Eduardo Cruz Vaninha Vieira Eduardo Almeida Silvio Meira Ana Carolina Salgado Patrick Brézillon
ecrs@cin.ufpe.br vvs@cin.ufpe.br esa2@cin.ufpe.br srlm@cin.ufpe.br acs@cin.ufpe.br
brezil@poleia.lip6.fr
Modeling Context in Software Reuse Modeling Context in Software Reuse
Roskilde, Denmark August 2007
Outline
¾Motivation and Problem Statement
¾Our Proposal
¾Context in Software Engineering
¾Modeling Context
¾Final Considerations
Outline
¾Motivation and Problem Statement
¾Our Proposal
¾Context in Software Engineering
¾Modeling Context
¾Final Considerations
Software Reuse
¾Main purpose
9No need to write from scratch every time 9Developers can use pre-built components
¾Benefits
developer’s efforts and software costs software quality
¾Example: Security Systems
Authentication
Components Repositories
¾A large number of software components are now available in repositories
¾There exists already a component market
ComponentSource.com
¾ Pioneer of the market for reusable software components (founded in 1995)
¾ Thousand of components can be
assembled in different
contexts
Koders.com
¾User can have access to 700 million lines of code
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
9 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,
So, the problem is…
¾Too much information available
¾Too few contextual information to define the appropriate
component to
support user’s task
Outline
¾Motivation and Problem Statement
¾Our Proposal
¾Context in Software Engineering
¾Modeling Context
¾Final Considerations
Context in Software Engineering
¾In software engineering, context is identified by contextual elements
¾Contextual elements are related to:
9Roles of each user
9Tasks in the software development process 9Asset themselves
9The User Environment
Focus on the User Role
¾Roles considered to define contextual elements:
9Project manager 9Software Architect 9Software Developer
9Configuration Manager
9Software Quality Engineer 9Software Tester
Focus on the Task at Hand
¾Tasks considered to define contextual elements:
9Requirements Elicitation 9Software Design
9Software Programming 9Software Testing
9Project Management
9Configuration Management 9Software Quality Assurance
Focus on the Aset Type
¾Asset types considered to define contextual elements:
9Requirements 9Source Code
9Unit Test Cases 9Project Plan
9Configuration Management Plan 9Quality Assurance Plan
Focus on the User Environment
¾User Environments types considered to define contextual elements:
9Programming IDE 9Text Processor
9UML Modelling Tool 9Web Interface
Outline
¾Motivation and Problem Statement
¾Our Proposal
¾Context in Software Engineering
¾Modeling Context
¾Final Considerations
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
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
¾Examples
of contextual attributes
related
to the user role level of abstraction
Examples
¾Some examples of how to use the modeled context attributes
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
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
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
Outline
¾Motivation and Problem Statement
¾Our Proposal
¾Context in Software Engineering
¾Modeling Context
¾Final Considerations
Our Goals
¾Make Context Explicit
¾Change the paradigm {problem,solution} for {problem, context, solution}
¾Apply context to improve software reuse
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)
B.A.R.T. Search Engine
¾ B.A.RT. - Basic Asset Retrieval Tool
¾ Asset is any reusable software artifact
9 Components, framework, documents, source code, tests
¾ Currently do not consider the context of use
¾ Multiple Search Clients
9 Eclipse IDE (Java Source Code) 9 Microsoft Word (Word Documents) 9 Microsoft Visual Studio (C#)
9 Web (java, pdf, doc, ppt, xls, c#)
SOME EXAMPLES OF OUR SEARCH CLIENTS
Contextual Elements
Management Through
Incremental Knowledge Acquisition
Context Context Manager Manager Methodology
Methodology
Context Context
Model Model
Context Context Aware Aware System System B.A.R.T.
B.A.R.T.
System System B.A.R.T. + CEManTIKA
Knowledge relevant to the focus but not directly considered in it
Stored in a CKB, supports PC building but it’s not used in the task
Part of context that has no relation with the current focus
It’s not considered by the context manager Part of CK that is invoked, organized, structured and situated according to a focus. Used to support the task at hand.
Built and managed by the context manager
“Context is always related to a focus”
Refers to what the user is doing Ex. task, step in a problem solving
Conceptual View of Context
(Brézillon and Pomerol, 1999)
Focus
Proceduralized Context
Contextual Knowledge
Software
Development
Expertise: Java; UML
Team: Carlos and André
Presence: on; off
schedule expertise
experience
reputation
ability team
presence
availability
Marital State
External Knowledge
Proposed Architecture
¾Create Software Components
Software Component Repository
COMPONENT X
COMPONENT Y
Proposed Architecture
¾Create Contextual Elements
Context
LANGUAGE
AUTHOR
LICENSE
Proposed Architecture
¾ Define Focus and Group Contextual Elements
Context Manager
LANGUAGE
AUTHOR
LICENSE
Focus: Artifacts by Language and
Author
Proposed Architecture
¾Apply Context Elements to Software Components
COMPONENT X
COMPONENT Y
LANGUAGE: FRENCH AUTHOR: PIERRE
LICENSE: GPL
Proposed Architecture
¾Select Artifacts by Focus
Software Component Repository
COMPONENT X
COMPONENT Y
LANGUAGE: FRENCH AUTHOR: PIERRE
LICENSE: GPL
Context Manager
LANGUAGE
AUTHOR
LICENSE
Artifacts by Language
and Author
?
Contextual elements are
stored apart and
related to software
assets
depending on the focus
Architecture
Outline
¾Motivation and Problem Statement
¾Our Proposal
¾Context in Software Engineering
¾Modeling Context
¾Final Considerations
Some Lessons Learned
¾ Information might be implicitly extracted by the system
9 i.e.: User environment, programming language
¾ Information might also be explicitly asked for the user
9 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.
Main Points
¾Contextual elements might be:
9The User task. (Write a Program or Write a Document)
9The User Role. (Project Manager or Programmer)
9Asset Attributes. (Author or Language)
9User Environment. (Programming IDE or Text Editor)
¾With explicit context we can improve the semantic interaction between the user and the system
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:
9a domain-dependent part represented by the contextual elements
9a domain-independent part with the context manager and all its mechanisms
Eduardo Cruz Vaninha Vieira Eduardo Almeida Silvio Meira Ana Carolina Salgado Patrick Brézillon
ecrs@cin.ufpe.br vvs@cin.ufpe.br esa2@cin.ufpe.br srlm@cin.ufpe.br acs@cin.ufpe.br
brezil@poleia.lip6.fr
Modeling Context in Software Reuse Modeling Context in Software Reuse
Roskilde, Denmark August 2007
Acknowledgments
¾LIP6 - Laboratoire d'informatique de Paris 6, France
¾CESAR – Recife Center for advanced Studies, Brazil
