initiating software product lines Feature-Oriented Product Line Engineering

Transcription

1 focus initiating software product lines -Oriented Product Line Engineering Kyo C. Kang and Jaejoon Lee, Pohang University of Science and Technology Patrick Donohoe, Software Engineering Institute, Carnegie Mellon University Product line software engineering is an emerging paradigm that helps organizations develop their wares from reusable core assets rather than from scratch. 1 3 However, to develop these assets, such software engineering must exploit commonality and manage variability. Many researchers in industry and academia started using a feature-oriented approach to commonality and variability analysis 4 after the Software Engineering Institute introduced -Oriented Domain Analysis in The -Oriented Reuse Method concentrates on analyzing and modeling a product line s commonalities and differences in terms of features and uses this analysis to develop architectures and components. The FORM explores analysis and design issues from a marketing perspective. FODA appeals to many product line developers because features are essential abstractions that both customers and developers understand. Customers and engineers usually speak of product characteristics in terms of the features the product has or delivers, so it s natural and intuitive to express any commonality or variability in terms of features. A feature-based model thus provides a basis for developing, parameterizing, and configuring reusable assets. Although requirements are essential inputs for core asset development, they are not sufficient on their own; a marketing and product plan () can help propel asset development. We extended FODA into the - Oriented Reuse Method (FORM) not only to support architecture design and object-oriented component development but also to incorporate a marketing perspective and explore analysis and design issues from that perspective. 6 With an, reuse is not opportunistic; it is carefully planned for a specific product line. Our customers have applied this method to several industrial application domains to create software engineering environments and software assets for a specific product line. 4 Here, we ll use a home integration system example to show how the FORM brings efficiency to product line development. FORM FORM product line engineering consists of two major processes: asset development and product development. (See Figure 1 for activities and their relationships.) Asset development consists of analyzing a product line (such as marketing and product plan development and refinement, feature modeling, and requirements analysis) and developing architectures and reusable components based on analysis results. Product development includes analyzing requirements, selecting features, selecting and adopting an architecture, and adapting components and generating code for the product. The identifies the information to gather during the marketing and business 58 IEEE SOFTWARE July/August /02/$ IEEE

2 Product line asset development process development refinement model PL req. model modeling PL req. Product line requirements analysis model PL req. COTS, patterns Conceptual architecture design Conceptual architecture Design object modeling Conceptual architecture Design object model Architecture refinement Process Deployment architecture architecture Component design Refined Product line assets Product requirement analysis and feature selection Architecture selection and adaptation Product development process Component adaptation and code generation Name PL Req. Data flow Activity Marketing and product plan Product line Requirements analyses. It includes a market analysis, a marketing strategy, product features, and product feature delivery methods. To start the asset development process, developers organize functional and nonfunctional product features from the into an initial feature model, which they then extend with design features operating environments, the domain technology available, and the implementation techniques to be used. In parallel, a product line requirements analysis elicits and organizes requirements in terms of a use case model and an object model. 7 A use case model defines interactions between the user and the system; an object model defines system responsibilities. The developers then refine the original with the help of both the feature and requirements models. The next step is conceptual architecture design, which allocates features to abstract architectural components and specifies the data and control dependencies between them. The result is a conceptual architecture. A design object model must be developed based on the conceptual architecture, the feature model, product line requirements, and other information such as any commercial off-the-shelf components or design patterns 8 relevant to the product line. Designers then refine this conceptual architecture into process and deployment architectures by allocating components to concurrent processes and network nodes, considering whether to replicate each process, and defining interaction methods between processes. (The process architecture represents concurrency structure in terms of concurrent processes or tasks to which functional elements are allocated; the deployment architecture shows an allocation of processes to hardware resources.) The component design activity then further refines the process and deployment architectures into concrete components by using the design object model. The provides quality attributes for architecture design and refinement. For example, user profile information in the can help determine the quality attributes required for the architectural design of the products targeted for each market segment. Also, the can help the developer explore design alternatives for feature delivery methods, the resolution of feature interaction problems, and so on. FORM product line engineering processes are iterative, incremental, and repeat until a design has enough details for implementation. Initiating asset development Developing an for a product line initiates asset development; the sets a specific context for analyzing the product line and exploring reuse. Products developed without considering how to market them or what the users needs and capabilities are cannot be sold. Functionality alone does not sell. Products must be configurable to meet user needs and capabilities. How the helps The first part of an is a marketing Figure 1. The -Oriented Reuse Method product line engineering process. The arrows show dataflow (each activity s use of work products). July/August 2002 IEEE SOFTWARE 59

