OAR © 2001 On-Line Applications Research Corporation Implementing a Product-Line Based Architecture in Ada Joel Sherrill, Ph.D., Jennifer Averett, and.

OAR

© 2001 On-Line Applications Research Corporation

Implementing a Product-Line Based Architecture in Ada

Joel Sherrill, Ph.D., Joel Sherrill, Ph.D., Jennifer Averett, and Glenn HumphreyJennifer Averett, and Glenn Humphrey

On-Line Applications Research CorporationOn-Line Applications Research Corporation4910-L Corporate Drive4910-L Corporate Drive

Huntsville, AL 35805Huntsville, AL 35805


OAR

Avenger and BradleyAvenger and Bradley


OAR

Our Software Development Our Software Development ChallengeChallenge

• SituationSituation– multiple similar products using derived copies of the same codemultiple similar products using derived copies of the same code– hard to ensure fixes were propagated to all productshard to ensure fixes were propagated to all products– systems have long lifespanssystems have long lifespans– minimize training for similar productsminimize training for similar products

• We needed to reduce the cost of We needed to reduce the cost of – production of new systems and product variantsproduction of new systems and product variants– maintenance maintenance – planned upgrades planned upgrades

• High expectations of software developersHigh expectations of software developers– reliability is expected to increasereliability is expected to increase– development time is expected to decreasedevelopment time is expected to decrease

We wanted to thrive, not just surviveWe wanted to thrive, not just survive


OAR

Solution – A Reuse Model ThatSolution – A Reuse Model That

• Leverages commonality of product family membersLeverages commonality of product family members• Reduces cost and time to marketReduces cost and time to market• Encourages development of new productsEncourages development of new products• Increases reliabilityIncreases reliability• Helps maintain look and feel of productHelps maintain look and feel of product• Distributes maintenance cost across multiple Distributes maintenance cost across multiple

productsproducts• Reflects Reflects

marketing view of product linemarketing view of product line hardware view of product linehardware view of product line organization structureorganization structure


OAR

Remember Why We Want Reuse …Remember Why We Want Reuse …

• Because reuse promotes Because reuse promotes – higher quality applicationshigher quality applications– less development time less development time – reduced cost of developmentreduced cost of development– reduced cost of maintenancereduced cost of maintenance

• Method of reuse is vitally importantMethod of reuse is vitally important– avoid reuse by copyavoid reuse by copy– feedback improvements to maintainerfeedback improvements to maintainer

• Families of applications can have high reuseFamilies of applications can have high reuse• Reuse between related products is achievableReuse between related products is achievable• Software portability is a reuse enablerSoftware portability is a reuse enabler

• But reuse requires– design– planning– commitment


OAR

Families of ApplicationsFamilies of Applications

• Product lines are grown from a successful Product lines are grown from a successful productproduct

• Marketing and hardware model for a product Marketing and hardware model for a product includesincludes– the core architecturethe core architecture– the product family architecturethe product family architecture– the individual productthe individual product

• Each product family has a manager whoEach product family has a manager who– governs the productgoverns the product– ensures compatibility between productsensures compatibility between products– manages the shared responsibilities of the productsmanages the shared responsibilities of the products


OAR

Example Product Family TreeExample Product Family Tree

C ore A rchitecture

Printer

Printer

Copier

Copier L ite

Fax

Fax Dem o

Printer NextG eneration

Printer 2000

Printer Deluxe

Printer W idget

Copier 1.0

Copier P ro

Fax 98

Fax ++


OAR

Reuse Within Product FamilyReuse Within Product Family

• Consider the FAX product Consider the FAX product family that has 3 family that has 3 individual productsindividual products– Fax DemoFax Demo– Fax 98Fax 98– Fax ++Fax ++

• Functionality may be Functionality may be shared between and shared between and among the individual among the individual productsproducts

Fax D em o Fax 98

Fax ++


OAR

Reuse Between Product Families Reuse Between Product Families

• Products from different Products from different product families can product families can share functionalityshare functionality– PrinterPrinter– CopierCopier– FAXFAX

• Shared componentsShared components– print engineprint engine– scannerscanner– paper feedpaper feed– duplexerduplexer

FAX

PRINTER CO PIER


OAR

Family Tree with Internet MigrationFamily Tree with Internet Migration

