ISSN 1751-8806 Story-driven approach to software evolutionpdfs.semanticscholar.org/5e7d/e42e09288818d2aa... · Various process models [3–7] supporting the evolution of software

304

& T

www.ietdl.org

Published in IET SoftwareReceived on 31st July 2007Revised on 22nd February 2008doi: 10.1049/iet-sen:20070095

In Special Section on Software Evolvability

ISSN 1751-8806

Story-driven approach to software evolutionJ. Rilling1 W.J. Meng1 R. Witte1 P. Charland2

1Department of Computer Science and Software Engineering, Concordia University, Montreal, Canada2System of Systems Section, Defence R&D Canada – Valcartier, Quebec, CanadaE-mail: [email protected]

Abstract: From a maintenance perspective, only software that is well understood can evolve in a controlled andhigh-quality manner. Software evolution itself is a knowledge-driven process that requires the use and integrationof different knowledge resources. The authors present a formal representation of an existing process model tosupport the evolution of software systems by representing knowledge resources and the process model usinga common representation based on ontologies and description logics. This formal representation supports theuse of reasoning services across different knowledge resources, allowing for the inference of explicit andimplicit relations among them. Furthermore, an interactive story metaphor is introduced to guide maintainersduring their software evolution activities and to model the interactions between the users, knowledgeresources and process model.

1 IntroductionSoftware evolution is a knowledge-driven process, withknowledge being continually integrated from differentsources (including source code repositories, documentation,test case results) and at different levels of abstraction (fromsingle variables to complete system architectures). Formaintainers to perform and complete a particularmaintenance task, they typically need to use and interactwith various tools and techniques (e.g. parsers, debuggers,source code analysers, visualisation tools). Identifyingknowledge resources that are applicable in a givenmaintenance context can become a major challenge forsoftware maintainers. Furthermore, there often exist non-obvious direct or indirect dependencies among theseknowledge resources that require maintainers to follow acertain sequence of steps in order to accomplish a particularevolution task. As a result, both maintainers andorganisations are facing the challenge of deriving andapplying procedures that provide for guidance to utilisethese existing resources more efficiently [1–3].

Various process models [3–7] supporting the evolution ofsoftware have been introduced. Common to most softwareand, more specifically, software evolution process models, isthat they share a generality in abstracting and describingactivities to be performed and resources to be used as part of

he Institution of Engineering and Technology 2008

the process. This generality can become, from anorganisational viewpoint, a major challenge in adopting them.Organisations often have to adapt their own internalprocesses to support a particular process model, and they alsoneed to modify and customise this process model so that itcan be supported or sustained as part of a largerorganisational context. Organizations are often left alone inestablishing context-awareness and customization of processmodels. From an organizational perspective, it is possible todefine processes in such a detail that the resulting model notonly describes the required maintenance activities, but alsoresources that must be employed. However, these well-defined process models are typically based on the assumptionthat resources and the knowledge provided by these resourcesare known at the process specification time, resulting in astatic (closed world) resource and knowledge allocation. Thisclosed world assumption, however, restricts the ability tointegrate newly gained knowledge and resources within theseprocess models. There has been little work in examining howthese resources can be applied and used collaboratively tosupport a specific software maintenance task [8]. Maintainersare often left with no guidance on how to complete aparticular task within a given context, using a set of availableresources (e.g. tools, artefacts). Current research in softwareevolution has led to a set of task-specific tools and techniquesthat are not integrated, due to a lack of integration standardsand frameworks to allow sharing services among them.

IET Softw., 2008, Vol. 2, No. 4, pp. 304–320doi: 10.1049/iet-sen:20070095

IETdoi

www.ietdl.org

The problem of knowledge and process integration is notunique to software maintenance. Other applicationdomains, including Internet search engines (e.g. Google,www.google.com) or online shopping sites (e.g. Amazon,www.amazon.com) are facing similar challenges. Commonto these application domains is that they use differentinformation resources to support users in a given context.For example, during an online shopping session, users willtypically find related information on other relevantproducts, customer reviews, product summaries and so on.Tools and techniques are utilised to enhance the shoppingexperience and facilitate the online shopping process. Thetwo major challenges in applying similar approaches tosupport software evolution are: (1) the lack of formalmodels to represent and link relevant knowledge resourcesand process activities and (2) the resulting lack of a suitablemetaphor to model the interaction between the users, themodel and the relevant resources.

In this research, we focus in particular on modelling theinteractions between the maintainers, a process model andits relevant knowledge resources. The presented research isa continuation of our previous work on modellingprogramme comprehension [9] by introducing a softwareevolution ontology that models both software evolutionprocess specific aspects and knowledge resources relevant tosoftware evolution.

We introduce a novel formal ontological representationthat models and integrates software process specificinformation with software and other knowledge resources(e.g. domain knowledge, documents, user expertise,historical data etc.). The goal of this commonrepresentation is to reduce the conceptual gap caused bythe type of abstractions and languages found in theseartefacts. Having a common ontological representationallows maintainers not only to explore knowledgerelevant to their given task across the different modelledartefacts, but also to enrich their current understandingof a system and share their knowledge. Furthermore,traceability between the software processes andknowledge resources can be established by providingnon-trivial relationships among these artefacts.Ontologies also provide support for extending anexisting knowledge base (KB) to reflect more closely an‘open’ world assumption [10], by allowing for both themodelling of incomplete knowledge and the enrichmentof the KB with newly gained knowledge. Moreover,having a formal ontological representation also allows usto take advantage of automated reasoning servicesprovided by ontology reasoners to infer implicit relations(links) between the processes and knowledge resources.Fig. 1 shows a simplified example that restricts theavailable information resources to tools and tasks.Different strategies (top-down, bottom-up or integratedapproach) are provided to support maintainers in the useof the knowledge resources and to answer questionssuch as:

Softw., 2008, Vol. 2, No. 4, pp. 304–320: 10.1049/iet-sen:20070095

1. Which tools might directly or indirectly be required toperform a particular comprehension task following a top-down approach?

2. Given a current knowledge level acquired using a bottom-up strategy, what are the potential (directly/indirectly) relatedtasks that can be performed?

Our research is not only motivated by this need tosynthesise these different information and knowledgeresources used within our formal framework, but also bythe ability to provide maintainers with a context directlyrelated to a specific process activity. The acceptance of anynew technology or approach is directly dependent ondelivering added benefits to the users or management of anorganisation. For a process environment to be accepted bymaintainers, it is essential that it provides a supportingframework that captures the context in which the processmodel is applied and that it also links resources to theprocess. For the contextual representation, an intuitivevisual metaphor is needed to establish an interaction modelbetween the user and the process model. We introduce astory metaphor that addresses the following three majorissues:

1. a metaphor that is familiar to users;

2. a metaphor that can be mapped closely to the activities ofa software evolution process and its activities;

3. a metaphor that can be expressed at different levels ofabstraction to reflect the different granularity of knowledgeand context that need to be represented.

The story metaphor not only models the interactionsbetween the users and the ontological representation interms of process context and resources, but it also providesthe basis for developing a supporting environment.

The overall goal of our research is not to provide a concretesolution to a specific software evolution activity, but rathermake use of explicit and implicit knowledge found in thesoftware maintenance domain. We focus on the integration

Figure 1 Conceptual model

305

& The Institution of Engineering and Technology 2008

306

& T

www.ietdl.org

of this knowledge within the maintenance process byestablishing traceability links between the process activitiesand applicable resources at the knowledge level, andmodelling the interaction between the users and the process.

Our approach differs from existing work oncomprehension models [11–13], tool integration [8, 14],and software evolution related process models [4–7, 15] inseveral important aspects.

