1 / 79

Overview of Software Reuse and Software Product Line

Overview of Software Reuse and Software Product Line. Vijayan Sugumaran Decision and Information Sciences Oakland University Rochester, Michigan, 48309 USA sugumara@oakland.edu. Outline of the Presentation. Software Reuse Overview Product Line Overview

shelley
Download Presentation

Overview of Software Reuse and Software Product Line

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Overview of Software Reuse and Software Product Line Vijayan Sugumaran Decision and Information Sciences Oakland University Rochester, Michigan, 48309 USA sugumara@oakland.edu

  2. Outline of the Presentation • Software Reuse Overview • Product Line Overview • Target System Generation Methodology • Prototype Architecture • Sample Session • Summary

  3. Software Reuse

  4. Reuse 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 Organizational Technical Individual

  5. 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

  6. Aspects of Technical Barriers Reusable Repository Organization Search & Locate Customization & Integration

  7. 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

  8. Enabling Technologies Search & Locate Customization 4 Knowledge-based Tools 4 Truth Maintenance Systems 4 Domain Model 4 NL / Web Interface Architectural Framework for Component Based Development Reuse Repository 4 Object-Oriented Methods and Tools 4 Business Objects 4 Component Models and Architectures 4 Object Management

  9. Reuse Objectives • Reuse of Higher Level Artifacts • Reuse at analysis and design phases • Overall methodology • Combine the enabling technologies to achieve reuse • Domain Model, Object/Component Repository, Knowledge-Base Technology

  10. 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)

  11. 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”

  12. Component Programming Model Component 1 Component 1 Interface pins methods pins methods Interface Component 2 Component 2 Software Component Wiring Hardware Component Wiring

  13. 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

  14. 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

  15. Possible Approach for Component Retrieval • User specifies search requirements • Generate initial search query • Use ontology and domain model to refine query • Execute the query against repository or application database • Format results

  16. System Architecture Ontology Application Database Capture User Input Search Query Query Execution/ Pattern Matching NL/Web Interface Query Refinement Generate Query Results Format Results Reuse Repository Repository Interface Query Interface Client Side Server Side Domain Model

  17. Prototype System • Web-based interface • Client-server architecture • Java enabled web browser • Form based interface • Java-enabled server • Java Servlets • JESS – Java Expert System Shell • Reasoning Engine

  18. 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

  19. 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

  20. Sample Components from Auction Domain Reuse Repository

  21. Term Synonym Description Business Rule Related to Item Product Bought and sold and bid Category, on Customer, Shipper Category Classification of Item Product Customer Buyer, Seller Person who buys or Item, Account sells Account Prerequisite for Customer Needs Customer Transaction to open account for transaction Shipper Vendor Company that delivers Item the items to the buyer Transaction Sale Buying and selling of a Need both buyer Item, Customer, good and seller to proceed Bid Current Current price willing to Item, Customer auction price pay Bidder Buyer Bids for item or product Has to be Buyer, Customer on sale registered to bid Customer, Item Register Open an account in Item, Customer order to buy or sell items Partial Auction Site Ontology

  22. Example: Component Retrieval 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”

  23. Auction Site Development Central Initial Panel

  24. Processes and Actions for the Facilitate Bidding Objective

  25. Further Steps in Retrieval • 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

  26. Specifying the Component Retrieval Query

  27. Viewing the JavaBean Implementation of the Bid Component

  28. Software Product Line

  29. Product Line Overview • Product 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.

  30. 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

  31. Three Major Activities • Core Asset Development • Creating the repository of assets used in instantiating specific systems • Product Development • Developing the individual systems within the family of systems • Management • Managing the technical as well as the organizational aspects

  32. Core Asset Development • Separate activity or evolve out of product development • Mine existing products for generic assets • May be purchased from other sources • Core assets are refreshed as organizations develop new products • Track asset use and fed back to the asset development activity

  33. 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

  34. Product Development • Depends on the requirements for individual products • Strong 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

  35. 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

  36. Product Line Practice Areas • Body 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

  37. 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

  38. 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

  39. 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

  40. 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

  41. 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

  42. Methodology for Target System Generation Steps: • Derive features and modules from the Domain Architecture Knowledge Base • Retrieve the corresponding implemented components from the Component Repository • Select the appropriate attributes and methods for the objects based on the new system requirements, and perform consistency checking • Customize and reconcile the components for the new system design

  43. Attributes Methods Overall Methodology Component Repository Domain Architecture and Knowledge Base Features Components Processes Components Attributes Methods Patterns Feedback Feedback Feature and Method Selection System Requirements Component Customization Business Rules System Requirements Component Integration

  44. Domain Architecture Features Domain Processes Features Processes Adaptation Domain Level Patterns Agents Patterns Process Level Mandatory Optional Components Data Level Current Implementation Framework from Literature

  45. Sales Domain Asset Model Domain:Sales Features: 1. Define potential market segments 2. Analyze sales prospects 3. 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

  46. Step 1-Derive Features & Components • Features of the new system • From Features, derive Processes and Modules • Derive “Conceptual” Components • Use of Domain Architecture • Dependencies between artifacts embedded in the domain architecture

  47. 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

  48. Step 3 – Configure Objects Sub-Steps: 3.1 Select interfaces to support actions - (access and update methods pulled in) 3.2 Select additional methods 3.3 Configure (re-package) these “actual” components based on user requirements 3.4 Perform Consistency Checking  Process –Pattern  Method – Attribute  Pattern – Component  Actual Components  Consistency within features, components, methods, etc.

  49. 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

  50. Domain Component Repository Assembled System Repository Domain Architecture Repository Objectives Processes Domain Level Actors Actions Process Level Flows Data Files Data Level • Java Beans Hierarchy • Packages • Client/Server Relationships System “A” System “B” System “Z” User Interface Knowledge Base Retrieval Rules Configuration Rules Customization Rules New System New System Components Requirements Consistency Checking Rules Local Data Fact Base Component Base Prototype Architecture

More Related