• Migrate Migrate functionality functionality through Core through Core Architecture from Architecture from one product to one product to anotheranother

• Internet support Internet support migrates from migrates from iFax to new iFax to new product iCopierproduct iCopier

C ore A rchitecture

P rin ter

P rin ter

C op ier

C op ier L ite

Fax

Fax D em o

P rin ter N extG enera tion

P rin ter 2000

P rin ter D e luxe

P rin ter W idget

C opier 1 .0

C opier P ro

Fax 98

Fax ++

iFaxiC op ier


OAR

Product Source Tree ExampleProduct Source Tree Example

• Figure is logical view– could be implemented

• We made toolkits– packaged– release procedure– viewed as system

libraries by applications

– include utilities, tests, and documentation

PRODUCT SOURCEROOT

PRODUCT FAMILYARCHITECTURE

COREARCHITECTURE

PRODUCT FAMILYSOURCE

PRODUCT SPECIFICSOURCE


OAR

Core and Product Family ToolkitsCore and Product Family ToolkitsThey are an important asset to the enterprise!They are an important asset to the enterprise!

• Should be viewed as an internal productShould be viewed as an internal product– testedtested– source code controlsource code control– release procedurerelease procedure– documentationdocumentation

• May have May have – formal releases to configuration managementformal releases to configuration management– informal development team releasesinformal development team releases


OAR

Release IssuesRelease Issues

• Core Architecture has its own releaseCore Architecture has its own release• Each Product Family Architecture is dependent Each Product Family Architecture is dependent

on a particular Core Architecture versionon a particular Core Architecture version– can include that version orcan include that version or– reference that versionreference that version

• OUR CHOICE: OUR CHOICE: – include Core Architecture in Product Family releases include Core Architecture in Product Family releases

• All software must be fully tested prior to releaseAll software must be fully tested prior to release• Maintainers of the Core Architecture must have Maintainers of the Core Architecture must have

sufficient resources, skill, and capability to test sufficient resources, skill, and capability to test any submission after it is merged into the any submission after it is merged into the architecture architecture


OAR

Feedback Release ProcessFeedback Release Process

• Products can develop Products can develop functionality and functionality and subsequently submit subsequently submit that functionality for that functionality for inclusion in the reuse inclusion in the reuse architecturearchitecture

• The development The development and submission and submission process is a process is a feedback loopfeedback loop

PRODUCTFAMILY

ARCHITECTURE

COREARCHITECTURE

PRODUCTSPECIFICSOURCE

Product FamilyArchitecture Release

CoreArchitecture

Release

Feedback

Feedback


OAR

Individual Product IssuesIndividual Product Issues

• Projects wish to control when and if an upgrade is Projects wish to control when and if an upgrade is acceptedaccepted

• For a product being developed on one host platform, the For a product being developed on one host platform, the product family architecture should be maintained on the product family architecture should be maintained on the same platformsame platform– With a working tree and released versions of the treeWith a working tree and released versions of the tree– Multiple products using the same version could share the Multiple products using the same version could share the

source code of the product familysource code of the product family• For a product pursuing reusable functionality for For a product pursuing reusable functionality for

submittal in the Core or a Product Family Architecture, a submittal in the Core or a Product Family Architecture, a working copy of the common architecture can be working copy of the common architecture can be maintained until it is incorporated and releasedmaintained until it is incorporated and released


OAR

Implementing Architectural Implementing Architectural Concepts in AdaConcepts in Ada

• Our project was written in Ada95Our project was written in Ada95• We recognized great potential for reuse BUT …We recognized great potential for reuse BUT …

how to implement the product family idea?how to implement the product family idea?

• We identified language features that would We identified language features that would helphelp packagespackages separate subprogramsseparate subprograms child units (both public and private)child units (both public and private) tagged/abstract typestagged/abstract types abstract subprogramsabstract subprograms


OAR

PackagesPackages

• Most basic means to replace an implementationMost basic means to replace an implementation• Replace body without modifying the specificationReplace body without modifying the specification• Coarse granularity of replacementCoarse granularity of replacement• Appropriate Appropriate

– when most subprograms are replacedwhen most subprograms are replaced– at logical edge of application such as HW or OS at logical edge of application such as HW or OS

interfacesinterfaces

