PLE-RUP: A Way to Product Line Engineering

1. PLE-RUP: A Way to Product Line Engineering By Nafees Qamar, Romana Aziz Faculty of Computer Sciences, COMSATS Institute of Information Technology, Islamabad, Pakistan. PLE-RUP: A Way to PLE

2. Presentation Profile • Things I will cover • A brief Introduction to Product Line Engineering (PLE) & its underlying Terminologies • Problem Statement • Proposed Methodology w.r.t • Aspect-Oriented Software Development • Model Driven Architecture • Specialized activities related to PLE • Conclusion & Future Outlook • Things I won’t cover in detail • In depth discussion on specific technologies like AOSD, MDA • Case Study PLE-RUP: A Way to PLE

3. Research Question/ Motivation • How can product families be engineered to achieve the goals of a software product line? & • To identify essential activities in software product lines and to bring improvements in its practice (State-of-the-art) • To propose new way to organizations which employing PLE concepts and to provide guidance to an organization PLE-RUP: A Way to PLE

4. Introduction: (1) • Often we confuse between two the terms • Product Lines: Group of products sharing a common, managed set of features that satisfy needs of selected market or mission • Product Family: Set of related systems that are built from a common set of core assets • Example? • Domain? • A specialized body of knowledge; an area of expertise. PLE-RUP: A Way to PLE

5. What is PLE?: (2) • To be very precise • Systematic reuse strategy that defines a software or hardware production process that takes advantage of previous developments and focuses on enhancing the product line rather than creating a new product • Domain Engineering? • Systematic approach to construct reusable assets • Application Engineering? • Use the assets to build specialized software systems PLE-RUP: A Way to PLE

6. Domain Engineering System Family Architecture Domain Knowledge Domain Model Domain Design Domain Analysis Domain Implementation New Requirements New Requirements Application Engineering Custom Design Custom Development Design Analysis Requirements Analysis Integration and Testing Customer Needs Customer Needs Features Product Configuration Look at Complications! MDA, AOSD, Light-weight Formal Methods, RUP Adoption, UML Profiles PLE-RUP: A Way to PLE

7. PLE-RUP: Focused Challenges • Along with Research Questions • Developing Product Line/Product Family • Evolving product line architectures and core assets • Collecting, organizing and storing past experience in building (parts of) systems • as well as providing means for reusing these assets (retrieve, adapt, assemble, etc...) • Building New Systems – Pure Application Engg. • How we can realize improved reusability? PLE-RUP: A Way to PLE

8. Existing Methodologies • COPA • FAST • FORM • QADA • PuLSE • PuLSE-I PLE-RUP: A Way to PLE

9. The Proposed Process – at a glance This is realized by various abstraction levels PLE-RUP: A Way to PLE

10. Aspectual Decomposition • Our way of catering requirements and their implementation… • Because of the Better Modularity, Increased Traceability PLE-RUP: A Way to PLE

11. PLE-RUP Phases: (1) • Inception: Product / Product Family (project viability) • Elaboration: Product / PLE Architecture • Construction: Product / Product Family Construction • Transition: End Product • Product Line Engineering: Workflow Output • Enhanced Reusability PLE-RUP: A Way to PLE

12. Proposed Workflow • Requirements Specifications/ stakeholders identification • Aspect-Oriented Software Development • Product Family • Product planning (scoping), • Product modeling (feature modeling) • and Product validation • Analysis & Design / Abstractions • Model Driven Architecture • Implementation • Test • Deploy PLE-RUP: A Way to PLE

13. MDA-Model Driven Architecture • The Motivation is apparent • Changes in the underlying platform do not affect existing applications, and • Business logic can evolve independently from the underlying technology • Computation Independent Model (CIM) • Platform Independent Model (PIM) • Platform Specific Model (PSM) • described by a Platform Model (PM), • and an Implementation Specific Model (ISM) PLE-RUP: A Way to PLE

14. Define and maintain business domain model Platform Independent Model Just enough modeling Built-in UML Modeling or… Supports external Modeling tools (e.g. Rational Rose) Automated transformations to application model(s) Platform Specific Models J2EE Architecture Automated code generation 100% Industry standard code Robust, secure, scalable, maintainable Working code (not stubs or skeletons) Agile, Iterative Automated application packaging and deployment Supports all standard deployment environments No lock-in Domain Model (PIM) Application Model (PSM) Code Model Web Server DBMS … Application Server MDD: Model Driven Development PLE-RUP: A Way to PLE

15. Summary of MDA benefits for Domain Specifications • Isolates domain specifications from platform details • Reduces complexity • Preserves domain model semantics • Increases stability and lifetime • Generates to platform/legacy of choice • Decreased development time • fast iterative development • separation between the engineering and business requirements • Increased quality. • Builds on industry directions • Many partial implementations exist • Tool/platform support proliferating PLE-RUP: A Way to PLE

