Domain Engineering and Software Reuse J David Szwarcberg

Domain Engineering and Software Reuse J. David Szwarcberg MSCS Candidate Graduate College of Union University

What is software reuse? Reuse is simply using an asset previously built in a new context.

What is an asset? 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 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 Systems airline reservation systems inventory management systems medical record systems Parts of Systems database systems GUI Libraries math 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 Analysis Planning and Scoping • Select a Domain • Domain Description • Data Source Identification • Inventory Preparation

Domain Analysis Planning 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 Analysis Planning and Scoping • Domain Description Define the boundary and the contents of the domain

Domain Analysis Planning and Scoping • Data Source Identification Identify the sources of domain knowledge

Domain Analysis Planning and Scoping • Inventory Preparation Create inventory of data sources

Domain Analysis Domain Modeling • Data Collection • Data Analysis • Taxonomic Classification

Domain Analysis Domain Modeling • Data Collection Gather all knowledge available from sources identified in the data identification stage

Domain Analysis Domain Modeling • Data Analysis Analyze the variabilities of the domain Modularize the system Model the entities, and relationships of the domain

Domain Analysis Domain Modeling • Taxonomic Classification Group all relevant data Create a vocabulary for the domain model Create the abstract layer for the domain

Domain Analysis Domain 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. Peterson Software Engineering Institute (SEI) 1990 • Organization Domain Modeling (ODM) M. Simos Software 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 independent General in scope Can be used across domains • Domain specific Less general in scope Used more in its particular domain • Product specific Specialized component Only applicable to a certain product line

Domain Engineering Process K. Czarnecki

Process Implementation • Procuring, establishing, recognizing, and coordinating the assets of the infrastructure. • Tangible assets Funding Personnel Existing software • Intangible assets Rationalization Politics Motivation

Managing Reuse • Process needs to be maintained • Requires a well defined structure

Factors Affecting Reuse Management • Size of company Upfront costs • Size of development team(s) Need support • Product diversity Size the team(s) accordingly

Management Structures • Pool Producer Model Usually 2 to 3 teams Each team has a manager and several producers Manager and producers have reuse based incentives and metrics

Management Structures Level 3 Manager Level 2 Manager A Level 2 Manager B Pool Producers Project A Manager Project A Team Project B Manager Project B Team Pool Producer Organizational Structure [MMYA 02]

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 Libraries CARDS • 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 3 X improvement in time to market, with a 4 X reduction in overall team size, and a 25 X 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). ”

Qn. A