3 Marketing and product plan Marketing plan (business concerns) Market analysis Market segment Needs assessment User profile Cultural and legal constraints Business opportunities Time to market Price range Marketing strategy Product delivery methods Other business considerations Figure 2. The elements of a marketing and product plan. Product plan (engineering concerns) Product features Product functional features lists description Quality attributes Usability, scalability, and so on Product feature delivery methods coverage binding time binding techniques plan, which includes a market analysis and a strategy for realizing business opportunities in that market (see Figure 2). For each market segment, the analysis includes an assessment of needs, potential users, cultural and legal constraints, time to market, and price range. The marketing strategy initially includes an outline of product delivery methods and other business considerations. Once we define the marketing plan, we should identify the characteristics of products in the line in terms of features and develop a plan to incorporate those features. A product plan includes product features and product feature delivery methods (see the right half of Figure 2). Product features are largely classified into functional and nonfunctional features. Functional features include services, which are often considered marketable units or units of increment in a product line, and operations, which are internal product functions that are needed to provide services. For example, in home integration systems, fire, intrusion, and flood detection and control features are functional features. Nonfunctional features include end-user-visible application characteristics that cannot be identified in terms of services or operations, such as presentation, capacity, usage, cost, and other quality attributes. Safety, reliability, and scalability are important quality attributes for a home integration system product line. A product feature delivery method defines how product features are sold or delivered to customers and users and how they are installed and maintained. We can prepackage some features in products as standard items; others can be selected at negotiation time. Other features could be specific to a customer and built into a custommade product. Marketing and product planning: An example Let s say that a home integration system company intends to become a major player with two initial products: a low-end product (LE-HIS) and a high-end product (HE-HIS). This company s key marketing strategy is to allow budget-conscious customers to start with a small system with a few features and then grow to a bigger one by adding new features instead of buying new products. Therefore, the product s scalability is the most difficult challenge for the engineers. Table 1 is an example of an for such a home integration system product line. The market analysis identifies two user categories (office building and home users) and two market segments (high-end and lowend) along with their current needs and user profiles. The user/maintainer profiles for each market segment are Low-end market (household uses): No computer skill is assumed for the potential users, and home integration system software should run on the PCs they already have. High-end market (office building uses): Dedicated engineers with computer science background are available for maintenance. The computing environment is distributed over a network, and maintainers can access the system remotely. The must also identify each country s laws and cultural traits. Emergency codes for each type of incident (such as fire, flood, or intrusion) could vary from country to country, as could safety and reliability requirements. Because the HE-HIS has many customerspecific requirements, the designers would choose the feature selection method (see Table 1) to adapt and integrate features at product delivery time. For the LE-HIS, they would use the prepackaged method (see Table 1) combined with a user-friendly interface for users who do not have any computer knowledge. The designers must refine product delivery 60 IEEE SOFTWARE July/August 2002

