Overview of Software Reuse and Software Product Line

Vijayan SugumaranDecision and Information Sciences

Oakland UniversityRochester, Michigan, 48309

USAsugumara@oakland.edu

Outline of the PresentationSoftware Reuse OverviewProduct Line OverviewTarget System Generation MethodologyPrototype ArchitectureSample SessionSummary

Software Reuse

Reuse Problem DimensionsReuse Problem Dimensions Reuse is still an active area of research No Silver Bullet – Incremental Progress Three Major Dimensions

Individual Factors Black-box syndrome

Organizational Factors Commitment to Reuse

Technical Factors Lack of standards Integration Issues Consistency, correctness, reliability

Individual

Organizational

Technical

Organizational Barriers a) economic barriers

lack of investment to create the reuse assets since they can not be charged to a client

b) administrative barriers lack of incentives and commitment from top

management c) political barriers

resistance to using artifacts developed in other units and the perception that the developers are no longer empowered to make architectural decisions

d) psychological barriers the “not invented here” syndrome and perceived

“top-down” imposition of a reuse mandate

Aspects of Technical Barriers

Reusable RepositoryOrganization

Search&

LocateCustomization&

Integration

Technical Barriers a) standards

lack of necessary standards for creating reusable assets within an organization

b) repository management lack of necessary tools and infrastructure to catalog,

archive and store reusable assets across multiple business units

c) component identification lack of effective search and retrieval mechanisms

d) customization and testing lack of adequate support for validating reusable

components that have been customized

Enabling Technologies

Search & LocateSearch & LocateDomain ModelDomain ModelNL / Web InterfaceNL / Web Interface

CustomizationCustomizationKnowledge-based ToolsKnowledge-based ToolsTruth Maintenance SystemsTruth Maintenance Systems

Architectural Framework forArchitectural Framework forComponent Based DevelopmentComponent Based Development

Reuse RepositoryReuse RepositoryObject-Oriented Methods and ToolsObject-Oriented Methods and ToolsBusiness ObjectsBusiness ObjectsComponent Models and ArchitecturesComponent Models and ArchitecturesObject ManagementObject Management

Reuse ObjectivesReuse of Higher Level ArtifactsReuse at analysis and design phasesOverall methodologyCombine the enabling technologies to

achieve reuse Domain Model, Object/Component

Repository, Knowledge-Base Technology

Domain Model Focus on the application domain Application Domain represented by a family of

systems “Artifacts resulting from domain modeling are

more conducive to reuse” Domain Model (DM)

Reflects similarities and variations of members of family of systems

Multiple viewpoint representation Domain Specific Software Architecture

(DSSA)

Component Based Development (CBD)

Component – Building block Hardware Industry

Standardized components Software Industry

Libraries are platform specific Language specific Lack of reuse of service, i.e., all or nothing Object-oriented technology

Didn’t create object market as anticipated

CBD – Focus on the Interface of components Standardized interface and behavior The notion of “contract”

Component Programming Model

Component 1

Component 2

pins

pins

Component 1

Component 2

methods

methods

Interface

Interface

Hardware Component Wiring

Software Component Wiring

CBD Building Blocks Repository

Collection of organized artifacts for reuse Lack of meta knowledge about artifacts Limitations in searching for reusable artifacts

Dependencies and relationships ignored

Ontology Explicit specification of related concepts Terms, definitions, relationships of application

domain

CBD Building Blocks (Cont’d)Domain Model

Model of an application domain Generic components within a domain

Objectives, processes, actions, actors, objects Dependencies between these artifacts

Use domain model information for searching reuse repositories

Possible Approach for Component Retrieval

User specifies search requirementsGenerate initial search queryUse ontology and domain model to

refine queryExecute the query against repository or

application databaseFormat results

NL/WebInterface

SearchQuery

QueryRefinement

QueryExecution/

PatternMatching

DomainModel

Ontology

ReuseRepository

Results

Server Side

ApplicationDatabase

CaptureUser Input

GenerateQuery

FormatResults

ClientSide

Query Interface Repository Interface

System Architecture

Prototype SystemWeb-based interfaceClient-server architecture