1. We introduce a formal ontological representation basedon description logics (DL) to support the modelling,integration and linking of processes (process activities) andknowledge resources relevant to these processes.

2. The ability to reason about knowledge modelled using thisontological representation to infer explicit and implicitknowledge, in order to provide an active and contextsensitive guidance during a software evolution process. Thisincludes knowledge inference across multiple sub-ontologies and the ability to model incomplete knowledge.

3. An interactive story metaphor was adopted to model thedynamic interaction aspects between the users and thecomprehension process.

4. An environment utilising the modelled knowledge,process and user interaction to guide maintainers duringsoftware maintenance tasks.

The remainder of the paper is organised as follows: Section 2provides a brief review of existing software evolution processmodels and their limitations. Section 3 introduces thebackground related to web ontology language (OWL)ontologies and inference services provided by ontologicalreasoners. Section 4 introduces the conceptualisation ofsoftware evolution and its corresponding ontological model.Section 5 introduces the story metaphor used to model theinteraction between the users and the process. Section 6discusses the implementation and validation issues,followed by Section 7 with the related work. Conclusionsand future work are outlined in Section 8.

2 Software evolution processmodelsHistorically, software lifecycle and process models havefocused on the software development cycle. However, withmuch of a system’s operational lifetime cost occurringduring the maintenance phase, this should be reflected inboth the development practices and process modelssupporting maintenance activities. One approach to modelsoftware maintenance is to include software maintenanceaspects as part of the total system life cycle/process model,as suggested, for example, in [4, 7]. Other approaches tomodel software maintenance include deriving maintenance-specific process models. Among these maintenance-specific


models are the quick-fix, iterative enhancement, full-reusemodel [4], the staged model [5], the SEI CMMI model[6], and the IEEE Std 14764-2006 – Software Life CycleProcesses – Maintenance [7].

One of the challenges in applying these models is thatvarious aspects can affect software evolution [12, 16, 17],making it an inherently complex and difficult problem toaddress. Some of these aspects influencing softwareevolution include a user’s comprehension ability (e.g.experience, knowledge background), the characteristics of asoftware system to be maintained (e.g. its applicationdomain, size and complexity), the maintenance task itselfto be performed (e.g. adaptive, corrective or perfectivemaintenance), as well as the tools and software artefactsavailable to support the evolution.

Common to most existing process models, includingevolution models, is that they do not specify how anyavailable supporting resources (tool, system, user expertise,software artefacts etc.) should be integrated within theprocess in a given context. Current research in softwaremaintenance focuses mostly on providing conceptualguidance (such as the documented standards) or ondeveloping tool support to address some specific aspects ofa software maintenance task. An example of such a processmodel is the IEEE Std 14764-2006 [7] that lists anddescribes activities and their sub-activities, referred to astask-steps, as part of the process model. However, thestandard provides only limited or no details on howto implement or perform the activities and task-stepsspecified in it.

Common observations that can be made from mostexisting software evolution process models are:

† They tend to provide only general descriptions of the stepsinvolved in a process, lacking details or guidelines on how tocomplete these steps in a given task and/or organisationalcontext.

† They are limited in their ability to provide a cohesiveintegration of existing knowledge resources (e.g. userexpertise, source code information, tools) and newly gainedknowledge (e.g. experienced gained from previouslyperformed maintenance tasks) within the process.

† Lack of tool support that can provide users with an active,context-driven guidance during the comprehension process,to help reduce their cognitive load.

3 Ontologies and reasoningIntuitively, maintainers perform various activities whilemaintaining a software product. These activities includeunderstanding, conceptualising and reasoning about thesoftware to be maintained. Therefore support fordeveloping a user’s mental model during software evolution


IETdoi

www.ietdl.org

is needed to assist and improve human thinking processes.Research in cognitive science has suggested that mentalmodels may take many forms, but the content normallyconstitutes an ontology [18].

Ontologies have their origins in philosophy, whereontologies correspond to a theory about the nature ofexistence and the categories of things that exist [19]. Incomputer science, ontology is ‘an explicit specification ofconceptualisation’ [20] to provide a formal model of acertain domain. There exists a variety of ontology languageswith different degrees of formality. Some of theselanguages are based on graphical notations such as semanticnetwork, UML or RDF. Others are based on logic such asDL (e.g. OIL, DAMLþOIL, OWL), rules (e.g. prolog)or first-order logic (e.g. KIF) [10, 21, 22].

DLs are a family of logic-based knowledge representationformalisms [23] that can be distinguished by their formalsemantics and inference services. DLs describe domains interms of TBox (also known as concepts or classes), roles(also known as relationships or properties) and ABox (alsoknown as individuals or instances). Particular DLs can becharacterised by the set of constructors they support forbuilding complex concepts and roles from simpler ones andthe set of axioms available for asserting facts aboutconcepts, roles and individuals [21]. Although DLs havemany applications (e.g. databases, configuration, softwareengineering and natural language processing [23]), they arecurrently best known as the basis for formal ontologicallanguages such as OIL, DAMLþOIL and OWL [21].

3.1 Web ontology language (OWL)

