Overview of Software Reuse and Software Product Line
Vijayan SugumaranDecision and Information Sciences
Oakland UniversityRochester, Michigan, 48309
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