Java enabled web browser Form based interface Java-enabled server

Java ServletsJESS – Java Expert System Shell

Reasoning Engine

Server-side Modules Query Interface

Capture user input Generate initial query Format results

Query Refinement Module Use contents of ontology and domain model

Query Execution Module Servlets for query execution and pattern matching Identify and retrieve additional information

Server-side Modules (Cont’d) Ontology

Terms, synonyms, description, business rules, and relationships

Domain Model Objectives, processes, actions, actors, and

components (objects) Application Database

Operational data Reuse Repository

Pre-defined components (objects) for domain Metadata about the components

Seller Component

Attributes Methods JavaBeans Implementation

Seller_IDPasswordSeller NameAddressPrimary PhoneSecondary PhoneEmailCreditCard InformationConfirmationCode

Access methodsUpdate methodsOpen accountReview seller creditReview seller history

.

.

//Seller Class - with Bound propertyimport java.beans.*;import java.util.*:public class Seller extends Object {//instance variables protected String seller_id; protected String name; protected String address;

. . . //additional instance variables//constructor

Sample Components from Auction Domain Reuse Repository

Partial Auction Site Ontology

Term Synonym Description Business Rule Related to

Item Product Bought and sold and bidon

Category,Customer,Shipper

Category Classification ofProduct

Item

Customer Buyer, Seller Person who buys orsells

Item, Account

Account Prerequisite forTransaction

Customer Needsto open accountfor transaction

Customer

Shipper Vendor Company that deliversthe items to the buyer

Item

Transaction Sale Buying and selling of agood

Need both buyerand seller toproceed

Item, Customer,

Bid Currentauction price

Current price willing topay

Item, Customer

Bidder BuyerCustomer

Bids for item or producton sale

Has to beregistered to bid

Buyer,Customer, Item

Register Open an account inorder to buy or sellitems

Item, Customer

Step 1- Learn about the application domain

User: “give me details about the bidding process”

Step 2- Explore domain model

Search domain model for related information

e.g: “facilitate bidding” and “monitor bidding”

Example: Component Retrieval

Auction Site Development Central Initial Panel

Processes and Actions for the Facilitate Bidding Objective

Step 3- Specify component requirements

User wants to retrieve components for bidding process with methods for capturing bidder information, bid time, etc.

Step 4- Retrieve components

Based on objectives, processes, and actions, identify relevant components

Display component list to the user

User selects one or more components to view

Further Steps in Retrieval

Specifying the Component Retrieval Query

Viewing the JavaBean Implementation of the Bid Component

Software Product Line

Product Line OverviewProduct Line

Set of software-intensive systems that share a common, managed feature set satisfying specific needs or mission

Developed from a common set of core assets in a prescribed way

Core Assets Architecture, components, domain models,

requirement statements, specifications, schedules, test plans, budgets, etc.

Product Line Overview (contd) Individual System – Target System

Created using applicable components from the core asset base

Tailoring through preplanned variation mechanism

Adding new components as necessary Assembling the collection according to the

rules of the product-line architecture Predefined plan that specifies the exact

product building approach

Three Major ActivitiesCore Asset Development

Creating the repository of assets used in instantiating specific systems

Product Development Developing the individual systems within

the family of systemsManagement

Managing the technical as well as the organizational aspects

Core Asset DevelopmentSeparate activity or evolve out of

product developmentMine existing products for generic

assetsMay be purchased from other sourcesCore assets are refreshed as

organizations develop new productsTrack asset use and fed back to the

asset development activity

Inputs to Core Asset Development Product Constraints

Commonalities and variations among products including their behavioral features

Styles, patterns, and frameworks Relevant architectural building blocks

Production Constraints Standards and requirements

Production Strategy Top down, bottom up etc.

Inventory of pre-existing assets Leveraging already existing assets

Product DevelopmentDepends on the requirements for

individual productsStrong feedback effect on product line

scope, core assets, production plan, etc.

Product development can vary greatly depending on the available assets, production plan and organizational context

Management Strong commitment needed at the technical

and organizational levels Technical management oversees core asset

development and the product development Organizational management involves setting

proper structure and allocating sufficient resources