• DisadvantageDisadvantage– can result in significant duplicationcan result in significant duplication– duplication is a problem during maintenance phaseduplication is a problem during maintenance phase


OAR

Separate SubprogramsSeparate Subprograms

• Granularity of replacement is subprogram levelGranularity of replacement is subprogram level• Replace body of single subprogram without Replace body of single subprogram without

modifying the specificationmodifying the specification• Appropriate Appropriate

– when few subprograms are replacedwhen few subprograms are replaced– subprogram variations for such as for speed vs. accuracysubprogram variations for such as for speed vs. accuracy– configuration checks (dynamic vs. static)configuration checks (dynamic vs. static)

• DisadvantagesDisadvantages– can be hard to track and manage subprogram variantscan be hard to track and manage subprogram variants– must have clear way for applications to pick from variantsmust have clear way for applications to pick from variants


OAR

Separate Subprograms as PackageSeparate Subprograms as Package

• Ada95 Style Guide suggestionAda95 Style Guide suggestion• Granularity of replacement is also subprogram Granularity of replacement is also subprogram

levellevel• Improves on simple use of separate Improves on simple use of separate

subprogramssubprograms– Subprogram can now have private state dataSubprogram can now have private state data

• Remember that this still creates something Remember that this still creates something that must be tracked during maintenance.that must be tracked during maintenance.

• Provides more freedom to implementers than Provides more freedom to implementers than simple separate subprogramssimple separate subprograms


OAR

Child UnitsChild Units

• Can contain related subprograms and related Can contain related subprograms and related datadata

• Appropriate Appropriate – when a logical set of subprograms are replacedwhen a logical set of subprograms are replaced– way to extend the functionality of an existing way to extend the functionality of an existing

packagepackage– encapsulate a logical section of a package (e.g. an encapsulate a logical section of a package (e.g. an

interface)interface)

• DisadvantagesDisadvantages– can be hard to track and manage variantscan be hard to track and manage variants– must have clear way for applications to pick from must have clear way for applications to pick from

variants variants


OAR

Public Child Unit ExamplePublic Child Unit Example

• Global Positioning System (GPS) Global Positioning System (GPS) • Package Package GPSGPS contains only basic positioning contains only basic positioning

– package GPS is …package GPS is …

• Add waypoint capability with public child Add waypoint capability with public child packagepackage– package GPS.Waypoints is …package GPS.Waypoints is …

• GPS.WaypointsGPS.Waypoints– is a public child unitis a public child unit– extends basic capabilities in extends basic capabilities in GPSGPS– has visibility into private parts of has visibility into private parts of GPSGPS– has great latitude in extending has great latitude in extending GPSGPS


OAR

Private Child Unit ExamplePrivate Child Unit Example

• Again package Again package GPSGPS contains only basic contains only basic positioningpositioning– package GPS is …package GPS is …

• Interface to GPS receiver in private child Interface to GPS receiver in private child packagepackage– package GPS.Interface is …package GPS.Interface is …

• GPS.InterfaceGPS.Interface– is a private child unitis a private child unit

NOT VISIBLE TO CLIENTS OF NOT VISIBLE TO CLIENTS OF GPSGPS– has visibility into private parts of has visibility into private parts of GPSGPS– has great latitude in implementing hardware specific has great latitude in implementing hardware specific

interfaceinterface


OAR

Tagged TypesTagged Types

• Augment an existing data type more informationAugment an existing data type more information • Data required by the child unit can be addedData required by the child unit can be added• Additional primitive subprograms may be definedAdditional primitive subprograms may be defined• Inherited primitive subprograms may be Inherited primitive subprograms may be

overriddenoverridden• Appropriate Appropriate

– way to extend the functionality of an existing packageway to extend the functionality of an existing package

• DisadvantagesDisadvantages– older Ada code must be modified to use thisolder Ada code must be modified to use this– application must derive a new type to use thisapplication must derive a new type to use this


OAR

More of GPS Waypoints ExampleMore of GPS Waypoints Example

package GPS ispackage GPS is

-- basic stucture-- basic stucture

type Control is taggedtype Control is tagged

recordrecord

Count : Natural;Count : Natural;

-- more fields here-- more fields here

end record;end record;

-- print current position-- print current position

procedure Position;procedure Position;

end GPS;end GPS;

package GPS.Waypoints ispackage GPS.Waypoints is

