Eduardo Santana de Almeida, Silvio Lemos Meira {esa2, srlm}@cin.ufpe.br, www.cin.ufpe.br/~esa2

1. Towards an Effective Software Reuse Process Eduardo Santana de Almeida, Silvio Lemos Meira {esa2, srlm}@cin.ufpe.br, www.cin.ufpe.br/~esa2

2. Research’s approach • Hypothesis • Software reuse processes present gaps • Development for and with reuse • Different emphasis …. • Domain analysis… Domain Design….Domain Implementation • Development for • Development with • Different trends • Domain Engineering (the begin) • Software Product-Line (currently) • Object of study • 11 reuse processes – State-of-the-Art • Research approach • Analysis of the state-of-the art • Key questions • Requirements for an effective process {draft}

3. RelatedWorks • Previous studies • Arango[1994] • Domain Analysis Methods • Boertin[2001] • Evaluation of Component-Based Development Methods • Stojanovic[2001] • A Methodology Framework for Component-Based System Development Support • Matinlassi[2004] • Comparison of Software Product Line Architecture Design Methods: COPA, FAST, FORM, KobrA, QUADA Our case: software reuse processes

4. Software Reuse: Putting the pieces together Overview

5. Evolution 1960 subroutines 1970 modules 1980 objects 1990 components 2000 SPL

6. DomainEngineering • Domain Engineering (DE) is the activity of collecting, organizing, and storing past experience in building systems or parts of systems in a particular domain in the form of reusable assets, as well as providing an adequate means for reusing these assets when building (i.e., retrieval, qualification, dissemination, adaptation, assembly, and so on) new systems. • Steps: • Domain Analysis • Domain Design • Domain Implementation

7. “A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. Paul Clements and Linda Northrop, 2002 Software Product Line

8. Essential Activities Core Asset Development Product Development Management Domain Engineering Application Engineering

9. Is Product Lines a new approach? • Small-Grained Reuse • Single-System Development with Reuse • Component-Based Development • Reconfigurable Architecture • Release and versions of Single Products

10. Software Reuse Processes State-of-the-art

11. Software Reuse Processes • Two Directions • The beginning • Domain Engineering • End of 99’s • Software Product Lines

12. SoftwareConstruction Using Components[Neighbors, 1980] • Motived by software crisis • First approach for Domain Engineering • Generative programming • Draco’s approach: • Domain Analysis • Domain Language{Domain design} • Software Components • Associated to each object • Reliable after several uses • Source-to-Source Program Transformation • Valid for all implementations of objects

13. Draco’s approach to software development [Neighbors, 1980]

14. Draco’s approach • Key aspects • First Domain Engineering approach • Use of Generative Programming • Use of components • Drawbacks • Hard approach • To design domains • To use transformations • To use the Draco machine • Dificult to apply in the practicecurrently • Domain analysis, scope, architecture ....

15. Reuse-Oriented Software Evolution (ROSE)[Stars, 1993] • Developed by Software Technology for Adaptable, Reliable Systems (STARS) program • Evolution of a previous work - Conceptual Framework for Reuse Processes (CFRP) • Two processes: Reuse Management and Reuse Engineering • Problem: general framework • Motivation • To resolve the gap between the high-level, general framework and the detailed, prescriptive methods

16. Submodels • Organization Management • Domain Engineering • Asset Management • Application Engineering [Stars, 1993]

17. Key aspects • Organizational issues • Maintenance and evolution {reengineering} • Development for and with reuse • Feedback • Drawbacks • Also very general ....for example...

18. Analyze and Model domain activity [Stars, 1993]

19. Analyze and Model domain activity The same in other activities (Develop Software Architecture, Develop Applications Generators, Develop software componentes) [Stars, 1993]

20. Organization Domain Modeling(ODM)[Simos, 1996] • Developed by Software Technology for Adaptable, Reliable Systems (STARS) program • Process Model to Domain Engineering{development with reuse is not considered!!} • General Process (509pp.) • Cases: HP, Lockheed Martin, Rolls-Royce, Logicon • Three phases • Plan Domain • Model Domain • Engineer Asset Base

21. Summary – Until 1997 Processesdo notdefineconcretetechniques tomodelingandimplementationofarchitectureandcomponents!!

22. Reuse-driven Software Engineering Business (RSEB)[Jacobson, 1997] • Developed by software development experts {Jacobson, Griss, Jonsson} • OO method based on: • UML notation • OO Software Engineering • Goal • To facilitate the development of reusable object-oriented software • Development forandwithreuse • Iterative • Use-case centric

23. Key aspects • Variability • Traceability • Drawbacks • Lack of Domain Analysis • Domain scoping • Feature Modeling • FeatuRSEB[Griss , 1998] • RSEB’s extension • Integration between FODA and RSEB