Adoption and diffusion plan that spells out the desired state and the strategy to achieve it

Product Line Practice AreasBody of work or collection of activities

that need to be mastered for creating successful product lines

Grouped into three major areas: Software engineering Technical Management Organizational Management

Software Engineering Practice Areas Necessary for applying the appropriate

technology to create and evolve core assets and products

Specific SE Areas: Architecture Definition Architecture Evaluation Component Development COTS Utilization Mining Existing Assets Requirements Engineering Software System Integration Testing Understanding Relevant Domains

Technical Management Practice Areas Necessary for Engineering the creation and

evolution of core assets and products Specific areas:

Configuration Management Data collection, Metrics and Tracking Make/Buy analysis Process Definition Scoping Technical Planning Technical Risk Management Tool Support

Organizational Management Practice Areas Necessary for orchestrating the entire product line

effort Specific areas:

Building a Business Case Customer Interface Management Developing an Acquisition Strategy Funding Launching and Institutionalizing Market Analysis Operations Organizational Planning Organizational Risk Management Structuring the Organization Technology Forecasting Training

Operational Issues Each core asset should have an associated process

that specifies how to use it in product development These processes get folded into what becomes the

product production plan Need commitment and sponsorship from someone

above technical ranks It takes highly proactive advocacy and marketing to

introduce software product lines Need architectural focus for success of product line

efforts Better product line tool support and more supportive

business models and data are imperative

Product Line Architecture Focus on the application domain Application Domain represented by various

artifacts “Artifacts resulting from domain modeling are

more conducive to reuse” Product Line architecture

Reflects similarities and variations of members of family of systems

Multiple viewpoint representation Individual Systems can be generated based

on specific requirements

Methodology for Target System Generation

1. Derive features and modules from the Domain Architecture Knowledge Base

2. Retrieve the corresponding implemented components from the Component Repository

3. Select the appropriate attributes and methods for the objects based on the new system requirements, and perform consistency checking

4. Customize and reconcile the components for the new system design

Steps:

Overall Methodology

Features

Processes

Patterns

Components

Components

Attributes MethodsAttributes Methods

System Requirements

Feedback

Component RepositoryDomain Architecture and Knowledge Base

Feedback

System Requirements Business RulesComponent Customization

Feature and MethodSelection

Domain Architecture

Features

Domain

Processes

Patterns

Optional

Agents

Mandatory

Domain Level

Process Level

Data Level

Features

Processes

Patterns

Components

Adaptation

Framework from LiteratureCurrent

Implementation

Sales Domain Asset ModelDomain: Sales

Features: 1. Define potential market segments 2. Analyze sales prospects3. Bid on large customer requests 4. Make the sale 5. Follow-up on sales 6. Analyze performance         Processes/Patterns: Components: 4. Make the sale Sales Person

Process order information Order Enter sales order Customer Follow-up orders Product Cancel sales order Hold sales order

Step 1-Derive Features & Components

Features of the new systemFrom Features, derive Processes and

ModulesDerive “Conceptual” ComponentsUse of Domain ArchitectureDependencies between artifacts

embedded in the domain architecture

Step 2-Retrieve Components from Component Repository

Sub-Steps:2.1 Identify relevant/comparable components

in the component repository

2.2 Retrieve and transform these components into a suitable representation for “configuring”

Artifact dependencies used in retrieval

Step 3 – Configure ObjectsSub-Steps:3.1 Select interfaces to support actions

- (access and update methods pulled in)

3.2 Select additional methods3.3 Configure (re-package) these “actual” components based on user requirements3.4 Perform Consistency Checking

Process –Pattern Method – Attribute

Pattern – Component Actual Components Consistency within features, components, methods, etc.

Step 4 – Object Customization

Sub-Steps:

4.1 Modify attribute and method names

4.2 Modify pre and post conditions of methods

4.3 Modify implementation of methods

4.4 Add new attributes and methods

Prototype Architecture

User Interface

RetrievalRules

ConfigurationRules

CustomizationRules

Consistency Checking Rules

Fact Base Component Base

Knowledge Base

Local Data

Domain ArchitectureRepository

Objectives

Domain

Processes

Actions

Data Files

