SOPLE-DE: an approach to design service-oriented product line architectures
13 Sep 2010-pp 456-460
TL;DR: The proposed approach provides guidance to identify, design and document architectural components, services, service compositions and their associated flows and demonstrates that the proposed solution can be viable.
Abstract: Software reuse is crucial for enterprises interested in software quality and productivity gains. In this context, Software Product Line (SPL) and Service-Oriented Architecture (SOA) are two reuse strategies that share common goals and can be used together to increase reuse and produce service-oriented systems faster, cheaper and customizable to specific customers. In this sense, this work investigates the problem of designing software product lines using service-oriented architectures, and presents a systematic approach to design software product lines based on services. The proposed approach provides guidance to identify, design and document architectural components, services, service compositions and their associated flows. In addition, an initial experimental study performed with the intention of validating and refining the approach is also depicted demonstrating that the proposed solution can be viable.
Figures (55)
Table 4.1 Search Strings 
Figure 6.3 Service Coupling 
Figure 5.18 Service Interface 
Table 5.5 Checklist of the Design Decisions Documentation Activity 
Table 5.1 Checklist of the Architectural Elements Identification Activity 
Table 4.4 Service Identification Techniques 
Table A.2 Service Specification Template 
Table A.1 Component Specification Template 
Figure 3.3 SOA Roles 
Figure 3.2 Distributed Object-Oriented Systems and SOA 
Table 4.5 Service Specification Artifacts 
Figure 2.2 Software Product Line Engineering Framework 
Figure 5.8 Conceptual Service Model 
Table B.3 Questionnaire for Subjects Feedback 
Figure 5.10 Variability Analysis Activity 
Table 6.2 The Profile of the Subjects 
Table 4.6 Roles Involved in the Process 
Figure 5.9 SOA Design Patterns 
Figure 2.1 The Essential Activities of Software Product Line Engineering 
Figure 1.2 RiSE Labs Projects 
Figure 5.13 Variability Granularity
Citations
More filters
21 Mar 2011
TL;DR: This paper proposes an approach to the development and configuration of Service-Oriented SPLs in which services are used as reusable assets and building blocks of implementation in which Mixed Integer Linear Programming is applied to find the optimal service selection within the constraints boundaries specified by stakeholders.
Abstract: Software Product Lines (SPLs) are families of software systems which share a common sets of feature and are developed through common set of core assets in order to promotes software reusability, mass customization, reducing cost, time-to-market and improving the quality of the product. SPLs are sets (i.e., families) of software applications developed as a whole for a specific business domain. Particular applications are derived from software families by selecting the desired features through configuration process. Traditionally, SPLs are implemented with systematically developed components, shared by members of the SPLs and reused every time a new application is derived. In this paper, we propose an approach to the development and configuration of Service-Oriented SPLs in which services are used as reusable assets and building blocks of implementation. Our proposed approach also suggests prioritization of family features according to stakeholder's non-functional requirements (NFRs) and preferences. Priorities of NFRs are used to filter the most important features of the family, which is performed by Stratified Analytic Hierarchical Process (S-AHP). The priorities also are used further for the selection of appropriate services implementation for business processes realizing features. We apply Mixed Integer Linear Programming to find the optimal service selection within the constraints boundaries specified by stakeholders.
21 citations
27 Sep 2010
TL;DR: This work investigates the problem of designing software product lines using service-oriented architectures, and presents a systematic approach to design product lines based on services, and provides guidance to identify, design and document components, services, service compositions and their associated communication flows.
Abstract: Software reuse is crucial for organizations interested in productivity gains and software quality. In this context, Software Product Line (SPL) and Service-Oriented Architecture (SOA) are two reuse strategies that share common goals and can be used together with the purpose of increasing reuse and producing service-oriented systems, customizable to specific customers, faster and cheaper than creating individual systems. In this sense, this work investigates the problem of designing software product lines using service-oriented architectures, and presents a systematic approach to design product lines based on services. The approach provides guidance to identify, design and document components, services, service compositions and their associated communication flows. In addition, an initial experimental study performed with the intention of validating and refining the approach is also depicted demonstrating that the proposed solution can be viable.
15 citations
23 Aug 2010
TL;DR: This paper combines ideas from the service domain and the product line domain and suggests a way for representing variability in service-oriented architectures by formalizing the notion of variability.
Abstract: Service-oriented architectures are a standard-based and technology-independent distributed computing paradigm for discovering, binding and assembling loosely-coupled software services. Software product lines on the other hand allow a generic architecture to be configured and deployed in different instances. Product lines facilitate systematic reuse through managing variability. In this paper, we combine ideas from the service domain and the product line domain and investigate what types of variability exist in service-oriented software architectures. Moreover, we suggest a way for representing variability in service-oriented architectures by formalizing the notion of variability. To allow different viewpoints on variability, we define stakeholder roles that occur in the context of service-oriented software architectures. By applying the proposed concepts, we hope to improve variability management at the software architecture level of service-oriented systems.
14 citations
25 Mar 2013
TL;DR: The paper describes an automated framework for service- oriented SPL engineering that allows modelers to design, deploy, and execute service-oriented SPLs using UML and the Service Oriented Architecture Modeling Language (SoaML).
Abstract: Service Oriented Architecture (SOA) development practices typically lack a systematic framework for managing variability in service requirements and architectures. This paper addresses this gap by applying software product line (SPL) concepts to model SOA systems as service families. The approach is to model SOA variability with a multiple-view service model and a corresponding meta-model. We integrate SPL concepts of feature modeling and commonality/variability analysis with multiple service requirements and architectural views by using UML and the Service Oriented Architecture Modeling Language (SoaML). The paper describes an automated framework for service-oriented SPL engineering that allows modelers to design, deploy, and execute service-oriented SPLs.
13 citations
25 Sep 2017
TL;DR: The intuition for this approach is provided and it is illustrated by means of a Hotel reservation service product line to define an algorithm to synthesise an orchestration of services that satisfies all feature constraints of theservice product line and the maximal number of service requests for which an agreement can be reached.
Abstract: In Service-Oriented Computing, contracts provide a way to characterise the behavioural conformance of a composition of services, and to guarantee that the results do not lead to spurious compositions. Adding variability leads to a product line of services capable of adapting to customer requirements and to changes in the context in which they operate. To this aim, we extended a previously introduced formal model of service contracts. In particular, we included: (i) feature-based constraints and (ii) four classes of service requests to characterise different variants of service agreement. We then exploited Supervisory Control Theory to define an algorithm to synthesise an orchestration of services that satisfies: (i) all feature constraints of the service product line, and (ii) the maximal number of service requests for which an agreement can be reached. Moreover, such an orchestration of a service product line, whose number of products is potentially exponential in the number of features, can be synthesised from only a subset of its products. A prototypical tool supports the developed theory. In this short paper, we provide the intuition for our approach and illustrate it by means of a Hotel reservation service product line.
12 citations
References
More filters
Book•
02 Sep 2011TL;DR: This research addresses the needs for software measures in object-orientation design through the development and implementation of a new suite of metrics for OO design, and suggests ways in which managers may use these metrics for process improvement.
Abstract: Given the central role that software development plays in the delivery and application of information technology, managers are increasingly focusing on process improvement in the software development area. This demand has spurred the provision of a number of new and/or improved approaches to software development, with perhaps the most prominent being object-orientation (OO). In addition, the focus on process improvement has increased the demand for software measures, or metrics with which to manage the process. The need for such metrics is particularly acute when an organization is adopting a new technology for which established practices have yet to be developed. This research addresses these needs through the development and implementation of a new suite of metrics for OO design. Metrics developed in previous research, while contributing to the field's understanding of software development processes, have generally been subject to serious criticisms, including the lack of a theoretical base. Following Wand and Weber (1989), the theoretical base chosen for the metrics was the ontology of Bunge (1977). Six design metrics are developed, and then analytically evaluated against Weyuker's (1988) proposed set of measurement principles. An automated data collection tool was then developed and implemented to collect an empirical sample of these metrics at two field sites in order to demonstrate their feasibility and suggest ways in which managers may use these metrics for process improvement. >
5,476 citations
TL;DR: An outline is given of the process steps involved in the spiral model, an evolving risk-driven approach that provides a framework for guiding the software process and its application to a software project is shown.
Abstract: A short description is given of software process models and the issues they address. An outline is given of the process steps involved in the spiral model, an evolving risk-driven approach that provides a framework for guiding the software process, and its application to a software project is shown. A summary is given of the primary advantages and implications involved in using the spiral model and the primary difficulties in using it at its current incomplete level of elaboration. >
5,055 citations
Book•
01 Jan 1997TL;DR: This second edition of this book reflects the new developments in the field and new understanding of the important underpinnings of software architecture with new case studies and the new understanding both through new chapters and through additions to and elaboration of the existing chapters.
Abstract: From the Book:
Our goals for the first edition were threefold. First, we wanted to show through authentic case studies actual examples of software architectures solving real-world problems. Second, we wanted to establish and show the strong connection between an architecture and an organization's business goals. And third, we wanted to explain the importance of software architecture in achieving the quality goals for a system.
Our goals for this second edition are the same, but the passage of time since the writing of the first edition has brought new developments in the field and new understanding of the important underpinnings of software architecture. We reflect the new developments with new case studies and the new understanding both through new chapters and through additions to and elaboration of the existing chapters.
Architecture analysis, design, reconstruction, and documentation have all had major developments since the first edition. Architecture analysis has developed into a mature field with industrial-strength methods. This is reflected by a new chapter about the architecture tradeoff analysis method (ATAM). The ATAM has been adopted by industrial organizations as a technique for evaluating their software architectures.
Architecture design has also had major developments since the first edition. The capturing of quality requirements, the achievement of those requirements through small-scale and large-scale architectural approaches (tactics and patterns, respectively), and a design method that reflects knowledge of how to achieve qualities are all captured in various chapters. Three new chapters treat understanding quality requirements, achieving qualities, and theattribute driven design (ADD) method, respectively.
Architecture reconstruction or reverse engineering is an essential activity for capturing undocumented architectures. It can be used as a portion of a design project, an analysis project, or to provide input into a decision process to determine what to use as a basis for reconstructing an existing system. In the first edition, we briefly mentioned a tool set (Dali) and its uses in the re-engineering context; in in this edition the topic merits its own chapter.
Documenting software architectures is another topic that has matured considerably in the recent past. When the first edition was published, the Unified Modeling Language (UML) was just arriving on the scene. Now it is firmly entrenched, a reality reflected by all-new diagrams. But more important, an understanding of what kind of information to capture about an architecture, beyond what notation to use, has emerged. A new chapter covers architecture documentation.
The understanding of the application of software architecture to enable organizations to efficiently produce a variety of systems based on a single architecture is summarized in a totally rewritten chapter on software product lines. The chapter reinforces the link between architecture and an organization's business goals, as product lines, based around a software architecture, can enable order-of-magnitude improvements in cost, quality, and time to market.
In addition to the architectural developments, the technology for constructing distributed and Web-based systems has become prominent in today's economy. We reflect this trend by updating the World Wide Web chapter, by using Web-based examples for the ATAM chapter and the chapter on building systems from components, by replacing the CORBA case study with one on Enterprise JavaBeans (EJB), and by introducing a case study on a wireless EJB system designed to support wearable computers for maintenance technicians.
Finally, we have added a chapter that looks more closely at the financial aspects of architectures. There we introduce a method--the CBAM--for basing architectural decisions on economic criteria, in addition to the technical criteria that we had focused on previously.
As in the first edition, we use the architecture business cycle as a unifying motif and all of the case studies are described in terms of the quality goals that motivated the system design and how the architecture for the system achieves those quality goals.
In this edition, as in the first, we were very aware that our primary audience is practitioners, so we focus on presenting material that has been found useful in many industrial applications, as well as what we expect practice to be in the near future.
We hope that you enjoy reading it at least as much as we enjoyed writing it.
0321154959P12162002
4,991 citations
"SOPLE-DE: an approach to design ser..." refers background in this paper
...Architecture specification is the next activity, in which the architecture is documented using different views in order to represent the concerns of the different stakeholders involved in the project [9]....
[...]
Book•
01 Aug 2001
TL;DR: The Three Essential Activities: Core Asset Development, Software Engineering Practice Areas, and Single-System Development with Reuse - All Three Together.
Abstract: Foreword. Preface. Acknowledgements. Dedication. Reader's Guide. I. SOFTWARE PRODUCT LINE FUNDAMENTALS. 1. Basic Ideas and Terms. What Is a Software Product Line? What Software Product Lines Are Not. Fortuitous Small-Grained Reuse. Single-System Development with Reuse. Just Component-Based Development. Just a Reconfigurable Architecture. Releases and Versions of Single Products. Just a Set of Technical Standards. A Note on Terminology. For Further Reading. Discussion Questions. 2. Benefits. Organizational Benefits. Individual Benefits. Benefits versus Costs. For Further Reading. Discussion Questions. 3. The Three Essential Activities. What Are the Essential Activities? Core Asset Development. Product Development. Management. All Three Together. For Further Reading. Discussion Questions. II. SOFTWARE PRODUCT LINE PRACTICE AREAS. Describing the Practice Areas. Starting versus Running a Product Line. Organizing the Practice Areas. 4. Software Engineering Practice Areas. Architecture Definition. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Architecture Evaluation. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Component Development. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. COTS Utilization. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Mining Existing Assets. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Requirements Engineering. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Software System Integration. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Testing. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Understanding Relevant Domains. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. 5. Technical Management Practice Areas. Configuration Management. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Data Collection, Metrics, and Tracking. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Make/Buy/Mine/Commission Analysis. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Process Definition. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Scoping. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Technical Planning. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Technical Risk Management. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Tool Support. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. 6. Organizational Management Practice Areas. Building a Business Case. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Customer Interface Management. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Developing an Acquisition Strategy. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Funding. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Launching and Institutionalizing. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Market Analysis. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Operations. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Organizational Planning. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Organizational Risk Management. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Structuring the Organization. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Technology Forecasting. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Training. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. III. PUTTING THE PRACTICE AREAS INTO ACTION. 7. Software Product Line Practice Patterns. The Value of Patterns. Software Product Line Practice Pattern Descriptions. The Curriculum Pattern. The Essentials Coverage Pattern. Each Asset Pattern. What to Build Pattern. Product Parts Pattern. Assembly Line Pattern. Monitor Pattern. Product Builder Pattern. Cold Start Pattern. In Motion Pattern. Process Pattern. Factory Pattern. Other Patterns. Practice Area Coverage. Discussion Questions. 8. Product Line Technical Probe. What Is the Product Line Technical Probe? Probe Interview Questions. Probe Participants. Probe Process. Using the Probe Results. Conducting a Mini Self-Probe. Discussion Questions. 9. Cummins Engine Company: Embracing the Future. Prologue. Company History. A Product Line of Engine Software. Getting off the Ground. An Organization Structured for Cooperation. Running the Product Line. Results. Lessons Learned. Epilogue. Practice Area Compendium. For Further Reading. Discussion Questions. 10. Control Channel Toolkit: A Software Product Line that Controls Satellites. Contextual Background. Organizational Profiles. Project History. Control Channels. Launching CCT. Developing a Business Case for CCT. Developing the Acquisition Strategy and Funding CCT. Structuring the CCT Organization. Organizational and Technical Planning. Operations. Engineering the CCT Core Assets. Domain Analysis. Architecture. Component Engineering. Testing: Application and Test Engineering. Sustainment Engineering: Product Line Evolution. Documentation. Managing the CCT Effort. Early Benefits from CCT. First CCT Product. Benefits beyond CCT Products. Lessons and Issues. Tool Support Is Inadequate. Domain Analysis Documentation Is Important. An Early Architecture Focus Is Best. Product Builders Need More Support. CCT Users Need Reuse Metrics. It Pays to Be Flexible, and Cross-Unit Teams Work. A Real Product Is a Benefit. Summary. For Further Reading. Discussion Questions. 11. Successful Software product Line Development in Small Organization. Introduction. The Early Years. The MERGER Software Product Line. Market Maker Software Product Line Practices. Architecture Definition. Component Development. Structuring (and Staffing) the Organization. Testing. Data Collection and Metrics. Launching and Institutionalizing the Product Line. Understanding the Market. Technology Forecasting. A Few Observations. Effects of Company Culture. Cost Issues. The Customer Paradox. Tool Support. Lessons Learned. Drawbacks. Conclusions: Software Product Lines in Small Organizations. For Further Reading. Discussion Questions. 12. Conclusions: Practices, Patterns and Payoffs. The Practices. The Patterns. The Success Factors. The Payoff. Finale. Glossary. Bibliography. Index.
3,502 citations
"SOPLE-DE: an approach to design ser..." refers background in this paper
...In the product development cycle, the architectural elements are specialized to a particular context according to specific customer requirements [5]....
[...]
...A service-oriented product line is considered as a set of similar service-oriented systems that supports the business processes of a specific domain and can be developed from a common set of core assets [5]....
[...]