presented at 4 th international workshop on frontiers of it, 20-21 dec, 2006 ple-rup: a way to ple1...

PLE-RUP: A Way to PLE 1

Presented at 4th International Workshop on Frontiers of IT, 20-21 Dec, 2006

PLE-RUP: A Way to Product Line Engineering

By

Nafees Qamar, Romana Aziz

Faculty of Computer Sciences,COMSATS Institute of Information Technology, Islamabad, Pakistan.



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



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



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.



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



Look at Complications!

DomainAnalysis

DomainAnalysis

Domain DesignDomain Design

DomainImplementation

DomainImplementation

Requirements Analysis

Requirements Analysis

Design AnalysisDesign Analysis

Integration and Testing

Integration and Testing

Domain Engineering

Domain Knowledge DomainModel

System Family

Architecture

Customer Needs

FeaturesProductConfiguration

CustomDesign

CustomDevelopment

New Requirements

Customer Needs

New Requirements

Application Engineering

MDA, AOSD, Light-weight Formal Methods, RUP Adoption, UML Profiles



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?



Existing Methodologies

COPA FAST FORM QADA PuLSE PuLSE-I



The Proposed Process – at a glance

Software Process – Product Line Engineering

Existing System Information

Requirements Specification/ Stakeholders

Guidelines

Product Family Visualization/ Product

Information

End Product

Built in support to become a family

Product Abstractions/ Models (MDA)

Reusability with minimal cost

Manual Input...

This is realized by various abstraction levels



Aspectual Decomposition

Software Requirements

Separating Functional & Non-functional Requirements

AOP Tools

Product Development

•Our way of catering requirements and their implementation…―Because of the Better Modularity, Increased Traceability



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



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



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)



MDD: Model Driven Development 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

CodeModel

Application

Model (PSM)

DomainModel

(PIM)

…

DBMS

Application Server

Web Server



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



ASPECT-ORIENTED SOFTWARE DEVELOPMENT



Case Study!

The implementation/ execution of this SDLC has been discussed in detail within the paper Processes are instruments to develop

software systems



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



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



References1) Introduction to Software Product Lines, Chapter Author: Charles W. Krueger, PhD, CEO, BigLever Software.2) 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 .3) Linda M. Northrop, SEI’s Software Product Line Tenets, IEEE SOFTWARE July / August 2002.4) Joachim Bayer, Towards Engineering Product Lines Using Concerns, ICSE2000. 5) 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.6) 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.

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

8) Erwan Breton Jean Btzivin, Model-Driven Process Engineering, 2001 IEEE.9) 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.10) John Bergey, Grady Campbell et al., DoD Product Line Practice Workshop Report, TECHNICAL REPORT, CMU/SEI-99-TR-015, ESC-TR-

99-01511) 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. 12) 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.13) 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.14) Mikyeong Moon, Keunhyuk Yeom, An Approach To Developing Core Assets in Product Line, Software Engineering Conference, 2004.

11th Asia-Pacific, Dec. 2004.15) On page(s): 586- 588, IEEE Xplore.16) 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.17) Stuart R. Faulk, Product-Line Requirements Specification (PRS): an Approach and Case Study, 2001 IEEE.18) François Coallier, Roger Champagne, A Product Line engineering practices model, Special issue on system and software

architectures(IWSSA'04), Pages: 73 – 87, 2005.19) 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. 20) 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.21) AspectC++: http://www.aspectc.org.22) AspectJ: http://eclipse.org/aspectj.



Questions

? ???

?



Thanks for Patient Listening!

presented at 4 th international workshop on frontiers of it, 20-21 dec, 2006 ple-rup: a way to ple1...

Documents

product line engineering

new product domain engineering

ple7 plerup

ple1 plerup

ple concepts

international workshop

product families

new way