Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "OAR © 2001 On-Line Applications Research Corporation Implementing a Product-Line Based Architecture in Ada Joel Sherrill, Ph.D., Jennifer Averett, and."— Presentation transcript:

1 OAR © 2001 On-Line Applications Research Corporation Implementing a Product-Line Based Architecture in Ada Joel Sherrill, Ph.D., Jennifer Averett, and Glenn Humphrey On-Line Applications Research Corporation 4910-L Corporate Drive Huntsville, AL 35805

2 OAR © 2001 On-Line Applications Research Corporation Avenger and Bradley

3 OAR © 2001 On-Line Applications Research Corporation Our Software Development Challenge Situation Situation –multiple similar products using derived copies of the same code –hard to ensure fixes were propagated to all products –systems have long lifespans –minimize training for similar products We needed to reduce the cost of We needed to reduce the cost of –production of new systems and product variants –maintenance –planned upgrades High expectations of software developers High expectations of software developers –reliability is expected to increase –development time is expected to decrease We wanted to thrive, not just survive

4 OAR © 2001 On-Line Applications Research Corporation Solution – A Reuse Model That Leverages commonality of product family members Leverages commonality of product family members Reduces cost and time to market Reduces cost and time to market Encourages development of new products Encourages development of new products Increases reliability Increases reliability Helps maintain look and feel of product Helps maintain look and feel of product Distributes maintenance cost across multiple products Distributes maintenance cost across multiple products Reflects Reflects marketing view of product line marketing view of product line hardware view of product line hardware view of product line organization structure organization structure

5 OAR © 2001 On-Line Applications Research Corporation Remember Why We Want Reuse … Because reuse promotes Because reuse promotes –higher quality applications –less development time –reduced cost of development –reduced cost of maintenance Method of reuse is vitally important Method of reuse is vitally important –avoid reuse by copy –feedback improvements to maintainer Families of applications can have high reuse Families of applications can have high reuse Reuse between related products is achievable Reuse between related products is achievable Software portability is a reuse enabler Software portability is a reuse enabler But reuse requires – design – planning – commitment

6 OAR © 2001 On-Line Applications Research Corporation Families of Applications Product lines are grown from a successful product Product lines are grown from a successful product Marketing and hardware model for a product includes Marketing and hardware model for a product includes –the core architecture –the product family architecture –the individual product Each product family has a manager who Each product family has a manager who –governs the product –ensures compatibility between products –manages the shared responsibilities of the products

7 OAR © 2001 On-Line Applications Research Corporation Example Product Family Tree

8 OAR © 2001 On-Line Applications Research Corporation Reuse Within Product Family Consider the FAX product family that has 3 individual products Consider the FAX product family that has 3 individual products –Fax Demo –Fax 98 –Fax ++ Functionality may be shared between and among the individual products Functionality may be shared between and among the individual products

9 OAR © 2001 On-Line Applications Research Corporation Reuse Between Product Families Products from different product families can share functionality Products from different product families can share functionality –Printer –Copier –FAX Shared components Shared components –print engine –scanner –paper feed –duplexer

10 OAR © 2001 On-Line Applications Research Corporation Family Tree with Internet Migration Migrate functionality through Core Architecture from one product to another Migrate functionality through Core Architecture from one product to another Internet support migrates from iFax to new product iCopier Internet support migrates from iFax to new product iCopier

11 OAR © 2001 On-Line Applications Research Corporation Product 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

12 OAR © 2001 On-Line Applications Research Corporation Core and Product Family Toolkits They are an important asset to the enterprise! Should be viewed as an internal product Should be viewed as an internal product –tested –source code control –release procedure –documentation May have May have –formal releases to configuration management –informal development team releases

13 OAR © 2001 On-Line Applications Research Corporation Release Issues Core Architecture has its own release Core Architecture has its own release Each Product Family Architecture is dependent on a particular Core Architecture version Each Product Family Architecture is dependent on a particular Core Architecture version –can include that version or –reference that version OUR CHOICE: OUR CHOICE: –include Core Architecture in Product Family releases All software must be fully tested prior to release All software must be fully tested prior to release Maintainers of the Core Architecture must have sufficient resources, skill, and capability to test any submission after it is merged into the architecture Maintainers of the Core Architecture must have sufficient resources, skill, and capability to test any submission after it is merged into the architecture

14 OAR © 2001 On-Line Applications Research Corporation Feedback Release Process Products can develop functionality and subsequently submit that functionality for inclusion in the reuse architecture Products can develop functionality and subsequently submit that functionality for inclusion in the reuse architecture The development and submission process is a feedback loop The development and submission process is a feedback loop

