The challenges and opportunities in open source reuse

236 views
194 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
236
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The challenges and opportunities in open source reuse

  1. 1. The  challenges  and  opportuni2es   in  open  source  reuse   Ivica  Crnkovic   Mälardalen  University,  Sweden   www.idt,mdh.se/~icc,  Ivica.crnkovic@mdh.se     OPEN-­‐SME  Project  –  Athens  Workshop      17  February  2012  
  2. 2. Before  the  start….  June  25-­‐28,  2012,  Ber2noro,  Italy  CBSE:  15th  ACM  SigSoH  InternaIonal  Symposium  on  Component-­‐Based  SoHware  Engineering  QoSA:  8th  ACM  SigSoH  InternaIonal  Conference  on  Quality  of  SoHware  Architecture  ISARCS:  3rd  ACM  SigSoH  InternaIonal  Symposium  on  ArchitecIng  CriIcal  Systems    ROSS:  Workshop  on  Reusing  Open-­‐Source  SoHware  Components    OPEN-­‐SME  workshop  @  presentaIon    Invited  papers  –  published  in  ACM  Digital  Library    Important  days  :              Papers  submissions:  March  7th        NoIficaIons:  April  7th        Camera-­‐ready  submission:  April  28          hWp://opensme.eu/ross       2013-­‐02-­‐06   2  
  3. 3. Open  Source  &  Free  and  Open  Source  •  Open-­‐source  soHware  (OSS)   –  soTware  that  is  available  in  source  code  form.  •  Free  and  open-­‐source  soHware  (F/OSS,  FOSS)  (free/libre/open-­‐ source  soTware  (FLOSS))   –   soTware  that  is  both  free  and  open  source   •  1.  Free  RedistribuIon   •  2.  Source  Code   •  3.  Derived  Works   •  4.  Integrity  of  The  Authors  Source  Code   •  5.  No  DiscriminaIon  Against  Persons  or  Groups   •  6.  No  DiscriminaIon  Against  Fields  of  Endeavor   •  7.  DistribuIon  of  License   •  8.  License  Must  Not  Be  Specific  to  a  Product   •  9.  License  Must  Not  Restrict  Other  SoHware   •  10.  License  Must  Be  Technology-­‐Neutral  2013-­‐02-­‐06   3  
  4. 4. Reusing  SoTware   Design  PaWerns   PragmaIc  source-­‐code  reuse   (cut/paste)   Component-­‐based     development   Program  Libraries   ApplicaIon  Product  Lines   Service-­‐oriented  systems   Model-­‐based  development  2013-­‐02-­‐06   4  
  5. 5. Reusing  SoTware   Design  PaWerns   PragmaIc  source-­‐code  reuse   (cut/paste)   Component-­‐based     development   Program  Libraries   Service-­‐oriented  systems   ApplicaIon  Product  Lines   Model-­‐based  development  2013-­‐02-­‐06   5  
  6. 6. Applica2on  development  reusing   components   Requirements   Design Implementa2on   Integra2on   Test   Selec2on  of   exis2ng   components   Release   Maintenance2013-­‐02-­‐06   6  
  7. 7. Systema2c  Reuse   Applica2on  Engineering   Requirements   Analysis   Applica2on   Design   Applica2on   Implementa2on  Customer    requirements   Domain  Analysis   Domain  Design   Domain   Implementa2on   Domain  Engineering   2013-­‐02-­‐06   7  
  8. 8. System  development     reusing  components   Requirements   Design   Implementa2on   Test   F Release   Find   I Select   N Maintenance   D Adapt   Requirements   Requirements   Verify   Design   Design   Store   Implementa2on   Implementa2on   Test   Test   Release   Release   Requirements   Requirements   Requirements   Maintenance   Maintenance   Design   Design   Design   Implementa2on   Implementa2on   Implementa2on   Test   Test   Test   Release   Release   Release   Maintenance   Maintenance   Maintenance  2013-­‐02-­‐06   8  
  9. 9. Where  are  the  challenges?  •  Challenges   Requirements* Design* Implementaon* App –  Business   li cao n *D e Test* velo pme nt* Find* Release* –  Organiza2onal   Select* Adapt* Maintenance* Requirements* Requirements* Verify* –  Technical   Design* Design* Implementaon* Implementaon* Test* Test* Store* Domain *Dev elop men Release* t* •  Technology   Requirements* Release* Requirements* Requirements* Maintenance* Maintenance* Design* Design* Design* Implementaon* Implementaon* Implementaon* •  Process   Test* Test* Test* Release* Release* Release* Maintenance* Maintenance* Maintenance* The  challenges  are  in  the  interface  between  domain  and  applica2on  engineering  2013-­‐02-­‐06   9  
  10. 10. Applica2on  Engineering  Details     (I)  Requirements  Engineering   Requirement Collection Requirements Reuse Analysis and Adaptation Requirement Modify Analysis Requirement Identification of [Component [Requirement Candidate Components not found] could be changed] [Component found] Requirement cannot be changed Mark requirement as "non-reusable" [Remaining requirements] [No more requirements]2013-­‐02-­‐06   10  
  11. 11. Applica2on  Engineering  Details     (I)  Requirements  Engineering  -­‐   challenges  You  need:  •  A  good  tool  to  find  components   Requirement Collection that  fits  to  the  requirements  •  Not  only  func2onal  requirements   Requirements Reuse Analysis and Adaptation but  non-­‐func2onal  (performance,   Requirement Modify reliability,  resource  requirements)   Analysis Requirement•  Maybe  you  need  test  the     Identification of [Component [Requirement component  with  others   Candidate Components not found] could be changed] [Component found] RequirementBasic  requirements:   cannot be changed•  A  repository  with  components   Mark requirement as•  Specifica2on  –  metadata   "non-reusable"•  Tests  •  Requirement  specifica2on   [Remaining requirements]•  Contract  (what  is  needed,  what  is   [No more requirements] provided)   2013-­‐02-­‐06   11  
  12. 12. Applica2on  Engineering  Details     (II)  Architectural  Design   Overall System Architecture Detailed System Architecture2013-­‐02-­‐06   12  
  13. 13. Applica2on  Engineering  Details     (II)  Architectural  Design  -­‐  challenges  Maybe  the  overall  architecture  already  exists?     Overall SystemMaybe  some  packages  (a  set  of   Architecturecomponents)  already  exists?     Detailed SystemChallenges:   Architecture•  Should  we  save  some   architectural  paiers?  •  Should  we  also  save  packages   and  composite  components  as   reusable  units?   2013-­‐02-­‐06   13  
  14. 14. Applica2on  Engineering  Details     (III)  Detailed  Design   Conceptual Architectural Design Deployment Architecure level Analysis [No] [OK] Detailed Identification Design [Component Create New of Candidate not found] Component Components [Component found] [Yes] [No] Detailed   Deatiled Analysis [OK] [Not Feasible] [Not OK] [Feasible Design]2013-­‐02-­‐06   14  
  15. 15. Applica2on  Engineering  Details     (III)  Detailed  Design  -­‐  challenges  You  need:   Conceptual ArchitecturalA  good  tool  to  find  components   Design Deploymentthat  fits  to  the  specifica2ons   ArchitecureNot  only  func2onal  specifica2on   level Analysis [No]but  non-­‐func2onal  (performance,   [OK]reliability,  resources)  Maybe  you  need  test  the     Detailed Identificationcomponent  with  others   Design of Candidate [Component Create New not found] Component   ComponentsChallenges:   [Component found]A  repository  with  components   [Yes] [No]Specifica2on  –  metadata  Tests   Detailed   DeatiledContract  (what  is  needed,  what  is  provided)   Analysis [OK] [Not Feasible]Efficient  component  browser   [Not OK] [Feasible Design] 2013-­‐02-­‐06   15  
  16. 16. Applica2on  Engineering  Details     (IV)  Implementa2on/Realiza2on   Component Selection [Not Found] [Found] Search somewhere else Component Repository [Adaptation needed] [Found] [Adaptation not needed] [Not Found] In-house development Adaptation Verification2013-­‐02-­‐06   16  
  17. 17. Applica2on  Engineering  Details     (IV)  Implementa2on/Realiza2on  -­‐   challenges  Challenges:  Search  someone  else   Component Selection [Not Found] Where?   Search [Found] Is  that  a  maier  of  DE?   Component somewhere elseIn  house  development   Repository Who  is  doing  that?   DE  à  repository   [Adaptation needed] [Found] Internal  development   [Adaptation not needed] [Not Found] Feedback  to  DE?  AdaptaIon:   In-house development Who  is  doing  that?   DE  à  repository   Internal  adapta2on   Adaptation Verification New  requirements  to  DE?   2013-­‐02-­‐06   17  
  18. 18. Applica2on  Engineering  Details     (VI)  Test     Test case Generation Test case Execution Test result Analysis [More tests remaining] [Bugs Debug and Identify found] faulty component [No bugs found] Fixing the Component Regression Testing [No more test cases]2013-­‐02-­‐06   18  
  19. 19. Applica2on  Engineering  Details     (VI)  Test  -­‐  Challenges  Challenges:  Are  tests  already  available?   Test case Generation How  to  pickup  all  tests  needed  Faulty  components   Test case•  Should  DE  be  informed?     Execution•  Should  DE  contain  list  of  known   Test result errors?   AnalysisFixing  the  component:   [More tests remaining] Who  is  doing  that?   [Bugs found] Debug and Identify faulty component DE  à  repository   Fixing the Internal  fix     [No bugs found] Component Sending  fixed  components   to  DE?   Regression Testing [No more test cases] 2013-­‐02-­‐06   19  
  20. 20. Applica2on  Engineering  Details     (VII)  Maintenance   Select replacement New Components Component Adaptation Integration2013-­‐02-­‐06   20  
  21. 21. Applica2on  Engineering  Details     (VII)  Maintenance  -­‐  challenges   Select replacement New Components ComponentChallenges:  Who  is  responsible  for  big  fixing  in  components?  •  DE?    Who  is  paying  for  that?  How   Adaptation can  DE  repeat  the  error?  Who  is  managing  error  reporIng  system?   Integration 2013-­‐02-­‐06   21  
  22. 22. Challenges  and  needs  •  Interface  between  domain  engineering  and   applica2on  engineering  is  crucial   –  Business  issues   –  Agreement  of  responsibility   OPEN-­‐SME   –  Implementa2on  of  an  efficient  process   objec2ves   –  Use  of  efficient  tools   •  Repository   •  Browser   •  Development  tools    2013-­‐02-­‐06   22  

×