Actors

Flows

Domain Level

Process Level

Data Level

ComponentRepository

Assembled SystemRepository

•Java Beans Hierarchy•Packages•Client/Server Relationships

New SystemRequirements

New SystemComponents

System “A” System “B” System “Z”

Jess Rules and Facts

(defrule single-dependency-present ""?rem1 <- (to-be-selected $?X Method)?rem2 <- (not-selected $?X Method ?p-id1)(Method-Dependency: $?X Method ?p-id1 requires $?Y Method ?p-id2)?rem3 <- (not-selected $?Y Method ?p-id2) =>(bind ?str1 (str-cat "Since the \"" (implode$ $?X) "\" Method requires " "\"" (implode$ $?Y) "\" Method, "))(bind ?str2 (str-cat "it will be automatically included in the Target System."))(bind ?str3 "Click on 'OK' to include, or 'Cancel' to abort.")(bind ?str (str-cat ?str1 ?str2 ?str3))(bind ?*d* (new YNDialog ?*current-pnl* "Method Deletion" ?str " OK " " Cancel ")))

Sample Consistency Checking Rule

Format(Component: component-name component-id) (Component-Dependency: comp-name1 comp-id1 requires comp-name2 comp-id2)

(Component-Part-Of: comp-name1 comp-id1 comp-name2 comp-id2)

(Component-Hierarchy: comp-name1 comp-id1 super-type:comp-name2 comp-id2 sub-type: comp-name3 comp-id3)

Jess Facts

Example(Component: Order Component 7)  (Component-Dependency: Order Component 7 requires Customer Component 4)  (Component-Part-Of: Order Component 7 contained-in Order Processing Component 1) (Component-Hierarchy: Order Component 7 super-type:Transaction Component 3 sub- type: Partial Order 11)

Target System Generation Domain Requirements

Domain DesignDomain

Design

Reusable Domain Specification

Reusable Domain Architecture

Target System Requirements

Elicitation

Target System Design Generator

Target System Requirements

Target System Specification

Target System Constraints

Executable Prototype/ Simulation Model

Unsatisfied RequirementsTarget System

Unsatisfied Domain Requirements

Domain Modeling

Target System Generation

Target System Architecture

Implementation of Domain

Specific Reusable

Components

Reusable Component

Library

Unsatisfied Constraints

Imported Reusable ComponentUnsatisfied Target

System Requirements

Target System Implementation

Domain Analysis & Specification

New Components

Multiple ViewsAggregation HierarchyGeneralization/Specialization HierarchyComponent InteractionState TransitionFeaturesNotion of Kernel and Optional

Components

NASA Goddard Ground Control CenterMonitor the health of the SatellitesUplink CommandsTelemetry DataA new ground control center established

from scratchDevelop a generic ground control centerFamily of ground control center software

systems

Payload Operations Control Center (POCC) Domain

POCC Aggregation Hierarchy

Payload Operations Control Center

(POCC) Domain

Telemetry CommandFlight

Operations Analyst

History

is-part-of is-part-ofis-part-of

GSH for Observatory Instrument Telemetry Trend Analyzer

Observatory Instrument

Telemetry Trend Analyzer

Experiment One Instrument

Telemetry Trend Analyzer

Experiment Three Instrument

Telemetry Trend Analyzer

Experiment Two Instrument

Telemetry Trend Analyzer

is-a is-a is-a

Component Interaction

Telemetry and

Command (TAC)

Recorder Utility

Processor System (RUPS)

Network Control Center (NCC)

Flight Operations

Analyst (FOA)

Command Management

System (CMS)

Flight Dynamics

Facility (FDF)

Greenwich Mean Time

(GMT)

4 History

*

2 Command

*1 Telemetry

*

3 Flight

Operations Analyst

*

Telemetry_Block_ or_Simulation_

Status

Command_Bloack_or_ OBC_Load_or_

Sim_Config

Raw_Tape_ Recorder_Dump

Tel_Displays_ Alarms_and_ Sim_Status

FOA_Tel_ Requests

FOA_History_ Requests_and_

Msgs

History_ Report

Replay_ Block

Tel_ History_

Msg