The OWL [21, 24] is the foundation of the semantic web[25], providing machine understandable Web informationto enable automatic processing and integration of Webresources. OWL was created based on Web standards suchas XML and RDF(s) and it exploits SHOIN(D) DL forsupporting greater machine interpretability of Web content[21]. OWL is built on earlier DL-based ontologylanguages OIL and DAMLþOIL and is the currentrecommendation of the World Wide Web Consortium(W3C, http://www.w3.org/) [24]. OWL has threeincreasingly expressive sublanguages: OWL Lite, OWL–DL and OWL Full. We adopted OWL-DL as it providesthe best tradeoff between the expressiveness and reasoningpower.

An OWL ontology can be seen as a DL KB that consistsof DL, TBox and ABox. OWL describes a domain in termsof classes, properties and individuals. OWL ontologies can beconstructed incrementally by first specifying elementarydescriptions, such as simple classes and properties, andthen defining more complex class and property descriptionsinductively through a set of OWL–DL constructors andaxioms. A class description can also be used to definequeries to describe the sets of individuals [23].


OWL ontologies can simply be used as a data storagemedium, similar to traditional databases. However, the useof DL to define the ontological model allows for a moreprecise and expressive representation than traditional datasemantics [23] and is also the foundation for automatedreasoning support. Reasoning is a mechanism to inferimplicitly represented knowledge from the knowledge thatis explicitly represented in a KB [23]. DL has beendesigned to support both TBox (concept) reasoning andABox (individual) reasoning. Typical reasonings for TBoxare satisfiability check to determine whether a description issatisfiable (can have individuals) or subsumption test, toexamine whether one description is more general thananother one [23]. Concepts can be organised into aterminology hierarchy according to their generality throughthe use of subsumption reasoning [23]. Other TBoxreasoning includes classification and consistency check.Basic reasoning for the ABox includes instance checking,that is, whether a given individual is an instance of acertain concept. Additional ABox instance reasonings canbe derived from instance checking, such as instanceretrieval tuple retrieval and instance realisation. For a moredetailed coverage of DL and reasoning services, we referthe reader to [23, 25].

3.2 Process ontology example

In what follows, we briefly illustrate the use of bothontologies and reasoning services on a simplified subset ofour ontological model. Fig. 2 presents a simplified ontologythat consists of four atomic concepts (person, team,organization and project) and three atomic roles (manage,program and work). The ontology is populated with fourindividuals, Mike (person), InfoGlue_001, uDig_001 andDebrief_001 (project).

3.2.1 Defining new concepts: Two new concepts,Manager and Programmer, can be defined to enrichthe existing ontology (Fig. 2). In the following twoexpressions, Manager is first defined as a person who hasmanaged some project; likewise, Programmer can bedefined as a person who has performed some programmingas part of a project. Based on these concept definitions, onecan now verify the following assumptions about a personMike. If the assumption ‘Mike has programmed in acertain project such as Debrief_001’ is true, theassumption that ‘Mike is a programmer’ will also

Figure 2 Simplified partial maintenance ontology

307


308

&

www.ietdl.org

automatically hold.

Manager ; Person u 9manage.Project.

Programmer ; Person u 9program.Project.

3.2.2 TBox reasoning: OWL–DL allows for thespecification of a role hierarchy through the use of thesubproperty axiom. The following example illustrates aTBox classification through the use of such asubPropertyOf axiom. A new role participate canbe defined as a super role of manage and program,denoted as:

manage v participate,

program v participate.

Having such a participate role specified, a newconcept participant can now be defined as a personwho has participated previously in some projects:

Participant ; Person

u 9participate.Project.

Given the above knowledge, the reasoner can now inferthat Manager and Programmer are both subconcepts ofParticipant and therefore all instances of Managerand Programmer become instances of Participant.

OWL–DL also supports transitive roles. Given thetransitive roles P(x,y) and P(y,z) -> P(x,z). InFig. 2, work corresponds to such a transitive role, where aperson works in a team and a team itself works on someprojects. The person works in an organisation relationshipis not asserted, but based on the transitive work role, thereasoner can now infer that all persons who work in a teamalso work for the organisation the team belongs to.

3.2.3 ABox reasoning: In addition to TBox reasoning,ABox reasoning can also be applied to perform instancechecking. For example, Mike is a person andDebrief_001 uDig_001, and InfoGlue_001 arethree different project instances. We can now define a newconcept ExperiencedProgrammer as:

ExperiencedProgrammer;Programmer u

9 �3program.Project.

Given that Mike has programmed in three projectinstances (Debrief_001, uDig_001 and InfoGlue), thereasoner can now automatically infer that Mike is a projectparticipant and also an experienced programmer.

3.2.4 Summary: Based on the above discussion, weadopted OWL–DL as the ontological modelling languagefor our research. OWL–DL representation is applicable tomodel the dynamically evolving software maintenance

The Institution of Engineering and Technology 2008

domain, because of its support for domain knowledgeevolution (concept, role and instance creation andpopulation). In addition, it not only provides a moreprecise and expressive representation of the domain, butalso enables automated reasoning to process the content ofthe represented domain. For a more detailed discussion onOWL ontologies, DL and reasoning, we refer the reader to[23, 24, 26].

4 Unified ontological softwareevolution process modelModels are essentially an abstraction of real and conceptuallycomplex systems to represent their significant features andcharacteristics [27]. For any model to provide addedbenefits, it is essential that the model is being accepted andused by the expected users. In what follows, we introducetwo criteria we applied for modelling software evolutionprocesses and their related knowledge resources.

† Support and adaptability: For a process model to beadopted by an organisation and/or end-user, the model hasto be adaptable to a given organisational structure. It alsohas to provide additional benefits to the user in the form ofproviding guidance in applying the model towards aspecific maintenance task.

† Flexibility and extendibility: Process models have to be ableto adapt to ever changing maintenance contexts andknowledge resources, therefore requiring the ability toevolve over time to reflect these new requirements.

4.1 Conceptualising software evolution

Building a formal ontology for software evolution requires theanalysis of concepts and relations in this discourse domain.From a software practitioner’s perspective, it is thereforeessential that the ontological KB includes and modelsconcepts and roles critical to software evolution processes.Indeed, our conceptualisation work has been influenced byother works in modelling software maintenance [28–30]and the observations of best software maintenancepractices. Our approach to construct this KB is 2-fold: (1)We created sub-ontologies for each of the key discoursedomains, such as tasks, software, documents and tools and(2) we linked them via a number of shared high-levelconcepts, such as artefact, task or tool, which have beenmodelled akin to a (simple) upper level ontology [31].Fig. 3 provides a simplified view of the resulting meta-model, focusing only on the major concepts and their roles.In what follows, we briefly summarise these key sub-ontologies.

Task: Describes a unit of work that is triggered by anemerging modification request (MR) or problem report(PR). Information about MRs or PRs, task assignment,tool log (tool used in the task solving process), activity logand so on is modelled in this sub-ontology. For example,


IETdoi

www.ietdl.org

the instances in this sub-ontology might be ‘Debrief XMLdecrypt/encrypt component substitution request’ (aninstance of concept Request), ‘corrective’ (an instance forconcept RequestType) and ‘successfully finished’ (aninstance for concept TaskStatus).

User: Describes maintainers involved in the softwaremaintenance process. Information about the involved rolesand their related skills, competencies and responsibilitiesare modelled. The users involved in the softwaremaintenance can be an individual, an organisational teamor an entire organisation. The example instances in thissub-ontology might be ‘Mike Smith’ (an instance ofconcept Person), ‘SE group’ (an instance of conceptMaintainer) and ‘MR reporter’ (an instance of conceptRole).

Artefact: Describes artefacts associated with both the softwareproduct (source code, documentation etc.) and themaintenance process (documents, models etc.) that areproduced as part of the maintenance process (Fig. 4). Atthe current stage, we consider artefacts to be either relatedto the software system or to the maintenance task. Fig. 4shows a partial view part of the taxonomy of the artefactsub-ontology. Artefact itself is a super class of theArtefact sub-ontology, which has two sub-classes:SoftwareArtefact and TaskArtefact. Thesoftware system related artefacts are further classified intosoftware documents, software components and libraries,and artefacts made available by supporting tools. Task-related process artefacts correspond to artefacts, such asguidelines, reports and so on.

Subject system: Describes the software system to be maintainedand includes information about the programming language(s)used, application domain and so on.

Process: Describes the interactions and relationships amongdifferent sub-activities within a maintenance process model.

Figure 3 Software maintenance meta-model


The example instances in this sub-ontology can be ‘IEEEStd 14764 – Software Life Cycle Processes –Maintenance’ (an instance of concept ProcessModel),‘5.3 Modification Implementation’ (an instance of conceptActivity), ‘5.3.2.1 Analysis’ (an instance of conceptTask), and ‘5.3.2.1 a’ (an instance of concept TaskStep).

Technique: Describes the software techniques that can be usedfor supporting software maintenance (programcomprehension technique, source code analysis technique,impact analysis technique, etc.). Based on the previouswork by Dias et al. [32] and Pressman [33], the followingtechniques supporting the following activities can beidentified: requirement elicitation, maintenance support,programming related, testing, configuration management,documentation and modelling technique.

Tool: Describes the software tools used to carry out a functionor service with the goal to simplify maintenance tasks [34].At the current stage, our tool sub-ontology provides generalcategories for commonly used maintenance tools anddescribes their key features for supporting softwaremaintenance activities. Tools can be classified by theirfunctionality, their role in supporting managers andmaintainers, their particular use during the varioussteps of a software engineering process, their supportedenvironment (hardware and software), or even by theirorigin or cost. Pressman [33] provides a comprehensiveclassification of tools by their functions, which includes,among others, analysis, design, programming, softwareconfiguration management, testing and documentation

Figure 4 Partial view of the Artefact sub-ontology

309


310

&

www.ietdl.org

tools. In our approach, tools and techniques in the KB areautomatically classified through the use of reasoning. Forexample, programming tools can be classified based ontheir support for a particular programming language,operating system, applicability for a specific task and so on.

As discussed previously, software evolution is amultifaceted and dynamic activity involving differentresources, which utilises these resources to enhance thecurrent knowledge about a system. Existing work onontological modelling of the software engineering domain,including its processes, has focused on conceptualising thedomain [35, 36] to establish a common terminology or tomodel specific aspects of software engineering processes[34–37]. In the context of our research, we adopt coreparts of these ontologies and further enrich them with newconcepts and relationships to more closely reflect: (1) theparticular needs of our particular modelling goal –establishing traceability links between the process andvarious knowledge process related knowledge resources and(2) provide a design that fully supports and utilisesoptimised DL reasoners, such as Racer [25] in our case, toinfer additional knowledge.

An essential part of our model is the ability to support boththe knowledge acquisition and use of the newly gainedknowledge. The unified ontological representation providesthe ability to dynamically add new concepts andrelationships, as well as new instances of these to the KB.This extendibility enables our model to be constructed inan incremental way, closely modelling the same iterativeknowledge acquisition behaviour used to create a mentalmodel as part of human cognition of a software system.Having these different sub-domains modelled as sub-ontologies also allows for the automated processing (e.g.reasoning) and integration of this knowledge at a conceptand/or instance level. However, it would not be realistic toexpect that all these sources share a single, consistent viewwithin a maintenance task. Rather, we expectdisagreements between the individual users and sub-ontologies during an analysis. We explicitly capture thosedifferent views using a representational model thatattributes information to (nested) contexts using so-calledviewpoints [38]. The detailed knowledge managementstrategies have been discussed already in our previous paper[9]. Having this knowledge management mechanism inplace, our ontological model can evolve over time to reflectnew maintenance contexts and knowledge resources,addressing the flexibility and extendibility acceptancecriteria introduced earlier.

4.2 Ontology-based software evolutionprocess model

For the foundation of our evolution model, we have adoptedthe most recent IEEE software maintenance standard [7].The maintenance standard describes activities for bothmanaging and executing software maintenance tasks. The


starting point for the maintenance process is either aMR or PR. The maintenance process itself is detailed withinthe standard by six major activities: process implementation,problem and modification analysis, modificationimplementation, maintenance review/acceptance, migrationand retirement. Each of these activities is again described bya set of tasks, which are further refined by a list of task-steps. These task-steps correspond to the most fine-grainedactivities described by the standards document. However, theIEEE standard, like most process models, describes only ageneral software maintenance process without specifyingany details on how to adopt or perform these specificactivities and tasks in a given maintenance context.Furthermore, the IEEE standard also lacks support on howexisting knowledge and resources within an organisation canbe adopted to support these process activities.

Presently, we are limiting our modelling scope to a subsetof these activities described within the IEEE standard,namely the problem modification analysis, modificationimplementation and acceptance phase, corresponding,respectively, to Sections 5.2, 5.3 and 5.4 in the document.These activities are closely related to performing the actualmaintenance task rather than addressing more globalorganisational issues related to software maintenance(Sections 5.1, 5.5 and 5.6 [17]). The major concepts (e.g.MR, activities, tasks, task-steps and their required inputand output) and their relationships (e.g. follows, requires,delivers) documented in the maintenance standard havebeen modelled as part of our process sub-ontology. Fig. 5shows a partial view of the ontological representation of theIEEE software maintenance process.

The IEEE software maintenance model is formalised aspart of our process sub-ontology, allowing for both theprovision of a unified representation of process andknowledge resources and the ability to establish linksbetween the knowledge resources and the process activitiesin the existing maintenance standard. In our approach,these traceability links are established through either designlevel links via OWL–DL axioms and relations, or at thelogical level through a set of pre-defined queries. In termsof the design level links, OWL–DL axioms or conceptscan be used to establish the links between the processmodel and other knowledge resources modelled.Relationships/properties specified as OWL axioms can beused to establish implicit links as well. For example, intask-step ‘5.3.2.1a Identify the elements to be modified inthe existing system’ [17], the supportedBy property canbe utilised to link automatically the task-step withsupporting tool resources. The supportedBy relationshown in Fig. 6 is defined as a transitive property used tolink task-step with technique (1) as well as for linkingtechnique with tool (2). Then the links between theTaskStep and tools can be automatically derived throughthe inferred link (3). As a result, each task-step in theprocess ontology can automatically be linked through thistransitive supportedBy property to the sub-ontologies


IETdoi:

www.ietdl.org

Figure 5 Partial view of the process sub-ontology

of technique and tool. Through further traversing of thetransitive closures across the sub-ontologies, otherknowledge resources can be identified (Fig. 6).

In addition to these design level links, logical linksbetween the process and the knowledge resourcescan be established through pre-defined queries for eachtask-step.

Fig. 7 illustrates the use of a set of pre-defined queries tosupport different process task-steps. Users can also definetheir own supporting queries based on their experience toextract, explore and reason upon the information stored inthe KB.

These pre-defined queries supporting the different task-steps allow users to retrieve explicitly modelled knowledge,as well as inferring implicit knowledge across the KB tosupport a particular task-step (Fig. 7). The query belowshows such an implicit knowledge support through a

Figure 6 Transitive design level links

Softw., 2008, Vol. 2, No. 4, pp. 304–32010.1049/iet-sen:20070095

pre-defined nRQL query [39]:

(retrieve (?tool ?technique)

(and (IEEE Step5.3.2.1a ?tool supportedBy )

(?technique ?tool supportedBy)))

In this query, all tools providing techniques applicable totask-step 5.3.2.1a in the IEEE standard will be identified.In this query, several sub-ontologies (process,tools, techniques) are queried to retrieve the task-step relevant information.

As discussed, our unified ontological representation allowsfor conceptualising, storing, linking and retrieving softwareevolution processes and their relevant knowledge resources.

Figure 7 Task supporting queries

311


312

& T

www.ietdl.org

Providing both pre-defined and user-defined queries addressesour first acceptance criterion for the process model, related tosupport and adaptability. Through the use of the pre-definedand user-defined queries and the underlying reasoningservices, our model allows customisation of the processsupport and also provides users with contextual informationrelevant to their given task. However, a metaphor is needed torepresent the interaction between the users and theontological model. In the following section, we introduce astory [40, 41] based metaphor to model this interactionbetween the users and our unified ontology.

5 Software evolution story modelStories are ubiquitous, universal and readily implanted andrecalled in human minds [42]. They are widely used toconvey information, cultural values and experience [43]. It issuggested that humans build cognitive structures thatrepresent real events in their lives using models similar to theones used for narrative stories in order to better understandthe world around them [44]. People usually find it is easier tounderstand information integrated within a story contextinstead of serial lists [43]. Learners constantly adjust theirunderstanding in accordance with their exposure toconventional narratives, making the construction of narrativea central cognitive goal [45].

5.1 Story models in software engineering

A story itself is a narrative, which, in its simplest form, providesa temporally ordered sequence of events (Table 1) [46].


Storytelling can be applied by scripting a story of thecomplete system at design time or by generating storiesdynamically on a per-session basis [41]. A system that cangenerate stories dynamically is capable of adapting the storynarrative to the user’s preferences and abilities. Storiesthemselves can be represented in various ways, such as usingtext, image or animation.

The story notation has already been applied in differentdomains. In extreme programming, stories are used as acommunication media to elicit requirements. In UML, ascenario diagram is a descriptive story of a use case,detailing what happens between the users and the systemfor a specific function. Sequence diagrams can also beviewed as a more formal story representation of a systembehaviour, delineating how operations are carried out –what messages are sent and when, by emphasising the timeordering of message passing among objects [47].

5.2 Story-driven interaction model

In this section, we introduce our interactive story-drivensoftware evolution model. The major motivation forapplying a story metaphor is to provide us with a metaphorthat allows us to model (map) user interactions between theprocess models and knowledge resources to a visualmetaphor. The story-driven metaphor not only supportsthe mapping of user interactions with the underlyingprocess model and knowledge resources. It also providesthe basis for developing a tool environment to support userinteractions with the process model.

Table 1 Story model [40]

Story model Description

theme overall message, concept or essence of a story; ties every structure and dynamic element

genre characters establishes an author’s overall attitude, which casts a background on all other considerations

protagonist main story character – driver of the story: the one who forces the action to resolve the problem andreach the ultimate goal

impactcharacter

Might be an antagonist (desire to let the problem grow), guardian (functions as a helper/teacher, aprotective character who eliminates obstacles and illuminates the path ahead), or contagonist (works to

place obstacles in the path of the protagonist, and to lure it away from success) etc.

settings place, time, weather conditions, social conditions, or mood or atmosphere etc.

plot a series of logic events that develop a story; details the order in which the elements must occur withinthat story

throughline the point of view and growth of the main character within the story world

interaction what occurs between the characters (or even ideas) is presented. Interaction can occur as connectionsand disconnections

conflict everything that prevents or gets in the way of the protagonist in achieving the goal

climax/resolution

at this point, the obstacles are no longer a threat and any conflict disappears


IETdoi

www.ietdl.org

From a maintenance perspective, maintainers typicallybecome immersed in the setting in which the particularmaintenance task (story) unfolds [2, 48] and the user(maintainer) is considered as an active character in thestory, able to interact with different elements, includingrelevant knowledge resources [3, 49] (e.g. tools, techniques,maintainers and their expertise) and other characters (e.g.system or historic user data) while following the process(through line).

From a story perspective, the evolution process can beviewed as authoring an interactive narrative between theusers and knowledge resources towards completing aspecific goal (task). The similarities among a story modeland a maintenance process model allow for a directmapping of the formal (ontological) representation of theprocess and resources with the story metaphor.

Furthermore, given the story model, this model can beeasily mapped to different metaphors, such as text, image,animation, depending on the abstraction level needed.Table 2 illustrates this mapping between the story modeland the evolution process.

A typical usage scenario for our story-based evolutionprocess model is illustrated in Fig. 8, reflecting the iterativenature of the knowledge acquisition and its use by the loop(messages 2–22). A user (maintainer) corresponds to theprotagonist in the story who has to complete a particularevolution task. The story manager, ontology manager(process manager) and reasoner are all examples of impactcharacters that might impact the user and therefore thestory interaction. Knowledge resources are the availableelements in the story environment (setting), and users can


use them during the task solving process. The storymanager is the main character with whom the userinteracts during the task solving process.

Based on a given story (task) setting (message 1), the storymanager applies a set of pre-defined queries to support thedifferent process activities, by identifying potentialknowledge and other resources that might be applicable tothe current activities (messages 2–14). The user interactswith the process through the story metaphor, providing thecurrent process context and the ability to trigger new eventsand actions. One of the major advantages of ourontological representation is not only the ability to reasonacross the different information resources, but also theability for users to add newly gained knowledge (concepts,relations and instances) to the system and make theseavailable for further processing. For instance, message 9may return a list of techniques that support a particularmaintenance activity, like impact analysis or reverseengineering. The resulting set of tools will be furtheranalysed by the process manager and a potentialapplicability ranking of the tools and techniques isprovided. At this point, the protagonist has the choicebetween three different options: (1) accept one of thesuggestions (shown in the scenario in Fig. 3 – messages15–18), (2) explore all available knowledge and otherresources stored in the ontologies or (3) create customisedqueries to search and filter information for specific settings,tools or historical data.

After the completion of a task-step, the protagonist willprovide feedback and annotate briefly the applicability ofthe knowledge resource towards solving a particular task-step (messages 18–22). The feedback is used to further

Table 2 Mapping between the story metaphor and the software evolution process model

Story model Software evolution model

theme evolution task

story a specific MR or PR

genre characters type of maintenance activity, for example, perfective, adaptive, corrective maintenance

protagonist The maintainer or user who performs the evolution task

impact/othercharacters

historical user experience, process manager, ontology manager and reasoner

settings organisational settings, available knowledge resources: software, tools, techniques,maintainers, etc

plot process management

throughline interactive communication between the user and plot based on the underlying process model(activities and task-steps)

interaction inter-relationships between the characters and the knowledge resources and process activities

conflict lack of necessary resources, unsuccessful use of resources

climax/resolution final outcome of the process (success/failure)

313


314

& T

www.ietdl.org

Figure 8 Resources usage sequence diagram

enrich the ontology, as well as triggering the next task-step oractivity in the evolution process.

6 Implementation and validationIn this section, we provide an overview of our systemimplementation followed by a discussion evaluating ourpresented approach. As stated earlier, our research focusesnot on developing a new tool or technique in attempt tosupport a specific maintenance activity. Instead, our goal isto automatically integrate implicit and explicit knowledgeresources through the use of queries and automatedreasoning within a maintenance process. Within oursystem, maintainers can directly query the KB to exploreknowledge or utilise pre-defined views and queries toautomatically establish a task (story) specific context.

6.1 System overview

We have developed an environment that supports our unifiedmodel built on a client/server architecture with both theserver and the client being implemented as Eclipse plug-ins(Fig. 9).

Ontology, persistent storage management and reasoningservices are provided through the server application. Theyare implemented in Java and built on top of the JenaSemantic Web Framework (http://jena.sourceforge.net/).Jena provides the backend repository for both concepts(TBox) and instance data (ABox). Leveraging Jena’spersistent storage support, the model storage can be based


on files or a relational database. TBox management iscentralised on the server to ensure consistency, quality ofthe ontology design and standardisation of the KB.Reasoning services are provided by Racer [26], whichprovides highly optimised TBox and ABox reasoningcapabilities.

The client provides the foundation for our visualintegration, supporting the interaction and linking betweenthe maintenance activities and the relevant resources.Similar to more traditional database applications, ABoxmanagement is provided through the client. The client alsoprovides the story interface that is part of the local processmanager. The contextual process views are establishedthrough separate process views and resource advisors. The

Figure 9 System architecture


IETdoi:

www.ietdl.org

story manager also integrates both the contextual navigationthrough the KB (through pre-defined queries), as well asthe query interface for user-defined queries.

6.2 Process support

A successful process-centred support system is based on thepremise that the right information should be madeavailable at the right time in the right format. Achievingthis premise depends greatly on the available knowledgeresources and the specific task context. From a softwaremaintainer’s perspective, the challenge is specifically theneed to adjust both information and context in real time tothe current process task-step being performed. Our processenvironment supports such traceability between theinvolved process steps and other supporting resources (e.g.artefacts, maintainers, techniques and tools).

The story (process) manager is built on top of the ontologymanager infrastructure. The story manager provides for theuser both the context and the interactive guidance duringthe evolution task. The story manager coordinates theprotagonist (the user) to dynamically author the specificevolution task solving story. In addition, the storymanagement is also responsible for providing an intuitivevisual metaphor to vividly model the whole task solvingprocess. The different aspects of the story metaphor can bemapped with the help of existing visualisation metaphors(such as static and dynamic 2D and 3D graphs, textualrepresentations and different types of animation). Duringthe process, the story manager is monitoring events andtriggers that might affect the storyline of the evolutionprocess, for example, user or system activities.

A software maintenance process typically originates froman MR. Similarly, our environment will initiate themaintenance process with a request view (Fig. 10). TheMR view also establishes the initial process context and the


traceability between the process and the available resources.The context sensitivity levels are supported throughcustomisable views and abstraction hierarchies that bothsupport filtering and extracting details-on-demand [50].The process supporting queries establish the link to the KBand automatically populate the relevant resource views. Theprocess and its task-steps are supported through a workflowlike view and a tree structure view, with both of themadopting similar techniques as the IBM Rational RMC[51]. Those views allow for easy process navigation byexpanding/collapsing of process task-steps and their details.For a specific task-step, we also support context switchingto the advisor views that provide suggestions on whatrelevant knowledge resources and other related task-stepsmight be applicable in the given context.

6.3 Initial evaluation and discussion

Our research contains two main contributions: The OWL–DL KB capturing both process and knowledge resources, aswell as an environment utilising the KB. The use of OWL–DL as the ontology language to formalise the KB providesadditional benefits compared with less formal knowledge andinformation sharing approaches. Our constructed ontologicalrepresentation can be used with many available OWL–DLtools such as Protege (http://protege.stanford.edu/) (ontologymanagement), Pellet (http://pellet.owldl.com/) (ontologyreasoner), and (SWOOP http://www.mindswap.org/2004/SWOOP/) (ontology browsing/debugging). Our modeldesign has been evaluated with Pellet and Racer [26] formodel consistency and reasoning support. Management andevolution of the KB is supported by existing ontologymanagement tools such as Protege.

In addition, the visual tool environment we developedpromotes the use and adaptation of process models and isnot limited to maintenance process models. Ourenvironment provides maintainers with process guidance

Figure 10 MR and linked views

315


316

& T

www.ietdl.org

without the need for a prior knowledge about formalontologies or OWL. Maintainers can use and customiseboth the standard process as well as the traceability betweenthe context relevant knowledge, through the differentadvisor views and pre-defined or customisable queries.

It has to be noted that one of the main challenges for ourapproach is the population of the KB. In this respect, ourapproach does not differ from any existing KB or datamining approach. We are currently following two mainstrategies to address this challenge. In the first phase, weare performing several case studies in collaboration withDefence Research and Development Canada (DRDC)Valcartier. The case studies are performed in a controlledenvironment that restricts both the type of task performed(component substitution) and the resources to be modelled.This limited knowledge corpus is sufficient to provide aninitial proof of concept that our ontological representationcan capture the relevant information and model the contextlevels. To date, we have conducted two componentsubstitution case studies on Debrief (http://www.debrief.info/index.php), a medium size open source application forthe analysis and reporting of maritime exercises. Both ofthe maintenance tasks were related to substituting a non-secure XML data exchange component within Debrief byopen source components that perform XML encryption.

6.3.1 Case study settings: We selected eight graduatestudents from our Software Maintenance Research Groupat Concordia University to participate in both case studiesin a controlled environment. The technical andmaintenance experience levels varied significantly amongthe students. Their Java programming experience rangedfrom 2 to 8 years and their industrial maintenanceexperience from no previous experience to several years assenior programmer. A commonality among all studentsparticipating in the case study was that they had noprevious experience using or maintaining Debrief.

For the case studies, 30 software maintenance relevanttools were selected and installed on the computers intwo software engineering labs accessible to the students.The software packages included source code analysis tools,software measurement tools, software visualisation tools andother software maintenance support tools. Informationrelated to these tools was manually collected and populatedwithin the KB. Since most of the students were unfamiliarwith these tools, tutorials and manuals were provided toallow them to familiarise themselves with the tools prior tousing them in their assigned maintenance task.

Artefacts that were made available with Debrief includedsource code, class files, a detailed analysis document, asystem design document, user guide and tutorials.

The intent of the first case study was 2-fold: first tovalidate whether our unified model was capable tosufficiently and correctly capture the information required


to support a software maintenance tasks. Secondly, the casestudy was used to collect some user, tool and feedback datafrom the case study to allow for an initial population of theontology.

Given the results and feedbacks collected from the secondcase study, we were able to extend and refine our ontologicalmodel to improve its ability to support more task-specificqueries. The collected feedback was also used to furtherpopulate the ontology, which included after the second casestudy 295 concepts, 129 relationships and 765 instances.

The studies provided us with a proof of concept that ourapproach is capable of providing additional benefits tomaintainers. It was in particular the integration of process,task and resource relevant information that was wellreceived. Ontology population is a major concern at thispoint of time, since our process advisor support is driven bythe quantity and quality of the information available. Thecollected feedback confirmed our initial hypothesis thatconsidering associated knowledge resources without aparticular maintenance context does not provide sufficientguidance to assist a maintainer (protagonist) in completinga given maintenance task.

During the second evaluation phase, we will furtherextended and generalise our environment by includingadditional tasks and resources to the KB. Currently, we arefacing the challenge of ontology population and exploringdifferent avenues to address this issue. Potential solutionsfor the ontology population problem include the creation ofan Internet community portal and/or the concrete adoptionof our tool within an industrial setting.

7 Related workAs a knowledge representation language, OWL has alreadybeen applied in many applications of the softwareengineering domain such as model-driven softwaredevelopment [52], a CMMI-SW model representation andreasoning for classifying organisational maturity levels [53],reverse engineering tool integration [14], component reuse[39] and open source bug tracking [54]. However, thereexists only limited research in modelling softwaremaintenance and evolution using ontologies. Ruiz et al.[30] present a semi-formal ontology based on REFSENOfor managing software maintenance projects. They considerboth the static [29] and dynamic aspects such as workflowin software maintenance processes. The ontology wasconstructed using KM-MANTIS, a knowledgemanagement system with the goal of improvingmaintenance project management. However, noimplementation or usage details are provided. Kitchenhamet al. [29] designed a UML-based ontology for softwaremaintenance to identify and model factors that affect theresults of empirical studies. Their goal differs from ours byutilising ontologies to establish a common understandingcontext for empirical studies. Furthermore, the resulting


IETdoi:

www.ietdl.org

ontology was not formally modelled and no reasoningservices were used to infer implicit knowledge. Dias et al.[28] extended the work by Kitchenham by applying a first-order logic to formalise knowledge involved in softwaremaintenance. Although they stated that it is worthwhile toprovide a KB, they only identified knowledge relevant tothe software maintenance domain without actuallyproviding a concrete KB implementation. Gonzalez-Perezand Henderson-Sellers present a comprehensive ontologyfor software development [55] that includes a process sub-ontology modelling, among others, techniques, tasks andworkflows. The ontology is presented using UMLdiagrams. No implementation is given, implying that theauthors also have not examined the integration of theirontology in an actual software development process.

Common to all of these approaches is that their main intentis to support in one form or another the conceptualisation ofknowledge, mainly by standardising the terminology and tosupport knowledge sharing based on a commonunderstanding. These approaches fall short on adopting andformalising a process model to support traceability linksbetween the process and the knowledge resources in the KB.They also lack the use of reasoning services to infer implicitknowledge. To the best of our knowledge, there exists noprevious work that focuses on developing a formal OWL–DL software maintenance process model and utilisesautomated reasoning to establish the links between theprocess activities and involved resources.

The collaborative nature of software engineering has morerecently been addressed by introducing Wiki systems into theSE process. Semantic Wiki extensions such as SemanticMediaWiki [56] or IkeWiki [57] add formal structuringand querying extensions based on RDF/OWL metadata.These works can be seen as complementary to ourapproach, in that they can support the creation andvisualisation of the developed KB. However, by themselvesthey do not address the main concern covered by ourapproach, delivering active and context-sensitive guidanceto an individual developer for his current task, based onknowledge both explicitly encoded and implicitly derivedby actions performed by other developers.

Compared with other modelling approaches such asmodel-driven architecture (MDA) and related modellingstandards (e.g. UML/MOF [58] or the eclipse modellingframework (EMF) [59]), our approach differsfundamentally in its objective. (1) These modelingapproaches focus on forward engineering, that is, producingcode from abstract, human-elaborated specifications,following a strict modelling process. We, on the otherhand, focus on software evolution, where one has to extract,model, integrate and utilise knowledge from various andoften not well-defined resources and (2) MDA and EMFboth focus on modelling well-defined processes, in anattempt to derive complete models. Our approach, on theother hand, is based on an open world assumption,


focusing on the integration of existing and newly gainedknowledge and by making this knowledge available to theend-user.

With regard to tool support for process guidance, recentwork by IBM rational on its method composer (RMC)[51] and process advisor [60] are the closest relatedapproaches to our research. RMC is a process managementtool for authoring, configuring and publishing developmentprocess like the rational unified process (RUP). The IBMrational process advisor integrates RUP process guidancewithin the context of software development tools [60].Because of the required tool customisation, the contextualguidance through the process advisor is currently onlysupported within a selected set of rational tools. Ourapproach has similarities in process modelling andcustomisation with the RMC, due to the fact that weadopted parts of the RMC, namely EPF (http://www.eclipse.org/epf/) and GEF (http://www.eclipse.org/gef/), tographically model and customise the IEEE maintenanceprocess. However, our approach differs in its overallmotivation. These differences can be summarised asfollows: (1) The process advisor focuses on the integrationof RUP-based process guidance into the context of severalrational development tools (http://www-128.ibm.com/developerworks/rational/products/rup) by requiring acustomisation of these tools to support the process advisor.Our focus instead is on the general knowledge integrationof the process activities and resources by creating linksbetween the process activities and resources which are notlimited by a set of specific tools and (2) We focus onknowledge integration rather than tool integration byproviding a flexible and dynamic knowledge management.Within our approach, any newly gained knowledge (processand/or resources) automatically becomes an integrated partof our model. Furthermore, we support reasoning servicesthat can infer implicit knowledge not explicitly modelled inthe KB. In comparison, the process advisor is a more staticapproach that requires a manual adaptation of tools to beable to take advantage of the process advisor and its contextsensitive guidance.

8 Conclusions and future workSoftware evolution is a major part in terms of effort and costinvolved in any software life cycle. Our work promotes theuse of both formal ontology and automated reasoning insoftware evolution by providing a formal DL-basedontological representation for the modelling of bothsoftware evolution processes and resources relevant tosupport these processes. We have adopted the IEEEsoftware maintenance standard to illustrate the modellingof software evolution processes using a formal ontologicalrepresentation. The unified ontological representationallows for the integration of these knowledge resources andestablishes traceability links between the process and theresources. The flexibility and extensibility of the ontologiesalso enables the evolution and enrichment of the KB.

317


318

&

www.ietdl.org

We introduce a story-based software evolution process modelto provide a metaphor that supports the interaction andcontext visualisation between the process model, modelledresources and users. The visual format for the task storymodel is still under development. As part of our futurework, we will conduct further case studies to enrich ourcurrent ontologies and optimise our current tool insupporting particular software evolution process models.

9 AcknowledgmentThis research was partially funded by DRDC Valcartier(contract no. W7701-052936/001/QCL).

10 References

[1] STOREY M.-A.D., WONG K., MULLER H.A.: ‘How do programunderstanding tools affect how programmers understandprograms?’’, Sci. Comput. Program., 2000, 36, (2 – 3),pp. 183–207

[2] VON MAYRHAUSER A., MARIE VANS A.: ‘Programcomprehension during software maintenance andevolution’, Comput., 1995, 28, (8), pp. 44–55

[3] LEHMAN M.M., BELADY L.A.: ‘Program evolution: processesof software change’ (Academic Press Professional, Inc.,San Diego, CA, 1985)

[4] BASILI V.R.: ‘Viewing maintenance as reuse orientedsoftware development’, IEEE Softw., 1990, pp. 19–25

[5] BENNETT K.H., RAJLICH V.T.: ‘Software maintenance andevolution: a roadmap’. Proc. Conf. Future of Software,2000, pp. 73–87

[6] CMMI for Development, Version 1.2: Technical ReportCMU/SEI-2006-TR-008, Carnegie Mellon, SoftwareEngineering Institute, USA, 2006

[7] International Standard: ISO/IEC 14764 IEEE Std 14764-2006 Software Engineering, Software Life Cycle Processes,Maintenance. ISBN: 0-7381-4961-6, 2006

[8] STOREY M.-A.D., SIM S.E., WONG K.: ‘A collaborativedemonstration of reverse engineering tools’, ACM SIGAPPAppl. Comput. Rev., 2002, 10, (1), pp. 18–25

[9] MENG W., RILLING J., ZHANG Y., WITTE R., CHARLAND P.:‘An ontological software comprehension process model’.3rd Int. Workshop on Metamodels, Schemas, Grammars,and Ontologies for Reverse Engineering (ATEM), 2006,pp. 28–35

[10] BAADER F., HORROCKS I., SATTLER U.: ‘Description logics asontology languages for the semantic web’, in HUTTER D.,


STEPHAN W. (EDS.): ‘Lecture notes in artificial intelligence’(Springer, 2005), vol. 2605, pp. 228–248

[11] LETOVSKY S.: ‘Cognitive processes in programcomprehension’ (Empirical studies of programmers (AblexPublishing Corp., 1986), pp. 58–79

[12] MAYHAUSER A.V., VANS A.M.: ‘Program comprehensionduring software maintenance and evolution’, IEEEComput., 1995, 28, (8), pp. 44–55

[13] SHNEIDERMAN B.: ‘Software psychology: human factors incomputer and information systems’ (Winthrop Publishers,1980)

[14] JIN D., CORDY J.R.: ‘Ontology-based software analysis andreengineering tool integration: the OASIS service-sharingmethodology’. 21st IEEE Int. Conf. Software Engineering(ICSM), 2005

[15] RIVA C.: ‘Reverse architecting: an industrial experiencereport’. Proc. 7th IEEE Working Conf. Reverse Engineering(WCRE 2000), 2000, pp. 42–52

[16] PACIONE M.J., ROPER M., WOOD M.: ‘A novel softwarevisualisation model to support software comprehension’.11th Working Conf. Reverse Engineering (WCRE 2004),2004

[17] STOREY M.-A.D.: ‘Theories, methods and tools in programcomprehension: past, present, and future’. Proc. 13th Int.Workshop on Program Comprehension (IWPC 2005),Missouri, USA, 2005, pp. 181–191

[18] JOHNSON-LAIRD P.N.: ‘Mental models: towards a cognitivescience of language, inference and consciousness’ (HarvardUniversity, Cambridge, MA, 1983)

[19] OWL web ontology language reference, W3CRecommendation, http://www.w3.org/TR/owl-ref, accessedJune 2007

[20] GRUBER T.R.: ‘A translation approach to portableontology specifications’, Knowl. Acquis., 1993, 5, (2),pp. 199–220

[21] HORROCKS I., PATEL-SCHNEIDER P.F., HARMELEN F.: ‘From SHIQand RDF to OWL: the making of a web ontologylanguage’, J. Web Semant., 2003, 1, (1), pp. 7–26

[22] SOWA J.F.: ‘Knowledge representation: logical,philosophical, and computational foundations’ (Brooks/Cole Publishing Co, Pacific Grove, CA, USA, 2000, ISBN:0 534-94965-7

[23] BAADER F., CALVANESE D., MCGUINNESS D., NARDI D., SCHNEIDER P.P.:‘The description logic handbook’ (Cambridge UniversityPress, 2003)


IETdoi:

www.ietdl.org

[24] Web ontology language, http://www.w3.org/2004/OWL/, accessed June 2007

[25] BERNERS-LEE T., HENDLER J., LASSILA O.: ‘The semantic web’,Sci. Am., 2001, 284, (5), pp. 34–43

[26] HAARSLEV V., MOLLER R.: ‘RACER system description’. Proc.Int. Joint Conf. Automated Reasoning (IJCAR’2001),Springer-Verlag, 2001, pp. 701–705

[27] KELLER I.M., MADACHY R.J., RAFFO D.M.: ‘Software processsimulation modeling: Why? What? How?’, J. Syst. Softw.,1999, 46, (2/3), pp. 91–105

[28] DIAS M.G.B., ANQUETIL N., OLIVEIRA K.M.: ‘Softwaremaintenance ontology’, in CALEOR C., RUIZ F., PIATTINI M.

(EDS): ‘Ontologies for software engineering and softwaremaintenance’ (Springer, 2006), Ch. 5, pp. 153–173

[29] KITCHENHAM B., TRAVASSOS G.H., MAYRHAUSER A.V., ET AL.:‘Towards an ontology of software maintenance’, J. Softw.Maint. Pract., 1999, 11, (6), pp. 365–389

[30] RUIZ F., VIZCAINO A., PIATTINI M., GARCIA F.: ‘An ontologyfor the management of software maintenance projects’,Int. J. Softw. Eng. Knowl. Eng., 2004, 14, (3), pp. 323–349

[31] NILES I., PEASE A.: ‘Towards a standard upper ontology’.Proc. 2nd Int. Conf. Formal Ontology in InformationSystem (FOIS), Maine, 2001

[32] GREYCK M., DIAS B., ANQUETIL N., MARCAL DE OLIVEIRA K.:‘Organizing the knowledge used in software maintenance’,J. Univers. Comput. Sci., 2003, 9, (7), pp. 641–658

[33] PRESSMAN R.: ‘Software engineering: a practioner’sapproach’ (McGraw Hill College, 2005, 6th edn.), ISBN-10:007301933X

[34] JAHNKE J.H., WALENSTEIN A.: ‘Reverse engineering tools asmedia for imperfect knowledge’. IEEE Working Conf.Reverse Engineering (WCRE’2000), pp. 22–31

[35] WONGTHONGTHAM P., CHANG E., DILLON T.S., SOMMERVILLE I.:‘Software engineering ontology – instance knowledge(Part I)’, Int. J. Comput. Sci. Netw. Secur. (USA), 2007, 7,(2), pp. 15–26

[36] BONTCHEVA K., SABOU M.: ‘Learning ontologies fromsoftware artifacts: exploring and combining multiplesources’. Proc. 2nd Int. Workshop on Semantic WebEnabled Software Engineering SWESE, 2006

[37] Software Engineering Coordinating Committee:SWEBOK, version 2004, http://www.swebok.org

[38] BALLIM A., WILKS Y.: ‘Artificial believers: the ascription ofbelief’ (Lawrence Erlbaum, 1991)


[39] HAPPEL H.-J., KORTHAUS A., SEEDORF S., TOMCZYK P.: ‘KOntoR: anontology-enabled approach to software reuse’. 18th Int.Conf. Software Engineering and Knowledge Engineering(SEKE), San Francisco, July 2006

[40] PHILLIPS M.A., HUNTLEY C.: ‘Dramatic a new theory of story’,Screenplay (Systems Inc., 2001, 5th edn.)

[41] RIEDL M.O., YONG R.M.: ‘From linear story generation tobranching story graphs’. ‘IEEE Computer Graphics andApplications’ (IEEE Computer Society, 2006)

[42] HARTLAND E.S.: ‘The science of fairy tales’ (Walter Scott,1891)

[43] GONZALEZ-PEREZ C., HENDERSON-SELLERS B.: ‘An ontology forsoftware development methodologies and endeavours’, inCALEOR C., RUIZ F., PIATTINI M. (EDS.): ‘Ontologies for softwareengineering and software maintenance’ (Springer, 2006),pp. 123–151

[44] BRUNER J.: ‘Acts of meaning’ (Harvard University Press,Cambridge, MA, 1990)

[45] PLOWMAN L., LUCKIN R., LAURILLARD D., STRATFOLD M., TAYLOR J.:‘Designing multimedia for learning: narrative guidanceand narrative construction’. Proc. SIGCHI Conf. HumanFactors in Computing Systems: The CHI is Limit, ACMPress, May 1999

[46] RIEDL M.O., YOUNG R.M.: ‘An intent-driven plannerfor multi-agent story generation’. Proc. 3rd Int.Conf. Autonomous Agents and Multi Agents Systems, July2004

[47] Open Management Group (OMG): ‘Unifiedmodeling language’, www.uml.org, accessed February 2008

[48] BROOKS R.: ‘Towards a theory of the comprehension ofcomputer programs’, Int. J. Man-Mach. Stud., 1983, 18,pp. 543–554

[49] WONGTHONGTHAM P., CHANG E., DILLON T.S.: ‘Towardsontology-based software engineering for multi-sitesoftware development’. 3rd IEEE Int. Conf. IndustrialInformatics (INDIN), 2005

[50] RILLING J., MENG W., CHEN F., CHARLAND P.: ‘Softwarevisualization – a process perspective’. 4th IEEE Int.Workshop on VISSOFT, Banff, Canada, 2007

[51] HAUNER P.: ‘IBM rational method composer. Part 1: Keyconcepts’, IBM Report, December 2005

[52] Ontological Driven Architectures and PotentialUses of the Semantic Web in Systems and SE, www.w3.org/2001/sw/BestPractices/SE/ODA/, accessed May2007

319


320

&

www.ietdl.org

[53] SOYDAN G.H., KOKAR M.: ‘An OWL ontology for representingthe CMMI-SW model’. Workshop on Semantic Web EnabledSoftware Engineering (SWESE), 2006

[54] ANKOLEKAR A.: ‘Supporting online problem – solvingcommunities with the semantic web’, PhD Thesis,Carnegie Mellon University, Pittsburgh, PA, 2005

[55] GERSHON N., PAGE W.: ‘What storytelling can dofor information visualization’, CACM 2001, 8, (44), pp. 31–37

[56] KROTZSCH M., VRANDECIC D., VOLKEL M.: ‘Semantic MediaWiki’,in CRUZ I., DECKER S., ALLEMANG D., PREIST C., SCHWABE D., MIKA

P., USCHOLD M., AROYO L.(EDS.): ‘The seman.tic web – ISWC2006’ (LNCS, 4273, Springer, 2006), pp. 935–942


[57] SCHAFFERT S.: ‘IkeWiki: a semantic wiki for collaborativeknowledge management’. WETICE, IEEE Computer Society,2006, pp. 388–396

[58] OMG: ‘Unified modeling language’, /www.uml.org/,accessed February 2008

[59] Eclipse and Open Development Platform, www.eclipse.org, accessed February 2008

[60] SMITH J., POPESCU D., BENCOMO A.: ‘IBM rational processadvisor: integrating the software development processwith IBM rational developer and tester V7 tools’. IBMReport, December 2006


Documents

ISSN 1751-8806 Story-driven approach to software evolutionpdfs.semanticscholar.org/5e7d/e42e09288818d2aa... · Various process models [3–7] supporting the evolution of software