-- add the waypoints list-- add the waypoints list

type W is new GPS.Control withtype W is new GPS.Control with

recordrecord

Waypoints : Natural;Waypoints : Natural;

end record;end record;

-- list all the waypoints-- list all the waypoints

procedure List;procedure List;

end GPS.Waypoints;end GPS.Waypoints;


OAR

Abstract Types and SubprogramsAbstract Types and Subprograms

• Ada95 LRM DefinitionsAda95 LRM Definitions– An An abstract typeabstract type is a tagged type intended for use as is a tagged type intended for use as

a parent type for type extensions, but which is not a parent type for type extensions, but which is not allowed to have objects of its own.allowed to have objects of its own.

– An An abstract subprogramabstract subprogram is a subprogram that has no is a subprogram that has no body, but is intended to be overridden at some point body, but is intended to be overridden at some point when inherited. when inherited.

• Product line viewpointProduct line viewpoint– Mechanism to force individual applications to provide Mechanism to force individual applications to provide

implementations of specific configuration routinesimplementations of specific configuration routines


OAR

Organizational IssuesOrganizational Issues

• Product family managers shouldProduct family managers should– Realize the benefits of sharing development and maintenance Realize the benefits of sharing development and maintenance

responsibilities responsibilities across the products within the family they across the products within the family they managemanage

– Encourage individual product teams to reuse existing Encourage individual product teams to reuse existing components and develop new ones with reuse in mindcomponents and develop new ones with reuse in mind

• Corporate managers should Corporate managers should – encourage encourage individual product teams to reuse existing componentsindividual product teams to reuse existing components– develop new components with reuse in minddevelop new components with reuse in mind– reward teams for reusing this intellectual propertyreward teams for reusing this intellectual property

• The goal should be to develop an intellectual property base The goal should be to develop an intellectual property base that can be shared by all projects in the organizationthat can be shared by all projects in the organization

• Without management support, enterprise level reuse efforts Without management support, enterprise level reuse efforts are doomed to failureare doomed to failure


OAR

Management CommitmentManagement Commitment

• Management should establish a core architecture Management should establish a core architecture maintenance group that supports the maintenance group that supports the organization’s reuse base across multiple product organization’s reuse base across multiple product families byfamilies by– operating with the interests of all product families in operating with the interests of all product families in

mindmind– treating the core architecture of reusable components as treating the core architecture of reusable components as

a product itself even though the customers are internala product itself even though the customers are internal– including representatives from each product family to including representatives from each product family to

ensure that all interests are consideredensure that all interests are considered• The organization should encourage The organization should encourage

communication between the core architecture communication between the core architecture group and product developers as well as between group and product developers as well as between developers on different product teamsdevelopers on different product teams


OAR

Getting Management CommitmentGetting Management Commitment

• Focus on the benefits to both individual projects and enterpriseFocus on the benefits to both individual projects and enterprise• IncreasedIncreased

reliabilityreliability flexibilityflexibility

• Reduced Reduced time to markettime to market development costdevelopment cost testingtesting maintenance costmaintenance cost

We sold the product family reuse concept to management based We sold the product family reuse concept to management based primarily upon primarily upon

reduction in software maintenance cost.reduction in software maintenance cost.


OAR

Reduced Software Maintenance CostReduced Software Maintenance Cost

• Effective reuse requires a single “official” source for the reusable components, which

– acts as a collector, maintainer, and tester of components

– increases the overall quality of the reuse base while eliminating the problem that each user of the component has an independently maintained copy

• Multiple products distribute (share) costs of maintenance between product family and core architecture levels

• Costs to each product for maintaining that component are minimized


OAR

Product Family Tree Without ReuseProduct Family Tree Without Reuse

• No product family No product family architecturearchitecture

• No reuse across familiesNo reuse across families• Each project independently Each project independently

maintains each object maintains each object within its applicationwithin its application

• Total number of separately Total number of separately maintained objects:maintained objects: PrinterPrinter = 855= 855 CopierCopier = 360= 360 FaxFax = 435= 435

TOTAL TOTAL = 1650= 1650

C ore A rchitecture

P rin ter

P rin ter

C op ier

C op ier L ite

Fax

Fax D em o

P rin ter N extG enera tion

P rin ter 2000

P rin ter D e luxe

P rin ter W idget

C op ier 1 .0