TimeOutgoing_

Attitude_Msg

Command_ OBC_ Load

OBC_Image_Msg_or_ Command_Verif_Msg

Command_ History_

MsgOutgoing_ Command_ Load_Ack

Incoming_ Command_

Load

Command_ Requests_

and_ Approvals

Command_Displays_ Alarms_and_ Notifications

FOA_Command Request

FOA_Displays

Response_ or_Status

NCC_Request_ or_NCC_Status

State Transition DiagramWaiting for

Command Status

Command-Received-Status-Msg 9

send Request-Command-Received-Status send History-Command-Verify-Msg 10, 10-b

Command-Received-Status (sent = arrived) 11

Command-Received-Status (sent not = arrived) 11-c

send Command-Received-Status- Alarm 12

Command-Executed-Status-Msg 15

send Request-Command-Executed-Status send History-Command-Verify-Msg 16, 16-b

Command-Executed-Status (expected = arrived) 17

send Command-Executed-Status- Alarm 18

Telemetry-Value 21

send Request-Telemetry-Expected-Value send History-Command-Verify-Msg 22, 22-b

Telemetry-Expected-Value (expected = arrived) 23

send Telemetry-Value-Alarm 24

Command-Executed-Status (expected not = arrived) 17-c

Telemetry-Expected-Value (expected not = arrived) 23-c

Command -Received Status Arrived

Command-Received Status Verified

Command-Executed Status Arrived

Command-Executed Status Verified

Telemetry-Value Arrived

Asset Development Environment

Figure 7. The EDLC Domain Modeling Environment

Object Communication Diagrams

Aggregation Hierarchy

Generalization /Specialization Hierarchies

State Transition Diagrams

Multiple Views of Domain Specification

State 1

State 2

Event

Action

arc node

directed multigraph

state transition digram

directed graph

object communi-

cation diagram

specializa- tion hierarchy

aggregation hierarchy

directed acyclic graph

tree

Mapping to Object Repository

and Multiple View Consistency

Checking

Knowledge-Based Target System

Generation

Multiple Views of Target System Specification

Target System Object Communication Diagrams

Target System Aggregation Hierarchy

Target System State Transition Diagrams

Event

Action

State 1

State 2

Object Repository

Feature / Object Editor

Domain Model

Documentation Tool

Domain Model Report

Feature/ Object

Dependencies

Target System

Requirements

Domain Features

Domain Component

TypeFeature

Exactly-One-of Feature Set

supported-by

set-of-mutually- exclusive-features

requiresis-part-of

is-a

id

name

id

properties

name

cardinality

Mutually-exclusive Feature Set

id

annotation

name

id

annotation

name

At-least-one-of Feature Set

id

annotation

name

set-of-exactly- one-of-features

set-of-at-least- one-of-features

Feature Explanation

id

annotation

name

feature- explanation

Application Domain name

contains

contains

Knowledge Based Requirements Elicitation Tool (KBRET)

Target System Requirements

Engineer

User Interface Manager

Domain Browser

Feature&Object Selection/Deletion

HandlerDependency

Checker

Inference Engine

Target System

Generator

Core Asset Repository

Target System

Specification

KBRET

Domain Independent Knowledge-Base

Domain Dependent Knowledge-Base

Feature and Object

Definitions

Feature/Object Dependency

View

Multiple Views

KBRET-Asset Repository Interface

KBRET Knowledge Bases

Sample Screens

Viewing the Features

Feature Information

Selecting Features

Dependency Checking

Figure A.12. Enforcing the exactly-one-of constraint

Dependency Checking

Dependency Checking

Target System Specification Generation

Specification Generation

Target System Specification

Target System AH

SADA Initial Panel

Dependency Checking

Assembling and Viewing New System

Configuring the New System

Configuring Objects

Consistency Checking

Summary and Ongoing Work Summary

Methodology for reuse of higher level artifacts Use of Domain Architecture and KB Technologies in SPL Consistency checking

Ongoing Research More support for Customization & Conflict Resolution Impact analysis, i.e., “ripple effect” of change Core Asset Repository Evolution Product Line Architecture Evolution Consistency of “New System” Templates Validation of the system