15 OAR © 2001 On-Line Applications Research Corporation Individual Product Issues Projects wish to control when and if an upgrade is accepted Projects wish to control when and if an upgrade is accepted For a product being developed on one host platform, the product family architecture should be maintained on the same platform For a product being developed on one host platform, the product family architecture should be maintained on the same platform –With a working tree and released versions of the tree –Multiple products using the same version could share the source code of the product family For a product pursuing reusable functionality for submittal in the Core or a Product Family Architecture, a working copy of the common architecture can be maintained until it is incorporated and released For a product pursuing reusable functionality for submittal in the Core or a Product Family Architecture, a working copy of the common architecture can be maintained until it is incorporated and released

16 OAR © 2001 On-Line Applications Research Corporation Implementing Architectural Concepts in Ada Our project was written in Ada95 Our 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? We identified language features that would help We identified language features that would help packages packages separate subprograms separate subprograms child units (both public and private) child units (both public and private) tagged/abstract types tagged/abstract types abstract subprograms abstract subprograms

17 OAR © 2001 On-Line Applications Research Corporation Packages Most basic means to replace an implementation Most basic means to replace an implementation Replace body without modifying the specification Replace body without modifying the specification Coarse granularity of replacement Coarse granularity of replacement Appropriate Appropriate –when most subprograms are replaced –at logical edge of application such as HW or OS interfaces Disadvantage Disadvantage –can result in significant duplication –duplication is a problem during maintenance phase

18 OAR © 2001 On-Line Applications Research Corporation Separate Subprograms Granularity of replacement is subprogram level Granularity of replacement is subprogram level Replace body of single subprogram without modifying the specification Replace body of single subprogram without modifying the specification Appropriate Appropriate –when few subprograms are replaced –subprogram variations for such as for speed vs. accuracy –configuration checks (dynamic vs. static) Disadvantages Disadvantages –can be hard to track and manage subprogram variants –must have clear way for applications to pick from variants

19 OAR © 2001 On-Line Applications Research Corporation Separate Subprograms as Package Ada95 Style Guide suggestion Ada95 Style Guide suggestion Granularity of replacement is also subprogram level Granularity of replacement is also subprogram level Improves on simple use of separate subprograms Improves on simple use of separate subprograms –Subprogram can now have private state data Remember that this still creates something that must be tracked during maintenance. Remember that this still creates something that must be tracked during maintenance. Provides more freedom to implementers than simple separate subprograms Provides more freedom to implementers than simple separate subprograms

20 OAR © 2001 On-Line Applications Research Corporation Child Units Can contain related subprograms and related data Can contain related subprograms and related data Appropriate Appropriate –when a logical set of subprograms are replaced –way to extend the functionality of an existing package –encapsulate a logical section of a package (e.g. an interface) Disadvantages Disadvantages –can be hard to track and manage variants –must have clear way for applications to pick from variants

21 OAR © 2001 On-Line Applications Research Corporation Public Child Unit Example Global Positioning System (GPS)Global Positioning System (GPS) Package GPS contains only basic positioningPackage GPS contains only basic positioning –package GPS is … Add waypoint capability with public child packageAdd waypoint capability with public child package –package GPS.Waypoints is … GPS.WaypointsGPS.Waypoints –is a public child unit –extends basic capabilities in GPS –has visibility into private parts of GPS –has great latitude in extending GPS

22 OAR © 2001 On-Line Applications Research Corporation Private Child Unit Example Again package GPS contains only basic positioningAgain package GPS contains only basic positioning –package GPS is … Interface to GPS receiver in private child packageInterface to GPS receiver in private child package –package GPS.Interface is … GPS.InterfaceGPS.Interface –is a private child unit NOT VISIBLE TO CLIENTS OF GPS NOT VISIBLE TO CLIENTS OF GPS –has visibility into private parts of GPS –has great latitude in implementing hardware specific interface

23 OAR © 2001 On-Line Applications Research Corporation Tagged Types Augment an existing data type more information Augment an existing data type more information Data required by the child unit can be added Data required by the child unit can be added Additional primitive subprograms may be defined Additional primitive subprograms may be defined Inherited primitive subprograms may be overridden Inherited primitive subprograms may be overridden Appropriate Appropriate –way to extend the functionality of an existing package Disadvantages Disadvantages –older Ada code must be modified to use this –application must derive a new type to use this

24 OAR © 2001 On-Line Applications Research Corporation More of GPS Waypoints Example package GPS is -- basic stucture -- basic stucture type Control is tagged type Control is tagged record record 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; package GPS.Waypoints is -- add the waypoints list type W is new GPS.Control with record Waypoints : Natural; end record; -- list all the waypoints procedure List; end GPS.Waypoints;

