Modeling Context in Software Reuse

Transcription

1 Roskilde, Denmark August 2007 Modeling Context in Software Reuse Eduardo Cruz Vaninha Vieira Eduardo Almeida Silvio Meira Ana Carolina Salgado Patrick Brézillon

2 Outline Motivation and Problem Statement Our Proposal Context in Software Engineering Modeling Context Final Considerations 2

3 Outline Motivation and Problem Statement Our Proposal Context in Software Engineering Modeling Context Final Considerations 3

4 Software Reuse Main purpose No need to write from scratch every time Developers can use pre-built components Benefits developer s efforts and software costs software quality Example: Security Systems Authentication Authorization 4

5 Components Repositories A large number of software components are now available in repositories There exists already a component market 5

6 ComponentSource.com Pioneer of the market for reusable software components (founded in 1995) Thousand of components can be assembled in different contexts 6

7 Koders.com User can have access to 700 million lines of code 7

8 Problem with Components Repositories More components you have, more difficult to find the right one you need Not easy to find useful information without the context of the user and the task at hand Components are stored out of their contexts of use Context of the component developer may be different from context of who will use component Components must be searched and assembled not only by their content, but also by their context of use 8

9 So, the problem is Too much information available Too few contextual information to define the appropriate component to support user s task 9

10 Outline Motivation and Problem Statement Our Proposal Context in Software Engineering Modeling Context Final Considerations 10

11 Our Goals Make Context Explicit Change the paradigm {problem,solution} for {problem, context, solution} Apply context to improve software reuse 11

12 Our Proposal Apply the concepts of context-management to improve software reuse in the software development cycle. Integrate a context manager (CEManTIKA) with a software component manager (BART) 12