16. ASPECT-ORIENTED SOFTWARE DEVELOPMENT PLE-RUP: A Way to PLE

17. Case Study! • The implementation/ execution of this SDLC has been discussed in detail within the paper • Processes are instruments to develop software systems PLE-RUP: A Way to PLE

18. Summary • Conclusion so far: SPLs should be engineered by • explicitly setting product production goals • considering product production early (before core asset design) by AOSD • focusing on domain knowledge - MDAs • merging these concerns • Conjecture: SPLs might be better designed and implemented by • Product planning (scoping), • Product modeling (feature modeling) • and Product validation PLE-RUP: A Way to PLE

19. Future Outlook • Requirement Engineering • Through light-weight formal methods • Almost accomplished • Design • Executable Models/ UML Profiles • Testing of Product Line Engineering • How they differ from conventional ones? • Wrapping up to a organized SDLC PLE-RUP: A Way to PLE

20. References • Introduction to Software Product Lines, Chapter Author: Charles W. Krueger, PhD, CEO, BigLever Software. • Martin Verlage, Thomas Kiesgen, Five Years of Product Line Engineering in a Small Company, Proceedings of the 27th international conference on Software engineering, Pages: 534 – 543, 2005 . • Linda M. Northrop, SEI’s Software Product Line Tenets, IEEE SOFTWARE July / August 2002. • Joachim Bayer, Towards Engineering Product Lines Using Concerns, ICSE2000. • Michalis Anastasopoulos, Joachim Bayer, Oliver Rege, and Cristina Gacek, A Process for Product Line Architecture, Creation and Evaluation, PuLSE – DSSA – Version 2.0, IESE-Report No.038.00/E, A publication by Fraunhofer IESE. • Colin Atkinson, Joachim Bayer, Dirk Muthig, Component-Based Product Line Development: The KobrA Approach, Proceedings of the first conference on Software product lines: experience and research directions: experience and research directions, Pages: 289 – 309, 2000. ISBN: 0-79237-940-3. • Mari Matinlassi, Comparison of Software Product Line Architecture Design Methods: COPA, FAST, FORM, KobrA and QADA, Proceedings of the 26th International Conference on Software Engineering (ICSE’04), IEEE. • Erwan Breton Jean Btzivin, Model-Driven Process Engineering, 2001 IEEE. • J. Bayer, O. Flege, P. Knauber, R. Laqua, D. Muthig, K. Schmid, T. Widen, and J.-M. DeBaud, "Pulse: a methodology to develop software product lines," in SSR '99: Proceedings of the 1999. • John Bergey, Grady Campbell et al., DoD Product Line Practice Workshop Report, TECHNICAL REPORT, CMU/SEI-99-TR-015, ESC-TR-99-015 • Joachim Bayer, Cristina Gacek, Dirk Muthig, Tanya Widen, "PuLSE-I: Deriving Instances from a Product Line Infrastructure," ecbs, p. 237, 7th IEEE International Conference and Workshop on the Engineering of Computer Based Systems, 2000. • Reis, R.Q. et al. “Towards an Aspect-Oriented Approach to Improve the Reusability of Software Process Models”, Proc. of the Int’l Workshop on Early Aspects. Enschede, The Netherlands. Apr. 2002. • Shin Young Park, Soo Dong Kim, A Systematic Method for Scoping Core Assets in Product Line Engineering, Software Engineering Conference, 2005. APSEC '05. 12th Asia-Pacific. • Mikyeong Moon, Keunhyuk Yeom, An Approach To Developing Core Assets in Product Line, Software Engineering Conference, 2004. 11th Asia-Pacific, Dec. 2004. • On page(s): 586- 588, IEEE Xplore. • Mikyeong Moon, Heung Seok Chae, An Approach to Developing Domain Requirements as a Core Asset Based on Commonality and Variability Analysis in a Product Line, IEEE Transactions on Software Engineering,Volume 31 ,  Issue 7  (July 2005), Pages: 551 – 569. • Stuart R. Faulk, Product-Line Requirements Specification (PRS): an Approach and Case Study, 2001 IEEE. • François Coallier, Roger Champagne, A Product Line engineering practices model, Special issue on system and software architectures(IWSSA'04), Pages: 73 – 87, 2005. • Walker, R.J., Baniassad, E.L.A., and Murphy G.C., An Initial Assessment of Aspect-oriented Programming, ICSE ‘99 Los Angelos CA USA, in the proceedings of ACM, IEEE, 1999. • Rinard, R., Salcianu, A., and Bugrara S., A Classification System and Analysis for Aspect Oriented Programs, in the proceedings of ACM, Pages: 147 – 158, ISSN: 0163-5948, 2004. • AspectC++: http://www.aspectc.org. • AspectJ: http://eclipse.org/aspectj. PLE-RUP: A Way to PLE

21. Questions ? ? ? ? ? PLE-RUP: A Way to PLE

22. Thanks for Patient Listening! PLE-RUP: A Way to PLE