25 OAR © 2001 On-Line Applications Research Corporation Abstract Types and Subprograms Ada95 LRM Definitions Ada95 LRM Definitions –An abstract type is a tagged type intended for use as a parent type for type extensions, but which is not allowed to have objects of its own. –An abstract subprogram is a subprogram that has no body, but is intended to be overridden at some point when inherited. Product line viewpoint Product line viewpoint –Mechanism to force individual applications to provide implementations of specific configuration routines

26 OAR © 2001 On-Line Applications Research Corporation Organizational Issues Product family managers should Product family managers should –Realize the benefits of sharing development and maintenance responsibilities across the products within the family they manage –Encourage individual product teams to reuse existing components and develop new ones with reuse in mind Corporate managers should Corporate managers should –encourage individual product teams to reuse existing components –develop new components with reuse in mind –reward teams for reusing this intellectual property The goal should be to develop an intellectual property base that can be shared by all projects in the organization The goal should be to develop an intellectual property base that can be shared by all projects in the organization Without management support, enterprise level reuse efforts are doomed to failure Without management support, enterprise level reuse efforts are doomed to failure

27 OAR © 2001 On-Line Applications Research Corporation Management Commitment Management should establish a core architecture maintenance group that supports the organizations reuse base across multiple product families by Management should establish a core architecture maintenance group that supports the organizations reuse base across multiple product families by –operating with the interests of all product families in mind –treating the core architecture of reusable components as a product itself even though the customers are internal –including representatives from each product family to ensure that all interests are considered The organization should encourage communication between the core architecture group and product developers as well as between developers on different product teams The organization should encourage communication between the core architecture group and product developers as well as between developers on different product teams

28 OAR © 2001 On-Line Applications Research Corporation Getting Management Commitment Focus on the benefits to both individual projects and enterprise Focus on the benefits to both individual projects and enterprise Increased Increased reliability reliability flexibility flexibility Reduced Reduced time to market time to market development cost development cost testing testing maintenance cost maintenance cost We sold the product family reuse concept to management based primarily upon reduction in software maintenance cost.

29 OAR © 2001 On-Line Applications Research Corporation Reduced 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

30 OAR © 2001 On-Line Applications Research Corporation Product Family Tree Without Reuse No product family architecture No product family architecture No reuse across families No reuse across families Each project independently maintains each object within its application Each project independently maintains each object within its application Total number of separately maintained objects: Total number of separately maintained objects: Printer= 855 Printer= 855 Copier= 360 Copier= 360 Fax= 435 Fax= 435 TOTAL = 1650

31 OAR © 2001 On-Line Applications Research Corporation Product Family Tree With Reuse Core and product family architectures applied for reuse Core and product family architectures applied for reuse Each project independently maintains fewer objects within its application Each project independently maintains fewer objects within its application Total number of separately maintained objects: Total number of separately maintained objects: Core= 175 Core= 175 Family= 74 Family= 74 Printer= 155 Printer= 155 Copier= 38 Copier= 38 Fax= 45 Fax= 45 TOTAL= 487

32 OAR © 2001 On-Line Applications Research Corporation Component Reuse Comparison

33 OAR © 2001 On-Line Applications Research Corporation iPrinter Estimated Maintenance Costs Without reuse, 270 components to maintain Without reuse, 270 components to maintain With reuse, there are With reuse, there are –45 unique components –50 family components shared by 6 families –175 core components shared by 14 products = 45 + (50/6) + (175/14) = 45 + (8.33) + (12.5) = components Other product families display similar results Other product families display similar results

34 OAR © 2001 On-Line Applications Research Corporation Conclusion An organization faces numerous challenges on the way to establishing and successfully using a code reuse architectureAn organization faces numerous challenges on the way to 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 based on the Core ArchitectureShort term costs are easily recouped as more products are based 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 reusable code base will realize numerous benefitsAn organization establishing and effectively utilizing a reusable code base will realize numerous benefits Realization of these benefits comes with commitment from management, development staff and investment of effortRealization of these benefits comes with commitment from management, development staff and investment of effort Reuse is a continuous process based on a commitment to the long-term success of the organizationReuse is a continuous process based on a commitment to the long-term success of the organization

35 OAR © 2001 On-Line Applications Research Corporation Contacts Joel Sherrill, Ph.D. Director of Research and Development Glenn Humphrey Director of Software Engineering Jennifer Averett Senior Software Engineer OAR Corporation 4910-L Corporate Drive Huntsville, AL Voice:(256) Fax:(256)


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

Similar presentations


Ads by Google