C opier P ro

Fax 98

Fax ++

iFaxiC op ier

(0)

100

110

130

105

140

270

50

55

60

195

70

75

80

210

(0) (0)

iP rin ter


OAR

C ore A rch itectu re

P rinter

P rin ter

C opier

C opier L ite

Fax

Fax D em o

P rinter N extG eneration

P rin ter 2000

P rinter D eluxe

P rin ter W idget

C opier 1 .0

C opier P ro

Fax 98

Fax ++

iFaxiC opier

(50)

(5)

(15)

(35)

(10)

(45)

(45)

(1)

(6)

(11)

(20)

(5)

(10)

(15)

(15)

(4) (20)

iP rin ter

(45 + 130)

Product Family Tree With ReuseProduct Family Tree With Reuse

• Core and product family Core and product family architectures applied for architectures applied for reusereuse

• Each project independently Each project independently maintains fewer objects maintains fewer objects within its applicationwithin its application

• Total number of separately Total number of separately maintained objects:maintained objects: CoreCore = 175 = 175 FamilyFamily = 74= 74 PrinterPrinter = 155= 155 CopierCopier = 38= 38 FaxFax = 45= 45

TOTALTOTAL = 487= 487


OAR

Component Reuse ComparisonComponent Reuse Comparison

0

200400

600

800

10001200

1400

16001800

Pri

nte

r

Copie

r

Fax

Core

Fam

ily

Tota

l

No ReuseReuse


OAR

iPrinter Estimated Maintenance iPrinter Estimated Maintenance CostsCosts

• Without reuse, 270 Without reuse, 270 components to maintaincomponents to maintain

• With reuse, there areWith reuse, there are– 45 unique components45 unique components– 50 family components 50 family components

shared by 6 familiesshared by 6 families– 175 core components 175 core components

shared by 14 productsshared by 14 products

= 45 + (50/6) + = 45 + (50/6) + (175/14)(175/14)

= 45 + (8.33) + (12.5)= 45 + (8.33) + (12.5)

= 65.83 components= 65.83 components• Other product families Other product families

display similar resultsdisplay similar results

0

100

200

300

400

500

600

iPri

nte

r

Fam

ily

Core

Tota

l

NoReuseReuse


OAR

ConclusionConclusion

• An organization faces numerous challenges on the way to An organization faces numerous challenges on the way to establishing and successfully using a code reuse architecture establishing and successfully using a code reuse architecture

• The reuse model encourages reuse of software componentsThe reuse model encourages reuse of software components• Short term costs are easily recouped as more products are Short term costs are easily recouped as more products are

based on the Core Architecturebased on the Core Architecture• Maintenance is a fact of lifeMaintenance is a fact of life

• product improvements, technology insertions, bug fixes, etc.product improvements, technology insertions, bug fixes, etc.• An organization establishing and effectively utilizing a An organization establishing and effectively utilizing a

reusable code base will realize numerous benefitsreusable code base will realize numerous benefits• Realization of these benefits comes with commitment from Realization of these benefits comes with commitment from

management, development staff and investment of effortmanagement, development staff and investment of effort• Reuse is a continuous process based on a commitment to the Reuse is a continuous process based on a commitment to the

long-term success of the organizationlong-term success of the organization


OAR

ContactsContacts

Joel Sherrill, Ph.D.Joel Sherrill, Ph.D.Director of Research and Director of Research and

DevelopmentDevelopment

Glenn HumphreyGlenn HumphreyDirector of Software Director of Software

EngineeringEngineering

Jennifer AverettJennifer AverettSenior Software EngineerSenior Software Engineer

OAR CorporationOAR Corporation

4910-L Corporate Drive4910-L Corporate Drive

Huntsville, AL 35805Huntsville, AL 35805

Voice:Voice: (256) 722-9985(256) 722-9985

Fax:Fax: (256) 722-0985(256) 722-0985

Email:Email:[email protected]@OARcorp.co

mm

[email protected]@OARcorp.com

[email protected]@OARcorp.com

OAR © 2001 On-Line Applications Research Corporation Implementing a Product-Line Based Architecture in Ada Joel Sherrill, Ph.D., Jennifer Averett, and.

Documents

product family architecture

product families products

fax product family

product family toolkits

different product families

successful product marketing

new product icopier

product variants maintenance