4 Fire Detection Fire Detection Fire Detection Table 1 A marketing and product plan example for a home integration system product line Office building (high-end product) Household (low-end product) User/maintainer profile Dedicated engineers with computer science backgrounds No computer knowledge is assumed delivery method selection from a predefined set of features (feature selection method) Prepackaged method Legal constraints Emergency control services must conform to each country s codes Emergency control services must conform to each country s codes Product features Fire, intrusion, flood, security, and other customer-specific features Fire, intrusion, flood Quality attributes Safety, reliability, scalability Safety, reliability, scalability, usability Product feature binding time Product delivery time Product build time identification and organization model Market information Business concerns Engineering concerns Marketing and product plan Market analysis Marketing strategy Product functional and nonfunctional features Product feature delivery methods Key driver interaction policy Quality attributes delivery methods Behavior specification (Statechart) Architecture design and evaluation Component design for feature binding time variation Collaboration through User profile User interface and installer design Product line assets methods into product feature delivery methods what features are allowed (feature coverage), when they are incorporated (product build time, product delivery or installation time, or runtime), and how that incorporation is made (framework, template, load table, plug-ins, and so on). 5,9,10 For example, the LE-HIS has a closed set of features, so feature binding occurs at the product build time. For the HE-HIS, however, customers can select any feature from a predefined list, so feature binding occurs at product delivery time, perhaps by using a load table that contains parameter values for instantiation. FORM with The FORM includes the to bring efficiency into product line asset development. (Figure 3 shows an overview of the concept.) modeling and requirements analysis Because a product line s sets a specific context for a product line analysis, the analyst can perform that analysis effectively and efficiently. As we mentioned earlier, product features identified in the are organized into an initial feature model, which is then refined by incorporating operating environment, domain-specific technology, and implementation technique features. When incorporating these features, analysts must investigate potential environmental and technological changes (see Figure 4). 11 Product line requirements analysis captures the necessary functionalities in a set of models such as a use case model, an object model, and so on. 7 Depending on the product line s domain, other models may be included. Based on this information, the product line component design provides realizations of common functions that an organization can use across products. (The complete set of models of the HIS example is not presented in this article because of space limitations.) Figure 3. Product line asset development using a marketing and product plan as a key driver. July/August 2002 IEEE SOFTWARE 61

5 Capability layer HIS Services Administration... Security Intrusion Fire Flood Standard Advanced Detection Action Detection Action Detection Action Door operation Message... Gas... Pumping Alarm Water Water Data Voice main Motion Smoke Moisture Direct Scheduled Periodic Monitor/control One-time Usability Scalability Eventbased Quality attributes Reliability Safety Operating environment layer Domain technology layer Monitoring and detecting Communication Telephone Internet... Detection devices Motion sensor Smoke sensor Moisture sensor Action devices... Sprinkler Sump pump Responding strategy Discrete value Continuous value Sequential Priority Implementation technique layer Connection Redundancy control TCP UDP Active Standby Composition rules Water requires Sprinkler. Flood requires Moisture sensor. Pumping requires Sump pump. Message requires Communication. Optional feature Alternative feature Composed-of relationship Generalization relationship Implemented-by relationship Figure 4. A feature model of the home integration system product line. interaction problems significantly affect the way components are designed and integrated. They can also affect how products are sold and delivered to customers. Suppose a product line has a large set of features from which customers can select. In this case, analyzing feature interactions for all possible feature combinations and having the components ready for them is probably too difficult. Analyzing feature interactions for each customer selection and handling the problem on a per-customer basis might be more cost-effective. The organization should use this information in designing components, and the marketing strategy should reflect it. Suppose, for example, a flood control feature, which shuts off the water main to the home during a flood, is added to the HIS along with the fire control feature, which turns sprinklers on during a fire. One possible scenario could see sprinklers turning on during a fire and flooding the basement before the fire is under control. This would trigger the flood control feature to shut off the home s water main, rendering the sprinklers useless. Thus, when features are added or integrated, the designer must analyze all possible interactions during product line requirements analysis and design the system so that no undesirable interactions occur. Figure 5 describes policies for handling LE-HIS feature interactions using the Statechart technique. The nested structure of states represents the priority among events, the deepest state having the lowest priority. Notice that the event-monitoring features are independently additive, and the associated activities perform concurrently. Event handling is not independently additive, so the designer should analyze interactions among features and devise and enforce an interaction resolution policy. Once the analyst refines the feature model and develops the product line requirement models, he or she can use this information to refine the, as Figure 1 describes. Because the initial contains delivery methods only for functional and nonfunctional features, the designer should develop product feature delivery methods for design features, such as operational environment and implementation technique features, during refinement. 62 IEEE SOFTWARE July/August 2002