13 B.A.R.T. Search Engine B.A.RT. - Basic Asset Retrieval Tool Asset is any reusable software artifact Components, framework, documents, source code, tests Currently do not consider the context of use Multiple Search Clients Eclipse IDE (Java Source Code) Microsoft Word (Word Documents) Microsoft Visual Studio (C#) Web (java, pdf, doc, ppt, xls, c#) 13

14 SOME EXAMPLES OF OUR SEARCH CLIENTS 14

15 B.A.R.T. + CEManTIKA Contextual Elements Management Through Incremental Knowledge Acquisition Methodology Context B.A.R.T. Aware System Context Model Context Manager 15

16 Conceptual View of Context (Brézillon and Pomerol, 1999) Software Development Focus presence team Knowledge Part of CK relevant that is invoked, Part of context that has to the no focus organized, relation but with not Context is always related to a focus structured directly and situated the current considered according focus it to a focus. Used to support the task at hand. Refers to what the user is doing Stored in a CKB, supports PC building but It s not Ex. considered task, step in by a the problem context solving manager Built and managed it s not used by the in the context task manager expertise availability schedule Team: Carlos and André Proceduralized Context Contextual Knowledge Expertise: Java; UML ability Presence: on; off reputation experience External Knowledge Marital State weight age Last vacation 16

17 Proposed Architecture Create Software Components COMPONENT X COMPONENT Y Software Component Repository 17

18 Proposed Architecture Create Contextual Elements LANGUAGE AUTHOR LICENSE Context Manager 18

19 Proposed Architecture Define Focus and Group Contextual Elements LANGUAGE AUTHOR Focus: Artifacts by Language and Author LICENSE Context Manager 19

20 Proposed Architecture Apply Context Elements to Software Components AUTHOR: PIERRE COMPONENT X LANGUAGE: FRENCH LICENSE: GPL COMPONENT Y Software Component Repository 20

21 Proposed Architecture Select Artifacts by Focus AUTHOR: PIERRE LANGUAGE LICENSE AUTHOR Context Manager Artifacts by Language and Author? COMPONENT X LANGUAGE: FRENCH LICENSE: GPL COMPONENT Y Software Component Repository 21

22 Architecture Contextual elements are stored apart and related to software assets depending on the focus 22

23 Outline Motivation and Problem Statement Our Proposal Context in Software Engineering Modeling Context Final Considerations 23

24 Context in Software Engineering In software engineering, context is identified by contextual elements Contextual elements are related to: Roles of each user Tasks in the software development process Asset themselves The User Environment 24

25 Focus on the User Role Roles considered to define contextual elements: Project manager Software Architect Software Developer Configuration Manager Software Quality Engineer Software Tester 25

26 Focus on the Task at Hand Tasks considered to define contextual elements: Requirements Elicitation Software Design Software Programming Software Testing Project Management Configuration Management Software Quality Assurance 26

27 Focus on the Aset Type Asset types considered to define contextual elements: Requirements Source Code Unit Test Cases Project Plan Configuration Management Plan Quality Assurance Plan Architecture Documentation 27

28 Focus on the User Environment User Environments types considered to define contextual elements: Programming IDE Text Processor UML Modelling Tool Web Interface 28

29 Outline Motivation and Problem Statement Our Proposal Context in Software Engineering Modeling Context Final Considerations 29

30 Modeling Context For our domain (Software Reuse) we considered context related to: user role, user environment, user task and the assets themselves There are many ways to model the problem. Our approach focused on modeling using the user role to define a user centered model 30

31 Modeling Context Steps 1. Identification of relevant issues 1. Roles 2. Groups of activities for each role 3. Levels of abstraction for artifacts 4. External knowledge for the domain 5. Contextual Knowledge 2. Group Contextual Elements 3. Define possible focus to groups of contextual elements 4. Use the focus to match the user context 31

32 Examples of contextual attributes related to the user role level of abstraction 32

33 Examples Some examples of how to use the modeled context attributes 33

34 EXAMPLE - 1 User Role Programmer User Environment Eclipse IDE Activity Debugging Software Contextual elements identified Programming language=java; Project=JContactPhone; License=GPL; Domain=Mobile Conclusion A programmer debugging software needs examples of code in java Mobile (J2ME) code with GPL license 34

35 EXAMPLE - 2 User Role Architect User Environment Borland Together Activity Modeling a class diagram Contextual elements identified UML Diagram=Class; Project=ChessGame; Domain=Games; GameType=BoardGame Conclusion An architect drawing a class diagram for a board game needs examples of diagrams in the same domain and of the same type 35

36 EXAMPLE - 3 User Role Test Engineer User Environment Microsoft Word Activity Writing Security Test Project Contextual elements identified Domain=Infrastructure/Security; Conclusion An Test Engineer is writing a test project and needs examples of test cases related to test security properties of a system 36

37 Outline Motivation and Problem Statement Our Proposal Context in Software Engineering Modeling Context Final Considerations 37

38 Some Lessons Learned Information might be implicitly extracted by the system i.e.: User environment, programming language Information might also be explicitly asked for the user i.e.: The User Role It is easier to model and identify attributes It is harder to model and identify activities. The user activity history should be considered. 38

39 Main Points Contextual elements might be: The User task. (Write a Program or Write a Document) The User Role. (Project Manager or Programmer) Asset Attributes. (Author or Language) User Environment. (Programming IDE or Text Editor) With explicit context we can improve the semantic interaction between the user and the system 39

40 Perspectives / Future Work Model the contextual elements according to CEManTIKA s generic context model Define rules for context conflict resolution Two parts in the context: a domain-dependent part represented by the contextual elements a domain-independent part with the context manager and all its mechanisms 40

41 Roskilde, Denmark August 2007 Modeling Context in Software Reuse Eduardo Cruz Vaninha Vieira Eduardo Almeida Silvio Meira Ana Carolina Salgado Patrick Brézillon

42 Acknowledgments LIP6 - Laboratoire d'informatique de Paris 6, France CESAR Recife Center for advanced Studies, Brazil 42