24. Feature-Oriented Reuse Method (FORM)[Kang, 1998] • FODA extension • Thesis • there are many attempts to support software reuse(two directions) • exploratory research • theoretical research • ... there arefew efforts to develop systematic methods for discovering commonality and using this information to engineer software for reuse...

25. The Process

26. Key aspects • Development for and with reuse • Domain analysis well explored • Drawbacks • Specification, Design, Implementation, Packing of components • Application development few explored

27. Summary – Until 1998 Processesrelated toDomain Engineering

28. Product Line Software Engineering (PuLSE)[Bayer, 1999] • Motivation • Domain engineering problems • Are methods effective in the practice? • Domain x Products{domain litle economic basis} • Lack of operational guidance • Lack of methodologies to develop and deploysoftware product line

29. ...existing methods have been either not flexible enough to meet the needs of various industrial situations, or they have been too vague, not applicable without strong additional interpretation and support. A flexible method that can becustomized to support various enterprise situations withenough guidance and support is needed....(Bayer, pp. 122) ... a lot of work in the literature has focused on the organizational aspect and context for setting up a reusable infrastructure. This body of work often takes forgranted that the technological problems of how to scope,model and architect the infrastructure have been solved. Wedo not think this is the case and hence feel strongly that this is the wrong approach.....(Bayer, pp. 122)

30. The Process [Bayer, 1999] Customizing PuLSE Initialization PL Infr. Evol. Mang. Scoping PL Infrastructure Construction Modeling Architecting PL Infrastructure Usage Instantiating Evolving & Mgmt. Maturity Scale Organization Issues Project Entry Points

31. Key aspects • Initial direction for software product line development • Development for and with reuse • PuLSE is the result of a bottom-up effort • Lessons learned from technology transfer • Drawbacks • How toperform the specification, design, implementation of the components? {details about it}

32. Komponentenbasierte Anwendungsentwicklung (KobrA)[Atkinson, 2000] • Several software engineering techniques • Frameworks, architecture, cbd, spl • PuLSE’s extension • Difficult to use in small organizations • Very general{a lot of artifacts} • KobrA • Development for and with reuse • Ready-to-use customization of PuLSE

33. Two activities • Framework engineering • Application engineering • UML’s use – activity, object, statechart...diagrams • Komponent • Specification – external properties {what} • Realization – internal properties {how}

34. Gaps • Domain analysis in large scale • Domain architecture • Variability {decision model}

35. A Component-Oriented Platform Architecting Method Family for Product Family Engineering (CoPAM) [America, 2000] Product Product Product Product Engineering Method Product Engineering Method Product Engineering Method Product Engineering Method Family [America, 2000]

36. Product Product Product Product Family Family Engineering Method [America, 2000]

37. Product Product Product Product Family Product Family Product Family Family Engineering Method Family Engineering Method Family Engineering Method Family Engineering Method Family [America, 2000]

38. Common uses: • Product families: • Consumer electronics • professional systems America said: ...the reason for this is that such a large population only makes sense if the products have enough in common...and the organization is able to coordinate the marketing, development and related to aspects [America, 2000]

39. Based on • RUP, RSEB, PuLSE • Author’s experience • Development for and with reuse • Platform engineering and Product engineering • Very general [America, 2000]

40. The PECOS Software Process [Winter, 2002] • Project between industry and university • To enable cbd for embedded systems • Motivation • Embedded systems • Monolithic • Platform-dependent • Goal • To develop families of PECOS devices • To reuse them in application development

41. Component-Based Development • During application composition • Profiling • Non-functional informations • CPU usage, memory Requirements Elicitation Interface Specification • Application Development Implementation Test & Profiling Identify Components Compose Components Documentation & Release Query Components Select

42. Gaps • How to perform requirements analysis? • How are the contracts specified? • How are the components identified? • Drawback • Lack of development for reuse • Component development{analysis, architecture}

43. Summary

44. The framework [Almeida, 2004]

45. Questions • Development for reuse • How to achieve efficient domain analysis? • Planning • Scoping • Modeling{commonalities, variability} • Features x use case • Decision model x feature model

46. How to perform domain design? • Architecture • Specific to a domain{styles, ADL} • MDA • Service • Identification, Specification {OCL, JML}, Design{components} • Architecture {quality attributes, documentation, evaluation}

47. How to perform domain implementation? • Incremental x Generative • Implementation, documentation and packing {components} • Variability{implementation}

48. Requirements {initial version} • Development for reuse • Domain analysis • Planing • Scoping • Modeling • Domain design • Design architecture • Identification, Specification, Design{components} • Architecture:evaluation, quality attributes, documentation

49. Requirements {initial version} • Domain implementation • Implementation, Packing, Variablity • Development with reuse • Traceability • Cost Models • Metrics • Reengineering • Support Environment

50. Future Work – RiSE’s Process • Write a paper: • Towards an efficient software reuse process • History • Questions • Requirements