6 Smoke level >?upper smoke level/fire Fire Detection detection Smoke level <?lower smoke level/extinguished Motion/intrusion Intrusion detection No motion/intrusion resolved Scheduled time/door event Door event handled No event Door event Door event handling Intrusion/set off alarm, send message to owner and police, lock doors Intrusion resolved/ turn alarm off Intrusion event handling Fire/turn sprinklers on, set off alarm, send message to owner and fire station, unlock doors, open water main Fire event handling Extinguished/shut off sprinklers, turn alarm off, timed event (back to normal,?time) Figure 5. Global control behavior of the low-end home integration system. The left side of the diagram shows event-monitoring activities being executed concurrently, and the right shows event-handling activities and priorities among them. Scheduled Fire Detection event detection Moisture/flood No flood event Flood under control/ open water main Flood/ shut off water main Restoration from fire event Back to normal Flood event handling Flood Fire Detection detection No moisture/flood under control Conceptual architecture design and architecture refinement In the FORM, architecture design starts with identifying high-level conceptual components and specifying data and control dependencies among them. The is a key design driver. For example, the conceptual architecture for LE-HIS (see the conceptual architecture in Figure 6) consists of three major components (HIS Control, Standby HIS Control, and Interface components); the Standby HIS Control component is added to meet the legal constraints on reliability by increasing the mean time between failures. Standby HIS Control is activated when HIS Control fails to send the Heartbeat data, thus making the system fault-tolerant. The Interface component is for external device scalability. It encapsulates the information on external devices and provides a common interface to HIS Control and Standby HIS Control. The next step is to refine the conceptual architecture into process and deployment architectures. The upper portion of Figure 6 shows the process and deployment architecture for the conceptual architecture s HIS Control component. (The processes are allocated to one network node.) During refinement, we use the quality attributes from the for architectural style selection and evaluation. 12 For example, we select the Independent Component architectural style 12 and design the human machine interface () process to configure the HIS Configuration and Status information-hiding module so that we can add new external devices easily. Component design Next, we refine the architectural components into concrete components. The product component design consists of specifications of components and relationships among them. Figure 7 shows a UML representation of the component specification of the EventDNMDriver component and relationships with other components. For component design, designers should take the product feature delivery methods in the into consideration. For example, the FORM s macro language ($IF(;$Flood) [...]) in the component specification of the July/August 2002 IEEE SOFTWARE 63

7 Figure 6. Architecture design and refinement for the low-end home integration system. Architecture refinement Process and deployment architecture request Event and action data Heart beat Event and action definition HIS configuration HIS and status configuration and status Action request Event definition Event detection and monitoring HIS configuration and status Action definition Event report device status Responding HIS configuration and status device Conceptual architecture Process Information hiding module Loosely coupled message queue Message without reply Data access Figure 7. Component specification for the EventDNMDriver. Heartbeat request HIS control Standby HIS control request device status device device status Moisture sensor input interface Motion sensor input Smoke sensor input Communication data Sprinkler control Door control Sump pump control Water main control Conceptual component Data flow Control flow FORM component specification for macro processing Component EventDNMDriver<;$Flood, ;$Intrusion, Implements Flood,Intrusion, Fire Require Moisture, SumpPump, Alarm, { DetectNMonitoring(){ $IF(;$Flood)[ If ( (moisturesensor->getmoisture( eventgeneration->generateevent(f1.... ] } UML/OCL specification FireEventDetection::FireDetection() pre: smokesensor.opflag = true post: if smokesensor->getsmoke() >= geteventdefinition->getdefinition(fire) then self.isfire = true else self.isfire = false endif EventDNMDriver DetectNMonitoring() FireEventDetection Fire: Event isfire: Boolean FireDetection():Boolean uses * SmokeSensor Smoke : Integer opflag : Boolean calls GetSmoke(): Integer isoperate(): Boolean 1 GetEventDefinition EventDefinition: Event Detection Detection():Boolean EventGeneration calls 1 1 GenerateEvent(e:Event) ChangeDefinition(e:Event, v:integer) GetDefinition(e:Event):Integer 64 IEEE SOFTWARE July/August 2002

8 About the Authors EventDNMDriver in Figure 7 supports the prepackaged LE-HIS feature delivery method. When we select the Flood feature (in Figure 4) as a prepackaged feature, code segments related to it are incorporated into the product at build time. As another example, we refine the process in Figure 6 into a framework, which defines a generic structure for implementing an Advanced feature for HE- HIS and a Standard feature for LE-HIS. At product build time, product-specific components for the Advanced and Standard features (in Figure 4) are instantiated from the framework. Depending on the nature of extensions required for product-specific features, we can use techniques such as code generation, encapsulation, parameterization, frameworks, templates, and so on. For example, we could specify the Event Generation component in Figure 7 that encapsulates a policy for handling feature interactions by using a formal specification technique (for example, the Statechart specification in Figure 5). Whenever we add new features, we modify and test the feature interaction specification for correctness, and users can generate new updated program code for the component. The FORM s connection to the forces organizations to make marketing more product aware and to think about how to package, deliver, and maintain features, who will perform these activities, and what the pricing implications are with various alternative approaches. The customer profile and other useful information go directly into product design. This marketing-oriented perspective can uncover critical quality attributes required for product line architecture and component design. By tightly coupling marketing with asset development, we can develop product line assets that will support business goals and satisfy customer needs. We are planning to apply our method to several product lines, including process computer systems for steel manufacturing factories and embedded systems for electrical appliances. Also, we are formalizing our method and extending our tool to support a marketing and product plan. Kyo C. Kang is a professor at the Pohang University of Science and Technology. His research interests include software reuse, real-time embedded systems, and automatic code generation. He received a PhD in industrial engineering from the University of Michigan. Contact him at the Dept. of Computer Science and Eng., Pohang Univ. of Science and Technology, San 31 Hyoja-Dong, Pohang, , Korea; kck@postech.ac.kr. Jaejoon Lee is a PhD candidate at the Pohang University of Science and Technology, where he received an MS in computer and communications engineering. He received a BS in mathematics from Sogang University. Contact him at the Dept. of Computer Science and Eng., Pohang Univ. of Science and Technology, San 31 Hyoja-Dong, Pohang, , Korea; gibman@postech.ac.kr. Patrick Donohoe is a senior member of the technical staff at the Software Engineering Institute of Carnegie Mellon University. His research interests are software product lines and analysis modeling. He received a BA in mathematics and an MS in computer science from Trinity College, Dublin, Ireland. Contact him at the Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, PA 15213; pd@sei.cmu.edu. References 1. P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, Addison Wesley Longman, Reading, Mass., D.M. Weiss and C.T.R. Lai, Software Product-Line Engineering: A Family-Based Software Development Process, Addison Wesley Longman, Reading, Mass., J. Bosch, Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach, Addison Wesley Longman, Reading, Mass., K.C. Kang et al., Oriented Product Line Software Engineering: Principles and Guidelines, to be published in Domain Oriented Systems Development: Practices and Perspectives, Taylor and Francis, London, K. Kang et al., -Oriented Domain Analysis (FODA) Feasibility Study, tech. report CMU/SEI-90- TR-21, Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, K. Kang et al., Using a Marketing and Product Plan as a Key Design Driver for Product Line Asset Development, G. Chastek, ed., Proc. 2nd Software Product Line Conf., Springer Lecture Notes in Computer Science, vol. 2379, Heidelberg, Germany, G. Chastek et al., Product Line Analysis: A Practical Introduction, tech. report CMU/SEI-2001-TR-001, Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley Longman, Reading, Mass., K. Czarnecki and U. Eisenecker, Generative Programming: Methods, Tools, and Applications, Addison Wesley Longman, Reading, Mass., M. Simos et al., Software Technology for Adaptable Reliable Systems (STARS) Organization Domain Modeling (ODM) Guidebook Version 2.0, STARS-VC- A025/001/00, Lockheed Martin Tactical Defense Systems, Manassas, Va., K. Lee, K. Kang, and J. Lee, Concepts and Guidelines of Modeling for Product Line Software Engineering, C. Gacek, ed., Proc. 7th Int l Conf. Software Reuse, Springer Lecture Notes in Computer Science, vol. 2319, Heidelberg, Germany, L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Addison Wesley Longman, Reading, Mass., For more information on this or any other computing topic, please visit our Digital Library at July/August 2002 IEEE SOFTWARE 65