improving software development with static code analysis ... › smash › get › diva2:412947 ›...

Improving software development with

static code analysis in a traceable environment

RICKARD EKLÖF

Master of Science Thesis

Stockholm, Sweden 2011

Improving software development with static codeanalysis in a traceable environment

RICKARD EKLÖF

Master’s Thesis at Machine DesignSupervisors:

Fredrik Asplund, KTHDetlef Scholle, ENEA

Barbro Claesson, ENEAExaminer: Martin Törngren, KTH

MMK 2011:12 MDA 407

AbstractThis thesis investigates how and where static code analysis can be inte-grated into a development process, and what impact static code analysishas on traceability between artifacts in a development life cycle.

To be able to answer the questions, two things have been performed.First, a theoretical study of life cycle phases, static code analysis andtraceability. Secondly, an analysis of traceability of static code analysisartifacts in the Jazz Team Server. The later including implementing ajava application which adds static code analysis artifacts to the JazzTeam Server and links them to artifacts of a development life cycle.The conclusions from the theoretical study have been compared to theanalysis of traceability.

This thesis concludes that static code analysis should be used dur-ing the implementation phase, during integration testing and duringtest analysis. Furthermore, this thesis defines minimal requirements onlinks to static code analysis artifacts, including properties which aidunderstanding the relationship between the linked artifacts.

The verifiability of the results are limited by the fact that the imple-mentation was unable to extend the already existing traceability in theJazz Team Server. This is however one of several suggestions on futurework outlined in the end of the report.

SammanfattningDet här examensarbetet undersöker hur och var statisk kodanalys kanintegreras i en utvecklingsprocess, och vilken påverkan statisk kodanalyshar på spårbarheten mellan artefakter i en utvecklingslivscykel.

För att kunna svara på frågorna har två saker utförts. Först, en teo-retisk undersökning av livscykelfaser, statisk kodanalys och spårbarhet.Det andra som utfördes var en analys av spårbarhet av artefakter frånstatisk kodanalys i Jazz Team Server. Den senare inkluderar en imple-mentering av en java-applikation som lägger till artefakter från statiskkodanalys till Jazz Team Server och länkar dem till artefakter av enutvecklingsprocess. Slutsatserna från den teoretiska undersökningen harjämförts med analysen av spårbarhet i Jazz Team Server.

Det här examensarbetet konkluderar att statisk kodanalys bör an-vändas i utvecklingsfasen, under integrationstestning och under test-analys. Vidare definierar det här examensarbetet minimala krav pålänkar till artefakter från statisk kodanalys, vilket inkluderar egenskapersom hjälper förståelsen av förhållandet mellan länkade artefakter.

Verifierbarheten av resultaten är begränsade av faktumet att imple-mentationen inte kunde utöka den redan existerade spårbarheten i JazzTeam Server. Detta är ett av flera förslag på framtida arbete som ärbeskrivet i slutet av rapporten.

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2.1 Static code analysis . . . . . . . . . . . . . . . . . . . . . . . 21.2.2 Traceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.3 Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Static Code Analysis 52.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Techniques of static code analysis . . . . . . . . . . . . . . . . . . . . 6

2.3.1 Build process comprehension . . . . . . . . . . . . . . . . . . 62.3.2 Code compilation . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.3 Syntax analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.4 Data flow analysis . . . . . . . . . . . . . . . . . . . . . . . . 72.3.5 Similarity to compilers . . . . . . . . . . . . . . . . . . . . . . 7

2.4 What can static code analysis do? . . . . . . . . . . . . . . . . . . . 72.4.1 Runtime errors . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.3 Software metrics . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.4 Code Standard Checking . . . . . . . . . . . . . . . . . . . . 102.4.5 Architectural analysis . . . . . . . . . . . . . . . . . . . . . . 10

3 Development Life Cycle Phases 113.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Requirements phase . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . 133.2.2 Non-functional requirements . . . . . . . . . . . . . . . . . . 133.2.3 Other requirements specification . . . . . . . . . . . . . . . . 143.2.4 Artifacts from the requirements phase . . . . . . . . . . . . . 14

3.3 Design phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.1 System design . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3.2 Detailed design . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.3 Other design methods . . . . . . . . . . . . . . . . . . . . . . 153.3.4 Artifacts of the design phase . . . . . . . . . . . . . . . . . . 15

3.4 Implementation phase . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4.1 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4.2 Artifacts of the implementation phase . . . . . . . . . . . . . 16

3.5 Validation and verification phase . . . . . . . . . . . . . . . . . . . . 163.5.1 The fundamental test process . . . . . . . . . . . . . . . . . . 163.5.2 Test levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.5.3 Component testing . . . . . . . . . . . . . . . . . . . . . . . . 183.5.4 Integration testing . . . . . . . . . . . . . . . . . . . . . . . . 193.5.5 System testing . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Traceability 234.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 Deployment of traceability . . . . . . . . . . . . . . . . . . . . . . . . 234.3 Trace dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.3.1 An example of traceability . . . . . . . . . . . . . . . . . . . . 244.4 Representation of traceability links . . . . . . . . . . . . . . . . . . . 26

5 IBM Jazz 275.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2 Jazz Integration Architecture . . . . . . . . . . . . . . . . . . . . . . 27

5.2.1 RESTful web services . . . . . . . . . . . . . . . . . . . . . . 275.2.2 Jazz Team Server . . . . . . . . . . . . . . . . . . . . . . . . . 285.2.3 JTS Applications . . . . . . . . . . . . . . . . . . . . . . . . . 295.2.4 Change and Configuration Management . . . . . . . . . . . . 29

5.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Design and Implementation 356.1 Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.1.2 SciTools Understand . . . . . . . . . . . . . . . . . . . . . . . 356.1.3 The approach and goal of the analysis . . . . . . . . . . . . . 37

6.2 Java Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.2.3 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.2.4 Java libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2.5 The Java Client . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7 Results 457.1 The “Implement” work item . . . . . . . . . . . . . . . . . . . . . . . 457.2 The “Defect” work items . . . . . . . . . . . . . . . . . . . . . . . . . 467.3 Link properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477.4 Overview of links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

8 Discussion 498.1 Question discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

8.2.1 Integrating SCA into a development process . . . . . . . . . . 548.2.2 Traceability of SCA artifacts . . . . . . . . . . . . . . . . . . 54

8.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.3.1 Integrating SCA into a development process . . . . . . . . . . 548.3.2 Traceability of SCA artifacts . . . . . . . . . . . . . . . . . . 558.3.3 Lessons learned . . . . . . . . . . . . . . . . . . . . . . . . . . 55

8.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578.4.1 The IBM Jazz Project . . . . . . . . . . . . . . . . . . . . . . 58

Bibliography 59

A Use CaseA.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.1.1 OpenGL ES 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . .A.1.2 EGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.1.3 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.1.4 OpenGL in Linux on the i.MX31 . . . . . . . . . . . . . . . .

A.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Appendices

Chapter 1

Introduction

1.1 Background

This master thesis was performed at ENEA AB in collaboration with the RoyalInstitute of Technology, KTH. The work is part of the project iFEST1[1] whichpurpose is to lower the cost and time of development and maintenance of embeddedsystems, also granting life cycle support.

Embedded systems today are very expensive to develop because of increasingcomplexity. The need to incorporate life cycle support for products is a necessity tokeep expenses low. The iFEST project addresses these issues, and the main goal isto show that integration of tools over the whole life cycle leads to lower developmentcosts and a faster time to market.

During the development process of embedded systems, often many developersneed to work together with separate tools because of the increasing size and com-plexity of projects. This leads to the need for ways to help the delivery teams bymaking it easier to use development life-cycle tools in combination. Part of thisproblem is traceability of artifacts2 between different phases in the development lifecycle. Another problem in the development of embedded systems is the amount ofdefects discovered late in the development cycle, or even after release of the product,which leads to high costs of correcting these defects. By finding the defects earlierin the development life cycle, it is possible to reduce this cost significantly. Staticcode analysis is a great tool to find these defects early, and developers are able tocorrect them before they creep further into the development life cycle.

1.2 Problem Statement

Two responses of iFEST to the target of ARTEMIS’s[2] goal of achieving 15 percentreduction in development cycles[3] are the following:

1industrial Framework for Embedded Systems Tools2an artifact is a work piece e.g. design document, documented bug etc.

1

CHAPTER 1. INTRODUCTION

“The iFEST tool integration solutions will enable use of analysis and synthesistools that increase the chances of removing errors prior to product release, and thusimproving development efficiency.” This thesis investigates how static code analysiscan be integrated into a development process as an approach for this statement.

“A well-functioning tool chain will avoid errors which today’s manual processesintroduce when going from one phase in the engineering life cycle to the next one.”There are many approaches to enforce this statement. This thesis investigates thetraceability between static code analysis artifacts and other artifacts when staticcode analysis is integrated into a development process.

1.2.1 Static code analysisHow is static code analysis best integrated into the development process of embed-ded software? This question leads to the following more specific questions:

• Q1 Where in the development process shall static code analysis be integrated?

• Q2 How shall static code analysis be integrated into the development process?

• Q3 What artifacts are affected by static code analysis?

• Q4 Can static code analysis in the development process be automated?

1.2.2 TraceabilityWhat traceability exists between static analysis artifacts and other artifacts whenstatic code analysis is integrated into a development process?

• Q5 What requirements does static code analysis impose on the representationof artifacts to ensure traceability?

• Q6 Is it possible to ensure traceability between defects and design artifacts?

• Q7 What other traceability can static code analysis assist?

1.2.3 Use CaseIn this thesis, a use case is defined as scenario or method used to verify or analysean implementation.

OSE3 currently lacks support for OpenGL4. At the moment the graphics libraryruns under Linux, but there is a wish to also have it running under OSE. The usecase consists of describing the architecture of a source code package delivered byImagination Technologies with the help of a static code analysis tool. Section 1.3describes how the use case will aid this thesis.

The original plan of the use case was to do all or part of porting OpenGL toOSE, but the approach was changed later. This is discussed in section 8.3.3.

3Operating System Embedded (ENEA Real Time Operating System)4Open Graphics Library

2

1.3. METHOD

1.3 MethodThis thesis begins with a literature study of academic research papers, manuals,books, technical documentation and reports.

The use case approach is to use a static code analysis tool to study the archi-tecture of the source code package. This will provide this thesis with artifacts froma static code analysis tool, giving examples of what kind of artifacts are availablefrom a certain static code analysis tool.

To answer questions 1-4, this thesis theoretically studies software developmentlife cycle phases, combined with an analysis of what static code analysis can provide,and then concludes how and where static code analysis can be integrated into thedifferent life cycle phases.

To answer questions 5-7, the concept of traceability is studied in the theoreticalpart of this thesis. This thesis then integrates static code analysis artifacts intothe Jazz Team Server (see section 5.2.2). The integration is made by using JazzFoundation defined REST services[4] in a java application. The application addsstatic code analysis artifacts to the Jazz Team Server repository and creates linksbetween work items, requirements, test cases and the static code analysis artifacts.The traceability between these artifacts are then analysed and compared to whatwas concluded from the theoretical study of traceability. The choice of IBM Jazzwas made to constrict the thesis to one architecture of life cycle integration. Jazzis also one of the integration frameworks interesting to the iFEST project.

The tools used in this thesis are:

• IBM Jazz Team Server with CCM, QM, RM applications

• IBM Rational Software Analyzer

• SciTools Understand

1.4 LimitationsThe time limit of this master thesis is 20 weeks. The literature study will becompleted within the first ten weeks, after that, the design and implementation ofthe use case and java application will be done.

Not every artifact of the development life cycle model will be investigated, onlyartifacts that are closely linked to static code analysis. Future work could be anelaboration of artifacts, and extending the grasp of static code analysis.

The Jazz Team Server does not provide representations of all artifacts of adevelopment life cycle, limiting the implementation of this thesis to artifacts thatare represented in the Jazz Team Server.

3

Chapter 2

Static Code Analysis

2.1 IntroductionDeveloping complex software products inevitably introduces defects. Most of themcan be caught during testing stages in the development process, with the help ofcode reviews or test cases. Code reviews are manually executed where developersreview source code. It is a good practice during a development process, but whenthe software database reaches huge numbers such as millions of lines of code, itbecomes impossible to apply code reviews to every source code line because of timeconstraints. Test cases find defects, but many are still left undetected.

When defects are detected early in the software development process, beforethey are allowed to migrate to the next stage, fewer remain in the shipped productand they are less costly to correct than if they are discovered later in the process[5]. An important reason why it is more costly to correct defects the longer they areleft undetected is because additional code is written around the code containing thedefect. The task of finding the original defect in the growing layers of code becomesincreasingly costly the further downstream the error is detected.

Static code analysis (SCA) is a tool that can be applied to source code, oftenwithout ever executing the code, regardless of how big the source code is. It is alsoapplicable directly after the code is written, so defects are caught even before thetesting phase. Static code analysis tools do not find all defects either, but they area very cost effective and easy way to reduce a large number of defects early in thedevelopment life cycle.

The main references read to write this chapter are [6], [7], [8], [9], [10].

2.2 DefinitionsTo understand the terminology used in this thesis, this section defines the terms.An error is a mistake that introduces defects into software, or more formally definedas

“A human action that produces an incorrect result.”[11]

5

CHAPTER 2. STATIC CODE ANALYSIS

Defects, also called “bugs”, that are introduced into software are a faulty piece ofcode defined as

“A flaw in a component or system that can cause the componentor system to fail to perform its required function, e.g. anincorrect statement or data definition. A defect, if encounteredduring execution, may cause a failure of the component system.”[11]

Defects may cause failures which are defined as

“Deviation of the component or system from its expecteddelivery, service or result.”[11]

2.3 Techniques of static code analysisThis section briefly describes some techniques a modern static code analysis toolfrom Klocwork uses to analyse source code. This section is written from [12]. Moreinformation about how the static code analysis tool from Klocwork works is availablein the reference. The techniques involve building a representation or model of sourcecode, and then simulating all possible execution paths through that model, mappingout the flow of logic on those paths coupled with how and where data objects arecreated, used and destroyed.

2.3.1 Build process comprehensionTo accurately analyse the source code, the build environment is identified. Thisensures that the analysis is performed in the same way as the build itself. Thismeans understanding how files are compiled and linked, as well as other operationsthat affect the outcome such as code generation and file copying.

In the absence of a build process comprehension, the analysis is performed us-ing a naive model of the system, perhaps using inappropriate compiler emulation,incorrect file include locations or incomplete link targets.

2.3.2 Code compilationThe source code is compiled to build the various source code modules exactly as thenative build would. This ensures that the analysis will be done as if on the “real”compiled program. The compiler also creates an Abstract Syntax Tree (AST) whichrepresents the source code in a tree-structure. The tree contains a rich breakdown ofthe structure of the code in a non-ambiguous manner, allowing for simple searchesto be performed for anomalous syntax.

2.3.3 Syntax analysisThis analysis relates purely to the semantics of the source code. The AST is queriedfor patterns of usage that are to be restricted. This analysis can be used when

6

2.4. WHAT CAN STATIC CODE ANALYSIS DO?

searching for coding standard deviations (see 2.4.4), but it is not useful for findingdefects that require understanding of the runtime state of the program.

2.3.4 Data flow analysisControl flow graph

The control flow graph is determined by analysing the paths through the source codeand finding which ones might be traversed through a program during its execution.This creates control flows that can then be analysed with data flow analysis.

Data flow analysis

Data flow analysis is about monitoring the life cycle of data objects as they arecreated, assigned, used and deleted along one or more paths in the control flowgraph. Defects can be seen to occur as objects are used inappropriately based ontheir life cycle context. For example, objects that are used when they are knownto be assigned a problematic value, or which are deleted more than once, or evennever deleted.

2.3.5 Similarity to compilersS. Tucker argues that, since static code analysis tools need to understand the se-mantics of the program being analysed, they must be closely integrated into thebuild environment[13]. His solution is to integrate the SCA tool tightly with thecompiler to largely eliminate build environment problems. The idea presented inthe article is that the SCA tool uses the compiler’s syntax analysis (among otherthings) to understand the source code. For further reading, see the reference.

2.4 What can static code analysis do?There are a lot of different defects that static code analysis can find. They rangefrom potential runtime errors to resource leaks and security leaks. Static codeanalysis can also calculate metrics of the code, giving a number to certain attributesof it. It is also very helpful to enforce a coding standard that programmers need toabide to ease future development and maintenance of the product. Another featureof static code analysis is the ability to aid understanding of the architecture ofsource code by calculating dependencies between functions, classes, files etc.

As written by Emanuelsson et al, it is important to note that most propertieschecked by static analyses are undecidable, which means that it is impossible, evenin theory, to determine whether an arbitrary program exhibits the property ornot[6]. This leads to the analysis inferring that a property may hold. Sometimesthe analysis will state that a program has a specific property, while in reality itdoes not. This is known as a false positive. Other times, the analysis will notfind a specific property (could be because of inefficient property checking), while

7


the property actually does exist in the program. This is known as a false negative.The precision of static analysis depends on the time spent analysing. The moreprecise the analysis, the more resource and time consuming it is. This causes thesource code developer to make a trade-off, where he must decide how much timeand resources may be spent on finding defects. If the analysis is very fast, it willreport many false positives which is not wanted, but if the analysis instead is verythorough then it can take a very long time to complete.

Sections 2.4.1 and 2.4.2 explain some of the defects or potential errors that staticcode analysis can find, including an example of static code analysis used on sourcecode from a government project. Further on, in sections 2.4.3, 2.4.4 and 2.4.5 somemethods for improving the development process or understanding the architectureof source code with the use of static code analysis is explained.

2.4.1 Runtime errors

These classes of programming errors are very hard to diagnose because of themdepending on the program’s dynamic behavior[9]. Bush et al. presents a compile-time analyser that detects these dynamic errors in large real-world programs in [9].This analyser uses variants of the techniques described earlier (see 2.3.4).

Invalid pointer references, memory and resource leaks, faulty storage allocation,use of uninitialized memory, and improper operations on resources such as filesare all part of this subset. According to Bush et al, on the order of 90 percentof these errors are caused by the interaction of multiple functions in commercialC and C++ code[9]. Other errors in this subset include illegal operations suchas division by zero, calling arithmetic functions with illegal values, concurrencyviolations, deadlocks and Endian incompatibilities.

In areas such as space exploration, software systems critically need to be reliable.The Mars Climate Orbiter space exploration mission failed miserably because of aninexistent metrics conversion[14]. This led to an article written by Brat et al.[15]that analyses the impact of static code analysis in these reliability critical systems.The static code analysis tool used in the investigation found several runtime errorsin the software code of a subsequent mission - the Mars Exploration Rover. Theconclusion was that current weaknesses can be addressed by building specializedstatic code analysers that are dedicated to specific software families.

2.4.2 Security

Security vulnerabilities are prone to being attacked by ill-attempting programmers,or so called hackers. Buffer overflows (writing data beyond the end of an array),dangling pointer references (using pointers to point to memory locations with ma-licious code), and format string vulnerabilities (overwriting pointer addresses) areall part of the security threat. Wilander et al. present a paper of an empiricalcomparison of five publicly available static code analysis tools aimed to stop bufferoverflows and format string attacks[10]. The study explains the concept of chang-

8

2.4. WHAT CAN STATIC CODE ANALYSIS DO?

ing the flow of control, meaning the hacker changes the program’s control flow toexecute arbitrary code. It further explains the concepts of buffer overflows and for-mat string attacks. The conclusion from the comparison of the tools were that thecurrent state of static intrusion prevention tools is not satisfying.

To get a picture of how software vulnerabilities have been constantly increasing,the following picture illustrates data from the CERT1 Coordination Center [16]

Vulnerabilities reported to CERT

1090

2437

4129 3784 3780

5990

80647236

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

2000 2001 2002 2003 2004 2005 2006 2007

Year

Vulnerabilities

Figure 2.1. Software vulnerabilities reported to CERT 2000-2007

More information about security vulnerabilities is found in [8].

2.4.3 Software metrics

There have been many attempts to estimate or predict how many defects a softwaresystem will reveal in operation or testing. Most of the predictions are based oncomplexity or size of the code. The most common size metric is the number of linesof code (LOC), but other metrics are available, e.g. the number of subroutine callsor the number of decisions. Complexity metrics vary a lot, but McCabe’s cyclomaticcomplexity[17] is probably the most known, even though it essentially also is a sizemeasurement. Fan-in and fan-out are two measures of how much of a bottlenecka certain component in the system is. Fan-in measures the number of calls to acomponent, while fan-out calculates how many calls it makes itself. If a componenthas both a high fan-in and fan-out, then most likely it is a frequently used componentin the system, possibly reducing the performance of other components because theyhave to wait for it.

By calculating these software metrics, testers and designers get an understandingof the architecture of the system. This aids testers by helping them prioritizewhich system components need to be more thoroughly tested, and helps designers

1Computer Emergency Response Team

9


by showing how much throughput components have, possibly making designersredesign certain high-throughput components.

Further reading about software metrics can be found in [18].

2.4.4 Code Standard CheckingWhen developing software, a coding standard is very often used to enforce commonsemantics between developers. The coding standard enforces rules that developersneed to follow when developing software. These rules are typically targeted toenhance reliability, portability and maintainability. Reliability rules for preventingfailures, portability rules to make it easier for software to be used in other systems,and maintainability rules for ease of maintaining the software.

2.4.5 Architectural analysisTo determine the actual architecture of source code, it is possible to find dependen-cies between functions, files, classes and variables through an analysis. This leads toa number of outputs; graphical representations of dependencies in the source code,dependency matrices and source code comparisons are some possible outputs. Belowin figure 2.2, an example of dependencies between source code files is illustrated.

fileA.c

fileE.cfileB.c

fileF.c

fileD.c

fileC.c

fileG.c

Figure 2.2. Example of graphical representation of dependencies betweensource code files

10

Chapter 3

Development Life Cycle Phases

3.1 Introduction

A software development life-cycle model refers to a set of guidelines or rules that areused to structure, plan, and control the process of developing a software product.The development model is divided into phases, where each phase has a set of artifactsthat needs to be developed and maintained. The phases also involve a variety oftasks or activities that need to be done. By having a specific flow - depending onwhat model is used - through the different phases, productivity and quality of theproduct is improved because of organized development. There are a lot of differentdevelopment models, and they are just that; models. Companies need to tailor theirown specific development model for their specific needs, and this could lead to acombination of several development models.

System

engineering

Analysis

Maintenance

Testing

Code

Design

ÖSK 2009

Figure 3.1. The classic life cycle

The classic life cycle depicted in figure 3.1 above is the oldest and most widely usedmodel for software engineering[19]. It is sometimes called the “waterfall model”, anddemands a sequential approach to software development that begins at the system

11

CHAPTER 3. DEVELOPMENT LIFE CYCLE PHASES

level and progresses through analysis, design, coding, testing and maintenance.While this model has flaws such as being non-iterative, and requiring a lot of timebefore delivering a working product, it still has an important place in softwareengineering work. It provides a template and standard for development models.

This thesis focuses on life cycle phases close to the implementation phase (codingphase) since static code analysis is used on source code. It also focuses on thegeneral picture of development life cycles, making a sequential model a good choicefor studying. To further limit the phases of the model, system engineering andanalysis are grouped together to a phase called requirement since they handle theestablishment of requirements for the product. Maintenance will not be coveredsince it is a very large subject, and basically reapplies each of the preceding life-cycle steps to an existing product. This leads to the following development lifecycles with activities described in this chapter, depicted in figure 3.2 below.

Requirements Phase Design Phase Implementation Phase Validation and Verification

Phase

User requirement

analysis

System design

specificationCoding Test planning and control

Functional requirement

specification

Non-functional

requirement specification

Detailed design

specification

Other requirement

specification

Other design

specificationDebugging

Integrating Test analysis and design

Test implementation and

execution

Evaluating exit criteria

and reporting

Figure 3.2. Development life cycle

In the following sections, four phases of the development life cycle will be explained.In each phase, a number of artifacts that are or might be related to static codeanalysis will be listed.

3.2 Requirements phaseThe first inputs to a development process are the user requirements of the product.The customer ordering the development of a software product typically has a generalidea of what functionalities the end product is supposed to have. In the requirementsphase these requirements are analysed and used to create the basic structure of theproduct.

12

3.2. REQUIREMENTS PHASE

The requirements from the customer act as inputs to making requirements of theproduct from a more technical aspect. The overall results are technical requirementson the product as a whole and how it performs, not how it actually is going to doit.

3.2.1 Functional requirementsFunctional requirements define what the product is supposed to accomplish. Anexample of some very simple functional requirements for a soda vending machine isdepicted below in figure 3.3.

Functional requirements of vending machine

[1] Must cool the soda

[2] Must keep count of the soda

[3] Must display amount of soda left

[4] Must be able to accept bills

[5] Must be able to accept coins

[6] Must be able to give change

[7] Must be able to deliver three kinds of soda

[8] Must notify customer if stock is empty

[9] Must not accept false coins or bills

Figure 3.3. Functional requirements of vending machine

3.2.2 Non-functional requirementsNon-functional requirements determine the final quality of the product. They areused to limit the choices during implementation of the functional requirements byconstraining design decisions. According to Ambriola et al, there are six categoriesof quality factors that non-functional requirements can be perceived as instancesof[20].

• Efficiency; how the system exploits its resources or how well it performs.

• Portability; the ability of the system to be moved between hardware orsoftware environments.

• Maintainability; the ability of the system to react to changes or requirementmodifications.

• Expandability; the system’s ability of reacting to new components beingintegrated.

• Robustness; the system’s ability to react to incorrect inputs or faults incomponents.

• Security; the aspect of protecting the system and its data.

13


An example of some very simple non-functional requirements for the vending ma-chine example is given below in figure 3.4.

Non-functional requirements of vending machine

[1] Cool the soda to 6°C within 5 minutes

[2] The counting functionality must be operable on

hardware X and Y

[3] The counting functionality must be expandable to

accept new types of coins

[4] The system must tolerate up to 10N of force

[5] The software system manager module can only be

accessed with administrator rights

Figure 3.4. Non-functional requirements of vending machine

Non-functional requirement 1 relates to efficiency, 2 to portability, 3 to expandabil-ity, 4 to robustness and 5 to security.

3.2.3 Other requirements specificationThere are many other requirements specification methods; one of them is require-ments modeling. Greenspan et al. present a framework for requirement models in[21].

3.2.4 Artifacts of the requirements phase• Functional requirements document

• Non-functional requirements document

3.3 Design phaseIn the design phase the architecture of the product is established. Inputs to the de-sign phase is given from the outputs of the requirements phase, where requirementsof the product guide the design. The architecture defines components, their inter-faces and behaviors. The deliverable of the design phase is the design document,which is similar to a blueprint or plan for the solution. The design activity can bedivided into two separate activities - system design and detailed design.

3.3.1 System designIn this activity, the modules that should be in the system are identified. Theirspecification (what they should do) and the interaction between modules to producethe desired result is also identified. The purpose is to create “black-boxes” of allmodules in the system and link them together. It is important to identify inputs

14

3.3. DESIGN PHASE

and outputs of modules to be able to make abstractions of them, so developers canwork independently with one module without knowing everything about interactingmodules. There are many layers to system design as developers need to see the wholeconnection between small amounts of modules, but also an overview of interactionsof every module in the system. Below in figure 3.5, an example of structural designof some components of the vending machine is given.

Coin

managerBill manager

Hardware

Software

Coin slotBill slot

System

manager

Coin

validator

Change

manager

Change

slot

HA

L

Change

slot driver

Bill slot

driver

Coin validator

driver

Ap

plic

atio

n

laye

r

Figure 3.5. Some modules and interactions of vending machine

3.3.2 Detailed design

In detailed design, the internal logic of each of the modules is specified, often in ahigh-level language which is independent of the target language that the softwarewill be implemented in. The detailed design describes how the module is going toperform its specification. This includes features like how well it will perform, whatresources it will use, quality aspects and more. The requirements documents definehow many of these aspects should be introduced in the modules and they also defineto which extent.

3.3.3 Other design methods

There are many other models for designing software; executable modeling is one ofthem. Sunyé et al. describe a method for executable modeling and simulation[22].

3.3.4 Artifacts of the design phase

• System design document

• Detailed design document

15


3.4 Implementation phaseIn the implementation phase, the developers are implementing the actual sourcecode from deliverables of the design phase. Since the design documents specify whatcomponents do, and how they do it as well as interactions between components, itis possible for developers to work independently on modules. This parallelizes theimplementation of the code, making it more efficient. The source code modules arethen integrated to bigger modules, so testers can test integrated systems.

3.4.1 Debugging

Debugging is a part of the implementation phase. The purpose of debugging is tofind the cause of a defect, remove it, and verify that it has been removed correctly.In the validation and verification phase, failures will be detected, but the actualdefect will have to be found and fixed by the developer. To verify that the defecthas been removed correctly, debugging test cases are run. They are test cases thatfound the failure in the first case.

3.4.2 Artifacts of the implementation phase

• Source code modules

• Debugging test cases

3.5 Validation and verification phaseThe validation and verification phase is about validating that the product is beingdeveloped according to the user needs and requirements, and verifying that theproduct is developed correctly according to development requirements. This sectionis dedicated to verification through testing. Testing is done to give confidence inthe quality of the software. If few or no defects are found during testing, thenthat is a sound sign of good quality. If instead testing does find defects, then thequality of the system increases as these defects are corrected. It is important tonote though that few defects found does not necessarily mean good product quality,as low quality testing can lead to the same result.

3.5.1 The fundamental test process

To be able to find deviating behaviors of the product, test cases are developed.According to the ISTQB1 a test case is defined as

“A set of input values, execution preconditions, expected resultsand execution postconditions, developed for a particular objective

1International Software Testing Qualification Board

16

3.5. VALIDATION AND VERIFICATION PHASE

or test condition, such as to exercise a particular program pathor to verify compliance with a specific requirement.”[11]

Test cases are supported by the fundamental test process, where many other factorsplay a part in how the test cases should be developed and what they should target.It is impossible to test every aspect of a system, so it is important to carefullydetermine which aspects should be tested. The fundamental test process aids thisby analysing and planning how to execute the tests.

Test planning

and control

Test analysis

and design

Test

implementation

and execution

Evaluating exit

criteria and

reporting

Test closure

activities

BEGIN

END

Replan

Design more tests

Fix SW/TC Execute more

reporting

control

Figure 3.6. The fundamental test process

Figure 3.6 above illustrates the fundamental test process which begins with planningthe process as well as controlling it from the beginning. When planning the processit is important to state the objectives and missions of the testing, and specify theactivities needed to fulfill them as well as defining an exit criteria for when to stoptesting. It is also important to control the test process by monitoring if the testingis complying with the test plan, and if not, taking necessary actions.

Test analysis and design focuses on identifying test conditions2 and specifyingtest cases and test data based on these conditions and the requirements of theproduct. The test cases are prioritized depending on their importance. Specifyingexpected results is a part of designing test cases, and it is important that theyare derived from requirements or other artifacts, and not from the actual resultsof testing. This is true because testing is about measuring quality which meanscomparing expected results from actual results.

During test implementation, test procedures are specified. They are series of testcases which are run in a certain order. The order is based on earlier prioritizationof test cases, and also technical and logical dependencies between them. Some testcases depend on others already have been run.

2a test condition is an item or event that can be verified by one or more test cases e.g. functionalrequirement

17


When the test cases are executed, the results are compared to expected results,and all outcome is logged. If discrepancies are found they need to be reported asincidents, and their causes need to be analysed. They could appear because ofdefects in the code, in specified test data, in the test document, or a mistake in theway the test was executed. All of this is logged in the test log where relevant testexecution details, test case status and incident reports are all part of it.

When all test cases have been run, the exit criteria is evaluated. If the results ofthe testing are satisfying, then the test process proceeds to test closure activities,but if they are not then more test cases need to be developed and executed.

During the test closure activities, the final status of the project, as well as lessonslearned is documented.

3.5.2 Test levels

In the sections 3.5.3-3.5.5 below, different test levels are defined. They correspondto their equivalent development level. For example, component testing applies tothe smallest units developed in the implementation phase of the life cycle, wherefocus is on if and how the component satisfies its requirements, while system testingtests the overall requirements of the whole system.

3.5.3 Component testing

There is no exact definition of what a component is. Among other things it dependson the type of programming language used. A component can be an individualprocedure or function or a component may consist of several procedures or functions.If an object-oriented language is used, a component may consist of a class, parts of aclass hierarchy or a group of related classes. Aoyama defines software components as“binary units of independent production, acquisition and deployment that interactto form a functioning system”[23].

Test cases are derived from work products such as the specification of the com-ponent, the software design or the data model. One important goal of componenttesting is to cover the complete component with test cases, even possible future useof the component.

Component testing often focus on the functionality of the component, but mayalso include testing of several non-functional characteristics, such as resource be-havior or robustness, as well as some structural testing such as branch coverage.

Components are tested separately or in clusters, and they often have some inputsthat need to be simulated in order to test the component. Outputs may also have tobe analysed. Therefore stubs and drivers are used. Pressman describes a driver as“a “main program” that accepts test case data, passes such data to the componentand prints relevant results.” He further describes a stub as “Stubs serve to replacemodules that are subordinate (called by) the component to be tested. A stubuses the subordinate module’s interface, may do minimal data manipulation, printsverification of entry, and returns control to the module undergoing testing.”[19]

18

3.5. VALIDATION AND VERIFICATION PHASE

3.5.4 Integration testingIntegration testing tests interfaces and interactions between components. Whenassembling the components together to create the full system, it is important toinvestigate if the assembled system works as it should. This should be done inincrements because it is very likely that the fully integrated system will not workas expected.

Component A

Component B Component C

Component EComponent D

Control

flow

Figure 3.7. Full system component integration

Component A

Component B

Component D-E stub

Component B

Component EComponent D

Component A Driver Control

flow

Figure 3.8. Integration with stub and driver

Figure 3.7 above illustrates the integration of all components in a system. In figure3.8 above, a stub that simulates component D and E is used to test the integration ofcomponent A and B. A driver simulating component A is used to test the integrationbetween components B, D and E as well. There are two approaches to integratecomponents in increments:

Top-down integration

Integrating components from the top of the control hierarchy, going downwards isone way of incremental integration. Stubs are used to replace low-level modules.One big issue with this approach is that performance critical components of thesystem tend to be integrated last since they generally exist closest to the hardware,far away from the user interface. Defects in performance critical parts of the system

19


often cause architectural changes, which take time and thus should be discovered asearly as possible. A big advantage of this approach is that after the first moduleshave been integrated, the integration can be done in parallel.

Bottom-up integration

Bottom-up integration starts by integrating the performance critical parts of thesystem first. Several teams can start integrating different parts of the system in-dependent of one another. The need for stubs is eliminated in this approach sinceprocessing required for modules subordinate to a given level is always available.Drivers are used to simulate higher level modules. One issue with this approachis that the top level modules are integrated last, meaning top components such asuser interfaces cannot be tested until the very end of the integration.

3.5.5 System testing

System testing is concerned with the behavior of the whole system. System func-tionality and system non-functionality are the big categories that are tested in thisphase. Functional system testing focuses on determining if the system does what itshould according to the requirements. Non-functional system testing instead focuseson how the system meets the requirements.

Artifacts of the V&V phase

• Test analysis document

• Test cases

• Test logs

3.6 Conclusions

Questions 1-4 are answered below. The discussion and motivation of the answersare found in section 8.1. The artifacts listed in the answer to question 3 are verycoarse grained. Why this is the case is also discussed in section 8.1.

Q1 Where in the development process shall static code analysis beintegrated?

• During the implementation phase.

• During integration testing in the validation and verification phase.

• During test analysis of the fundamental test process.

20

3.6. CONCLUSIONS

Q2 How shall static code analysis be integrated into the developmentprocess?

• In the implementation phase, developers should always run static code analysisbefore they check-in their code to find runtime errors and security defects. TheSCA tool should be integrated with the build environment (see figure 3.9 below).

• In the implementation phase, static code analysis should be used after check-into calculate metrics and the architecture.

Code Build Check-in Static

code

analysisStatic

code

analysis

Figure 3.9. How static code analysis should be implemented in the implemen-tation phase

• During integration testing, static code analysis should be used to see if defectsare introduced when components interact with each other.

• Static code analysis should be used prior to a release of the product to ensuremaximum quality.

Q3 What artifacts are affected by static code analysis?

• Source code modules

• System design document

• Detailed design document

• Functional requirements document

• Non-functional requirements document

• Test cases

• Test logs

• Test analysis document

Q4 Can static code analysis in the development process be automated?

There is no yes or no answer to this question. Some of the tasks that can beautomated are discussed in section 8.1.

21

Chapter 4

Traceability

4.1 Introduction

Requirements Phase Design Phase Implementation PhaseValidation and Verification

Phase

Functional Requirement System Design Source Code Module Test Case

Figure 4.1. An example of artifact traces in a development life cycle

Figure 4.1 above is an example to illustrate that during the development life cycle,artifacts are related. The design of the system is created based on the functionalrequirement. The source code is implemented as the system design specifies. A testcase is created to verify that the functional requirement is satisfied by the sourcecode.

Software traceability is the ability to relate artifacts created during the devel-opment of a software system to describe the system from different perspectives andlevels of abstraction with each other, the stakeholders that have contributed to thecreation of the artifacts, and the rationale that explains the form of the artifacts[24].Further reading about traceability can be found in [25], [26] and [27].

4.2 Deployment of traceability

Traceability relations present information that can be used in different activities inthe software development life cycle.

They can be used to establish the impact that potential changes in some partof the system may have in other parts and make decisions about whether or notsuch changes should be introduced, and with what priority[24]. The simplest formof analysing the impact of a change in a given artifact is the identification of all theother artifacts that are affected by the change.

23

CHAPTER 4. TRACEABILITY

Traceability relations may also be used to check the existence of appropriatetest cases for verifying different requirements and to retrieve such cases for furthertesting. This helps by, for example, providing the ability to be certain that everyrequirement is associated with at least one test case.

There are more deployments of traceability, one of them is understanding thesoftware artifacts which is explained below in section 4.3. For further reading abouttraceability deployments see [24].

4.3 Trace dependencies

Trace dependencies describe relationships between different artifacts such as re-quirements, designs, system components, source code, test cases etc. By recordingand maintaining these dependencies, it is possible to ease software understandingand help developers that need to answer questions such as “Why is this require-ment needed?”, or “What will happen to the requirements and design if I changethis source code?”. Looking at the trace dependencies gives understanding of theorigin, rationale or realization of software development artifacts.

Egyed et al. give an example of the dynamic nature of trace dependencies: “Ifa requirement R leads to the implementation of some source code C then a tracedependency exists between the two. If the requirement changes then the source codeis potentially affected. Conversely, a change to the source could make an update ofthe requirement necessary. This bi-directionality is very important for trace analysisand implies that if R depends on C then C depends on, at least, R.” [28]

The problem with only connecting life cycle artifacts with each other throughsimple links is that the rationale behind the development of the artifacts is lost.With simple links the implicit relationship between for instance design objectsmight be lost, causing problems such as misunderstanding of design architectureor ignoring business goals and constraints.

Good traceability ensures that the rationale behind developing artifacts andtheir traces is documented. This helps for instance architects and designers bymaking them understand the reasoning of an architecture design. It helps themanalyse the change impact of a design through forward tracing, as well as makesthem able to analyse the root-cause of a design through backward tracing.

4.3.1 An example of traceability

Figure 4.2 illustrates a simple relationship between a customer requirement andthree functional requirements designed to satisfy it. The links are used to tracethe relationship between the artifacts. While this is a sound approach to linkingartifacts, the rationale behind the relationships is not documented. In figure 4.3,the rationale is added into the relationship between the artifacts. This gives a goodlinkage between them, and makes the relationship easy to follow.

24

4.3. TRACE DEPENDENCIES

Customer requirement Functional requirements

[1] It shall be possible for the

user to chat with other users

[2] The main window will

have a ”chat” button that

opens a chat window

[3] The chat window will list

all online users, and their

status

[4] The chat window will

have a ”start chat” button

that starts a chat with the

selected user

Figure 4.2. Relationship between artifacts

Customer requirement Functional requirements

[1] It shall be possible for the

user to chat with other users

[2] The main window will

have a ”chat” button that

opens a chat window

[3] The chat window will list

all online users, and their

status

[4] The chat window will

have a ”start chat” button

that starts a chat with the

selected user

This requirement is satisfied by 2 means:

· Providing a button in the main view

for chatting

· Providing a chat window that allows

the user to choose whom to chat

with

Figure 4.3. Relationship between artifacts with rationale

25

CHAPTER 4. TRACEABILITY

4.4 Representation of traceability linksThere is no standard way to store or represent traceability links[29]. Tradition-ally, they are stored as a matrix and represented as graphs. The simplicity of thismethod is its main advantage, but it is not suitable for representation of all infor-mation relevant to the traceability links. According to Marcus et al.[29] traceabilitylinks have intrinsic components: source and target. They are elements in the link,with properties such as artifact name, artifact type (requirement, test case, etc.),location, creation time, update time, version, etc. These elements store informationabout the two artifacts the link binds together. In addition, the traceability linkalso has several general properties such as: creation time, update time, documen-tation (which can contain rationale description and author information), version(which also provides a reference to the previous structure of the link that evolvedto the current version), usage history (which users browsed this link and when),status (active or deleted), etc. This provides developers the possibility to sort linksaccording to preference. For example, during maintenance of the links, the devel-oper can list only links that are not up to date anymore, because the source or thetarget of the link had been changed.

Marcus et al.[29] continue to argue that traceability links are best used whenvisualized in the developer’s IDE1 because of many software development toolstoday already being integrated into the IDE. This helps by, in simplicity, adding atool that visualizes artifact links in the developer’s IDE, supporting the developerin understanding links between artifacts.

1Integrated development environment

26

Chapter 5

IBM Jazz

5.1 IntroductionIBM Jazz is an initiative of IBM Rational, where the goal is to make software de-livery teams more effective. Jazz delivers an architecture for life cycle integrationthat is based on open, flexible services and Internet architecture. This is made pos-sible by the introduction of Open Services for Lifecycle Collaboration[30] (OSLC).Rational Team Concert is a tool developed by IBM based on the Jazz IntegrationArchitecture and the services of OSLC, providing an environment for developers,architects and project managers to trace and manage work items1, source controland builds in a configurable development process.

5.2 Jazz Integration ArchitectureThe Jazz integration architecture[31] is used to enable tools to collaborate by pro-viding a way to share tool data, as well as a way to provide tool interaction. At thecore of the integration architecture is the Jazz Team Server (JTS), which providesfoundational services from the Jazz Foundation Services to enable groups of tools towork together. The goal of the architecture is to enable tools to easily share data,and enable better integration of - and navigation between - the user interfaces ofdifferent tools.

5.2.1 RESTful web services

The data and services need to be available to as many clients as possible, so a toolexposes its data and services through a resource-oriented web service, from hereon called REST API. The web service is created from specifications of the originalREST architecture[32]. This web service enables tools to access data and otherimportant information from other tools.

1Jazz work items are generalized notions of development tasks e.g. correct a defect, or imple-ment a new feature

27

CHAPTER 5. IBM JAZZ

The REST API provides three key things: URLs2 for the tool data resources; docu-mented representations for those data resources; and a protocol and operations formanipulating those data resources based on standard HTTP methods. By providingURLs for the tool data resources, they can be linked from anywhere, enabling globaldistribution of data and interoperability. A simple CRUD (Create, Read, Update,Delete) interface is provided by the operations POST, GET, PUT and DELETEfrom the REST API. This gives tools the ability to add, read or manipulate datafrom other tools that expose their data and services through the REST API.

5.2.2 Jazz Team ServerA Jazz Team Server provides the foundational services a group of tools need to worktogether. These services enable the basics of project administration, security, col-laboration, query and other cross-tool interactions. All these services are RESTful,meaning they implement the REST API. They do not however specify specific toolattributes; this is addressed by the addition of Jazz Team Server Extensions. Everytool that is integrated with the Jazz framework can specify its own set of RESTfulservices that are then added to the Jazz Team Server through a Jazz Team ServerExtension. This extension is a tool-specific functionality which is needed to makeeach tool expose its specific data and services to other tools. For example the Ra-tional Team Concert product adds functionality to the Jazz Team Server as serverextensions.

All interactions between tools goes through the REST API, depicted in figure5.1 below. This ensures loose coupling between tools that is necessary to eliminatethe traditional barriers between tool data and interaction.

Tool B – Server Extension

REST API

Tool A – Server Extension

REST API Jazz Foundation Services

REST API

· Discovery

· Administration

· Query

· Presentation

· Process

· ...

Jazz

Team Server

User of Tool A

User of Tool B

Figure 5.1. Jazz Team Server

2Uniform Resource Locators

28

5.2. JAZZ INTEGRATION ARCHITECTURE

5.2.3 JTS ApplicationsIBM has created three applications to the Jazz Team Server as of now. The threeapplications are Requirements Management (RM), Change and Configuration Man-agement (CCM) and Quality Management (QM), each dedicated to its own life cycledomain. A life cycle domain handles specific activities and artifacts of some partof the development life cycle. These domains are somewhat related to the phasesdescribed in chapter 3. RM and QM correspond to the requirements phase andthe validation & verification phase respectively. CCM has a broader scope, andhandles interactions through several phases, e.g. a defect found during integrationtesting demands a change request for the design. The design phase from chapter 3does not have a directly related domain in the Jazz Team Server. The domains arespecified by OSLC, and the closest OSLC-specified domain to the design phase isthe Architecture Management domain. As of this moment, the applications in theJTS do not support this domain. See section 8.4.1 for more information.

Requirements Management

RM handles activities and artifacts related to requirements. It is possible to createrequirements and requirement collections and link them to artifacts of other domainssuch as test cases or work items. Requirements are simple documents that areeditable through a web client connected to the RM application of the Jazz TeamServer.

Change and Configuration Management

CCM handles work items, source control management, builds, plans and reports.Work items are artifacts which specify what needs to be done. They are dividedinto types such as “Defect”, “Task” or “Risk”. Source control management handlesbaselines and versioning of delivered source code. The CCM domain is the centralpart of the development life cycle.

Quality Management

QM handles all artifacts related to validation and verification such as test cases,test suites and test results.

5.2.4 Change and Configuration ManagementThe CCM Services consists of capabilities that enable a client to create, retrieve,update and delete resources in the CCM domain. To be able to create and mod-ify resources in the CCM domain, the CCM Services need to be located. TheCCM Services are accessible via a Service Provider Resource that describes the cre-ation, query and delegated UI3 capabilities of each Service. Additionally, a Service

3User Interface

29

CHAPTER 5. IBM JAZZ

Provider Catalog lists several Service Providers, each linked to its own project area4.The Service Provider Catalog is listed in the Root Services. The Root Services canbe found via an HTTP GET to the address https://{jts-ip}:9443/ccm/rootservices.

The Services provide Creation Factories for resource creation, Query Capabilitiesfor resource query and Delegated UI Dialogs to enable clients to create and selectresources via a web UI. Figure 5.2 below illustrates relationships between resourcesin the CCM application.

Service Provider

CatalogService Provider Service

Creation Factory Query CapabilityDelegated UI

Dialog

Resource

Lists Lists

Creates

Provides ProvidesProvides

Creation UI

Queries

Root Services

Lists

Provides

Selection UI

Figure 5.2. CCM Services and relationships

Creation Factories

A creation factory enables the creation of new resources. It provides a URI5 usedto create new resources via HTTP POST. When a client wants to create a newresource, it HTTP POSTs a representation of the new resource to the URI specifiedin the creation factory.

Query Capability

A query capability enables querying of resources. This enables clients to discoverresources managed by a Service. By also adding a URI Query String to express the

4The CCM application can include several projects. A project area is the location for artifactsand resources related to a specific project.

5Uniform Resource Identifier

30

5.2. JAZZ INTEGRATION ARCHITECTURE

query criteria (e.g. high priority defects) the client can discover resources relatedto that query criteria.

Delegated User Interface Dialogs

When a user using a web application needs to create a new resource in a ServiceProvider, or choose a resource managed by the Provider, Delegated UI Dialogs areused. The Delegated UI Dialog provides a UI for the user to create or choose aresource from a Provider. This enables tools to interact without regards to thetools internal states.

Links

There are many different artifact link types in the Jazz Team Server. All links arebidirectional, e.g. an Implement work item wi implements requirement req, whilereq is implemented by wi. The links are simple, sharing no more information thanthe bidirectional type. They correspond to the specifications of OSLC.

Even though the links in the Jazz Team Server are only simple, OSLC specifiesa richer link called anchor. The anchor includes property values that are used todescribe the link. Figure 5.3 below illustrates an example of an anchor.

Anchor

Customer

Subscribes to

Expiration date

Annual price

Delivery address

Magazine

Figure 5.3. Anchor link

A customer subscribes to a magazine which could be modeled as a simple link, butthe subscription includes a number of factors such as expiration date, price anddelivery address. By using an anchor, these properties can be added to the link.

Link rendering

When hovering the mouse pointer over a link in the Jazz Team Server, a mechanismfor retrieving information about the target of the link is returned and displayedin a popup window. This mechanism is called Jazz compact rendering. A linkbasically contains two elements: a URI to the target of the link, and a name ofthe link type. To retrieve information from the target resource, a GET request issent to the URI with a specific header called application/x-jazz-compact-rendering.

31

CHAPTER 5. IBM JAZZ

The header includes extra information to the GET request. The response fromthe target resource includes the title, icon, small preview and large preview of thetarget resource. The previews show a summary of the resource with either muchinformation (large) or less information (small).

Login and authentication

To access protected resources the user needs to authenticate and pass the JazzTeam Server security mechanisms. The Root Services document is not a protectedresource, but if the user wants to interact with the JTS, the Service Provider catalogdocument is needed, and that document is protected. JTS uses a Form-basedAuthentication with three steps depicted below in figure 5.4.

Client

Jazz

Team

Server

1

2

3

Request protected resource

Redirect to login page

Submit the login Form

Return the login result

Re-Request protected resource

Protected resource

Figure 5.4. JTS Form-Based Authentication

5.3 ConclusionsQuestions 5-7 are answered in this section. The answers are discussed and motivatedin section 8.1. Question 5 is a very broad question, therefore the answer is restrictedto the representation of artifacts in the Jazz Team Server. This is also discussed insection 8.1.

Q5 What requirements does static code analysis impose on therepresentation of artifacts to ensure traceability?

Representations of artifacts are available in the Jazz Team Server when connectingthrough a web client to any of the JTS applications (see section 5.2.3). The require-ments below were derived from conclusions of the theoretical study of traceabilityand analysis of the Jazz Team Server.

• req1 The ability to link to static code analysis artifacts6.

6an output from a SCA tool, e.g. code review or metrics report

32

5.3. CONCLUSIONS

• req2 The ability to follow these links, both forward and backward.

• req3 Links should have properties defined in figure 5.5 below.

Representation of relationship between artifacts

Generic artifactStatic code analysis

artifact

Link Information

Creation time

Update time

Version

Usage history

Status


TypeSource code module

Priority

Figure 5.5. Representation of SCA traceability link

Why these properties are important is discussed in section 8.1.

Q6 Is it possible to ensure traceability between defects and designartifacts?

The implementation of this thesis does not include a full development life cyclewith associated design artifacts, concluding that this question is mostly discussedin section 8.1, with some input from the experience of the implementation.

Q7 What other traceability can static code analysis assist?

This is a more general question about SCA traceability. Apart from ensuring trace-ability between defects and design, what other traceability can exist between SCAartifacts and other artifacts of the development life cycle? This is discussed insection 8.1 and 8.3.2.

33

Chapter 6

Design and Implementation

The first part of this chapter describes the method of analysing the architecture ofOpenGL ES 1.1 for the Freescale i.MX31 ADS in Linux with a static code analy-sis tool. The other part describes the java application that integrates static codeanalysis artifacts and links into the Jazz Team Server applications.

6.1 Use Case

6.1.1 Introduction

See section 1.3 for motivation of the use case.To be able to analyse the architecture of a source code package, a static code

analysis tool was used. The SCA tool needs to be able to perform architectural anal-ysis (see section 2.4.5). Three different tools were investigated when deciding whichone to use in this thesis: Rational Software Analyzer[33], SciTools Understand[34]and Klocwork Architect[35].

Klocwork Architect needs to have a working makefile-system to analyse thesource code, and since this was not available in the source code, this tool wasdismissed. Rational Software Analyzer did not provide any architectural results.Why this was the case was never investigated thoroughly, as the last tool did provideresults. The choice fell on SciTools Understand since it was the only tool capableof describing the architecture of the source code package.

6.1.2 SciTools Understand

Understand is a static code analysis tool that parses source code to learn of de-pendencies in the code or calculate metrics of the code, as well as other analyses.It supports many programming languages such as Ada, C/C++, C#, FORTRAN,Java, VHDL, HTML, PHP, CSS and some others. A limitation is that the tooldoes not require a build environment, meaning that it does not utilize the tech-nique from section 2.3.1. There are two important features that aids understandingdependencies of a source code package. They are described below.

35

CHAPTER 6. DESIGN AND IMPLEMENTATION

Dependency browser

The dependency browser is used to examine which items are dependent on others.This can be applied to architecture nodes (e.g. folders), files, classes, packages andinterfaces. It is possible to either show items which are depended on the currentitem, or depended on by the current item. An item depends on another if it includes,calls, uses, casts or otherwise refers to that item. Below is a picture illustrating thedependency browser.

Figure 6.1. Dependency browser showing items that jutils.c depends on.

Dependency graphs

Dependency graphs show a graphical representation of how items are related. It isused to see an overview of relationships the item has. It is possible to show bothdepends on, depended on by or a combination of both. Below is a figure showinga dependency graph. The numbers in the picture correspond to the amount ofdependencies (see Dependency browser above).

includeext

hwdefs

egl services_um

include

eglcommon

138

1847

420

4

Figure 6.2. Dependency graph showing folders that the folder egl depends on

36

6.2. JAVA APPLICATION

Other features

There are a number of other features that aid the understanding of source codesuch as treemaps, metrics and control flow graphs. These features were not usedwhen describing the architecture of the package since they were not helpful inunderstanding dependencies between modules of the package which was the goal.

6.1.3 The approach and goal of the analysis

The goal was to describe the architecture of the source code package. This wasdone by identifying critical modules and finding dependencies between them. Thefinal product is a picture illustrating the architecture of the package.

Identifying critical modules

Modules were defined by the folder structure in the package. To identify whichones were critical, there was a need to draw the graph of the whole system whereall modules were involved, and see which modules were more involved than others.Then the dependency browser was used to further narrow down the modules byinvestigating if the dependencies were necessary for OpenGL operations.

Finding dependencies

By combining results from the dependency browser and dependency graphs, thedependency structure of the package could be explained. The critical modules wereinvestigated one by one to see the direct relationships between one module and therest.

6.2 Java ApplicationThe motivation for the java application is found in section 1.3. The SCA artifactsthat were uploaded to the Jazz Team Server were derived from Understand andRational Software Analyzer (RSAR), analysing the source code package describedin section A.1.4. RSAR provides a metrics report and a coding standard report,while Understand provides architectural images. These three artifacts were chosensince they are an important part of integrating SCA into a development process.RSAR and Understand were not able to provide any other artifacts when run onthe source code package (such as defect reports).

6.2.1 Setup

A project area was established in the Jazz Team Server CCM application. A newwork item called “Implement” was created through a web client. This work itemrepresents a source code module that needs to be implemented. Another new workitem, called “Design” was also created. It represents the design architecture of the

37


source code module. In the Requirements Management and Quality Managementapplications, requirements and test cases were added to the project area space, andthe work items, requirements and test cases were linked together. This created asimulated life cycle management project with some artifacts from the four life cyclephases described in chapter 3.

6.2.2 MotivationThe SCA artifacts were uploaded as attachments because when this is done, thefunctionality of the java libraries automatically uploads the artifacts and createslinks to them.

The two features in the java application were implemented to give an exampleof what possibilities exists in the Jazz Team Server. They can be used when inves-tigating the possibilities of modifying an existing SCA tool to modify artifacts inthe JTS (see 8.4). The last requirement in the section below was also created todemonstrate the possibilities of the Jazz Team Server.

6.2.3 SpecificationThe java client application connects to the Jazz Team Server CCM domain andadds SCA artifacts to the project area. To do this, the client uses the REST APIdescribed in 5.2.1, and connects to the relevant Services according to 5.2.4. Twofeatures were implemented. The first is a possibility to add a new work item ifthe developer thinks the SCA architecture is too different from the original designarchitecture. The second is about the same but is used when the developer thinksthere are too many coding standard deviations found by static code analysis.

The IBM Jazz work team has provided java libraries that enable a client toconnect to a CCM project area and modify or create work items with the RESTfulAPI. The requirements for the java client are shown below.

Requirements

SCA artifacts shall be integrated into the Jazz Team Server.

• req1 The artifacts shall be integrated into the Jazz Team Server through at-tachments.

• req2 Three types of artifacts shall be integrated: metrics, coding standardreport and graphical architecture.

Two features shall be implemented in the java client.

• req3 Implement Feature 1: Add a new “Defect” work item with the same linksas the “Implement” work item and a link to the SCA architecture artifact.

• req4 Implement Feature 2: Add a new “Defect” work item with the same linksas the “Implement” work item and a link to the coding standard report artifact.

38


To be able to analyse traceability in the Jazz Team Server, several link types shallbe used when linking to SCA artifacts. There are two possible link types whenlinking to uploaded files; “Attachment” and “Related Artifact”.

• req5 Use the link type “Attachment”.req5.1 The “Attachment” link type shall be used in the “Implement” workitem.

• req6 Use the link type “Related Artifact”.req6.1 The “Related Artifact” link type shall be used in the created “Defect”work items.

If a feature was chosen, create a link to the original “Implement” work item fromthe new work item.

• req7 Create a “Blocks” link to the “Implement” work item from the new workitem.

6.2.4 Java librariesThe java libraries created by the IBM Jazz work group provides a java interface tothe REST API. The crucial java instances used when implementing the java clientare explained below.

WorkItemClient

The WorkItemClient handles querying of work items and can return the WorkItem-WorkingCopyManager which is used to operate on work items. The WorkItemClientis also used to get the work item types and categories from the project area. Whena work item is found by querying, a handle is returned.

WorkItemWorkingCopyManager

The WorkItemWorkingCopyManager connects to a work item handle and is used tosave the changes made to the work item.

WorkItemWorkingCopy

AWorkItemWorkingCopy is fetched from theWorkItemWorkingCopyManager. Thisinstance is used to get a java object of the actual work item so it can be modified.It is also used to get the list of references of the work item. References are links toother artifacts.

6.2.5 The Java ClientThis section describes the implementation of the Java application that integratesstatic code analysis artifacts into the Jazz Team Server.

39


Work Flow Chart

The work flow chart below illustrates the action flow of the java client. The clientconnects to the JTS repository and HTTP GETs the CCM Service to be able tomodify and add work items. Then the static code analysis artifacts are added tothe “Implement” Work Item through attachments. If chosen, a new work item isthen created which inherits all links from the “Implement” Work Item, and gets alink to the SCA architecture image as well. Another work item is created - if chosen- which inherits the same links as the “Implement” work item as well, but the SCAartifact linked to this time is the coding standard report.

startLogin to

repository

Find Project

Area

end

Get Work Item

Type ”Defect”

Get

WorkItemClient

Get

WorkItemWorking

CopyManager

Get Work Item

Category

Get Working

Copy of

Implement WI

Get references

of Implement WI

Add SCA

attachments to

references

Add architecture

defect WI?

Create new

Defect WI

Copy

references from

Implement WI

Add link to SCA

arch. image to

Defect WI

Add coding

standard defect

WI?

Create new

Defect WI

Copy

references from

Implement WI

Add link to SCA

coding standard

report to Defect

WI

Save and

disconnect

Yes

No

Yes

No

Figure 6.3. Work flow chart of the java application

Login and authentication

The provided java libraries handle the authentication automatically when providedwith a user name, password and the Jazz Team Server IP-address. The authentica-tion was done according to 5.2.4.

Project Area

The project area includes specific work item types and categories for that area. Tobe able to create new work items, the work item type and category have to bedeclared. This implementation created work items of the type “Defect” belongingto “Category 1”. Categories are used to organize work items.

40


Adding attachments

To add attachments to a work item, the work item has to be fetched, either byquerying or by creating a new work item. The WorkItemWorkingCopy is used toget the references of the work item. The references are organized in types e.g.“Defect”, “Task”, “Implement”. Attachments were added with the following linesof code:

File file = new File("{location-of-file }");IReference reference =

IReferenceFactory.INSTANCE.createReferenceFromURI(file.toURI(),file.getName());

references.add(WorkItemEndPoints.ATTACHMENT, reference);

where references was fetched from the WorkItemWorkingCopy. When the workitem was saved, the WorkItemWorkingCopyManager automatically uploaded theattachment file to the JTS storage, and created and added an “Attachment” linkto the work item that links to the attachment file.

Creating new work items

The new work items were created by creating and connecting to a new work itemhandle with the WorkItemWorkingCopyManager. The properties of the new workitem were modified by getting a java instance of it from the WorkItemWorking-Copy. The modifications were changing the titles of the work items, and addingdescriptions to them.

Copying links

To copy links from one work item to another, the references of the source work itemhas to be fetched. This is done by calling getReferences() from the WorkItem-WorkingCopy of the source work item. Then, depending on if the reference is toanother CCM work item or to another domain, two different methods are used:

IItemHandle itemHandle = attachmentReference.getReferencedItem();IReference reference =

IReferenceFactory.INSTANCE.createReferenceToItem(itemHandle);

references.add(endPointDesc, reference);

This first method is used when the target of the link is in the CCM domain. The firstline resolves the attachment to a handle. The second line creates a new reference tothe item. The last line adds the reference to the target work item. endPointDescdefines the link type, e.g. “Related Artifact”. This method was used when copyinglinks between work items.

41


URI attachmentHandle = attachmentReference.createURI();IReference reference =

IReferenceFactory.INSTANCE.createReferenceFromURI(attachmentHandle);

references2.add(endPointDesc, reference);

This second method is used when the target of the link is in another domain thanCCM. The first line creates a URI address to the referenced item. The second linecreates a new reference from the URI, and the last line adds the new reference to thetarget work item. This method was used when copying links between work itemsand artifacts from other domains; test cases and requirements.

Creating specific links

To satisfy req7 and req7.1 , the links created in the new work items were imple-mented with the following lines of code where WorkItemEndPoints.RELATED_ARTIFACTdefines the link type.

IItemHandle itemHandle = attachmentReference.getReferencedItem();IReference reference =

IReferenceFactory.INSTANCE.createReferenceToItem(itemHandle);

references.add(WorkItemEndPoints.RELATED_ARTIFACT, reference);

To satisfy req8 , the following lines of code were used where workitem11 is thehandle to the “Implement” work item.

IReference reference =WorkItemLinkTypes.createWorkItemReference(workitem11);

references.add(WorkItemEndPoints.BLOCKS_WORK_ITEM, reference);

6.3 ConclusionsTo describe the architecture of the source code package, the static code analysis toolUnderstand was used. The features Dependency browser and Dependency graphswere used to identify critical modules of the system, and the dependencies betweenthem. In the end, a final picture was drawn which illustrates the architecture of thepackage by dividing modules into areas and describing APIs and relations betweenthem (see appendix A).

To add traceability of static code analysis artifacts to the Jazz Team Serverapplications, artifacts from Rational Software Analyzer and Understand were cre-ated as pdf reports and jpeg images. They were then added as attachments tothe “Implement” work item whose purpose is to add functionality as a source codemodule. Two work items were then created to visually represent the need to correct

42

6.3. CONCLUSIONS

an architectural defect and several coding standard mistakes. These two new workitems inherited the same links as the “Implement” work item, creating traceabilitybetween all the life cycle artifacts connected to the source code module. The rele-vant SCA artifact was linked to each of the new work items with the type “RelatedArtifact”.

The traceability of this life cycle project has been analysed and compared to theconclusions from section 5.3. This is discussed in section 8.2.2 and 8.3.2.

43

Chapter 7

Results

7.1 The “Implement” work item

The left part of figure 7.1 below illustrates the links of the “Implement” work itemafter the setup in section 6.2.1. The “Implement” work item has links to a require-ment, a test case and a work item (“Design” work item). The right part of figure7.1 below depicts the links of the “Implement” work item after the java applicationhas performed the link additions. Three “Attachment” links are added, as well astwo “Depends On” links toward the new “Defect” work items.

Figure 7.1. The “Implement” work item before (left) and after (right) the javaclient

45

CHAPTER 7. RESULTS

7.2 The “Defect” work items

The left part in figure 7.2 below illustrates the links of the created architecture“Defect” work item. It has the same three links as the pre-modified “Implement”work item, and also a “Related Artifact” link to the SCA architecture artifact anda “Blocks” link to the “Implement” work item. The right part in figure 7.2 belowdepicts about the same information, but the “Related Artifact” link links to thecoding standard report instead.

Figure 7.2. The new architecture “Defect” work item (left), and the newcoding standard “Defect” work item (right)

46

7.3. LINK PROPERTIES

7.3 Link properties

Figure 7.3 below illustrates what happens when hovering over the “Attachment”link to the jpeg picture. The jpeg-picture was revealed in a picture viewer. Whenhovering over the other “Attachment” links, there was no such functionality. Thiswas also the case when hovering over the “Related Artifact” link.

Figure 7.3. Hovering over jpeg in attachment link

47

CHAPTER 7. RESULTS

7.4 Overview of linksFigure 7.4 below illustrates an overview of all links between artifacts of the life cycleproject in the JTS. The normal arrows are links that were created with the javaapplication. The dashed arrows are links created in the setup (see section 6.2.1).

New Work Items

Requirement Design WI

Implement WI

Test Case

Coding

standard

report

Metrics

Report

Architectural

image

Coding

standard WI

Architectural

WI

Static Code Analysis Artifacts

Requirements Phase Design Phase Implementation Phase Validation and Verification

Phase

Figure 7.4. Overview of links in the life cycle project

48

Chapter 8

Discussion

8.1 Question discussionQ1 Where in the development process shallstatic code analysis be integrated?

Static code analysis can be used in a number of ways in the development process.Finding defects (section 2.4.1 and 2.4.2) and ensuring a coding standard is followed(section 2.4.4) should be used during the implementation phase of the developmentprocess since source code is first made in that phase (section 3.4). This ensures thatSCA is used as early as possible.

Calculating software metrics (section 2.4.3) and analysing software architecture(section 2.4.5) aid certain activities of the development life cycle. This should bedone as early as possible, and thus in the implementation phase.

During integration testing in the validation and verification phase, source codemodules are connected together to verify and validate that they accomplish whatthey should do together. Earlierly mentioned in section 2.4.1, on the order of 90percent of certain runtime errors are caused by the interaction of multiple functionsin commercial C and C++ code[2]. This leads to the conclusion that static codeanalysis should be used during integration testing.

During test analysis and design of the fundamental test process, test cases areprioritized. The prioritization depends on how important the specific test case is.This can be aided by using metric calculation from a static code analysis tool, whichconcludes that static code analysis should be used during test analysis.

Q2 How shall static code analysis be integrated into thedevelopment process?

In the implementation phase, developers should always run the static code analysistool before they check-in their code. A code module is checked-in to the sourcecontrol management repository when the developer is satisfied with his work, andwants the module to be unit tested (delivered to the next phase). This ensures

49

CHAPTER 8. DISCUSSION

that every component will have been analysed with static code analysis as early aspossible (before unit testing). As mentioned earlier in section 2.3.5, the SCA toolshould be integrated with the compiler to eliminate build environment problems.

Every component should also be measured with respect to code metrics af-ter check-in. In certain components, where the architecture of the component isessential, static code analysis should be used to describe the architecture of thedeveloped component, also after the module is checked in. They should be analysedafter check-in to ensure that the module is as final as possible in the implementa-tion phase. The results from the code measurement and architecture descriptionare documented, available for use by designers or testers.

Figure 8.1 below illustrates how static code analysis should be implemented inthe implementation phase.

Code Build Check-in Static

code

analysisStatic

code

analysis

Figure 8.1. How static code analysis should be implemented in the implemen-tation phase

During integration testing, static code analysis should be used to see if defectsare introduced when components interact with each other. This should be done onthe whole integrated system as well as on small integrated systems (constructed of afew components). When running static code analysis on the whole system, a lot ofdefects will probably be found. By running static code analysis continuously whenintegrating more and more modules, it is easier to understand the appearance ofnew defects.

Static code analysis should also be used prior to a release of the product toensure maximum quality. The static code analysis tool should be able to stop therelease if it finds severe defects. Another appliance of static code analysis is duringnightly builds of the system. There is a lot of time available during these builds,enabling the tool to search for defects with higher precision. Nightly analyses, aswell as the other analyses should be used, but the main focus should be on theregular analyses, during the day. This is because the nightly analyses analyse thewhole system, while regular analyses are more targeted towards smaller modules orsystems. Both are important, but nightly analyses cannot exclude regular analyses,while the opposite is true.

50

8.1. QUESTION DISCUSSION

Q3 What artifacts are affected by static code analysis?

The artifacts listed in the answer to question 3 (see section 3.6) are very coarsegrained. The reason for this is that this thesis focuses on the general picture ofdevelopment life cycle phases. Since development life cycles vary a lot dependingon the needs of the product in development, different activities and different artifactsare used when developing different products. An extension to this thesis would be toinvestigate a specific development life cycle model with more fine grained artifacts.See section 8.4 for more information.

When implementing the design, the static code analysis tool is run on source codemodules, meaning they are artifacts affected by the tool.

Designers can look at code metrics derived from the static code analysis toolto determine if a certain component is subject to design change. This would influ-ence artifacts of the design phase; the system design document and detailed designdocument.

When analysing why the design causes defects found by static code analysis,the cause could be artifacts from the requirements phase; structural requirementsdocument and non-structural requirements document. This relationship is indirect,but it is still viable for helping developers understand causes of static code analysisdefects. This is related to traceability (see section 4.3), in the sense that to be ableto understand the cause of the defect, the developer should have knowledge of thework flow up to the defect component.

During test integration, test cases will specify a target for static code analysisto find defects. The target is a set of integrated modules. This makes test cases anartifact affected by static code analysis. Test logs are created from the results ofthe test case, and if static code analysis defects are found during testing, then thetest log will document the defects, which means test logs are affected by the tool.Test engineers can use code metric data derived from the static code analysis toolwhen analysing the test environment, making the test analysis document affectedby static code analysis.

Q4 Can static code analysis in the development process be automated?

Some of the tasks of the tool can be automated. When developers implement theircomponent source code, the tool can be made to run automatically after the build isfinished. This can also be applied during nightly builds of the system, automaticallyrunning static code analysis on the whole system. When developers check-in theircode, static code analysis can automatically calculate code metrics of the module.During test analysis, code metrics from static code analysis will be used. Theprocess of prioritizing test cases can be partly automated by assigning risk levels tosystem components based on code metrics from the tool. This has to be manuallyprocessed as well, since code metrics are not the only factor when prioritizing testcases.

51


Q5 What requirements does static code analysis impose on therepresentation of artifacts to ensure traceability?

The information from traceability relations can be used in different activities in thedevelopment life cycle (see section 4.2). This means that several different developersuse traceability in some part of the development life cycle, e.g. design engineers,test engineers etc. The Jazz Team Server provides representations of artifacts fromdifferent life cycle phases, and can be used by any of these developers to understandrelations between artifacts. This is the reason for restricting the answer to therepresentation of artifacts in the Jazz Team Server.

The most important part of having traceability is linking artifacts to each otherin some way and to be able to follow these links. The conclusions from the theoreticalstudy of traceability and analysis of the Jazz Team Server (section 5.3) specifiesthat links should be used to ensure traceability. The links must be navigable, toensure better traceability by being able to navigate to the actual linked artifacts.The conclusions also specifies properties of a SCA link (figure 8.2 below). Theproperties are motivated and discussed below.

Representation of relationship between artifacts

Generic artifactStatic code analysis

artifact

Link Information

Creation time

Update time

Version

Usage history

Status


TypeSource code module

Priority

Figure 8.2. Representation of SCA traceability link

Link Information

The link information describes properties of the link itself such as when it was cre-ated or updated. These are general properties that aid developers in understandingthe link. They are also useful when sorting links (see section 4.4). Sorting is use-ful for finding links relevant to the developer, and excluding links which are not.Creation time and update time are necessary to display the actualness of the link.Version displays the version of the link, and has a reference to the previous versionso users can see how the link has evolved. Usage history shows when this partic-ular link has been browsed by a user, showing how often it is used. Status stateswhether the link is active, deleted or obsolete. If the source code is updated, theSCA artifact is obsolete, and the link specifies this.

52

8.1. QUESTION DISCUSSION


These properties show information about the SCA artifact. Type refers to whattype of SCA artifact is linked e.g. “Coding Standard” or “Metrics”. It is betterto display this information directly in the link than having the user navigating thelink to find out what type of SCA artifact is connected to it. Source code moduledisplays what source code module this SCA artifact is derived from. Priority statesthe importance of this SCA artifact. This aids developers by letting them knowwhich SCA artifacts should be investigated first. This prioritization is dependenton the development project. Some projects need to focus on security aspects, whileothers focus on performance.

Q6 Is it possible to ensure traceability between defects and design?

The reason this question is relevant is because the design and implementation phasesare directly connected as a predecessor and successor (see section 1.2). In theimplementation, SCA artifacts are linked to a “Design” work item. The “Design”work item represents a design artifact such as a system design document. Thisrelationship is on a very high level, only stating that the system design documentis linked to a SCA report or picture.

This concludes that the implementation was able to ensure some traceabilitybetween defects and design. A more yielding relationship would be if a specificSCA output is linked to a specific part of the system design document e.g. aresource leak is linked directly to the change slot driver in figure 3.5. This was notpossible to implement because the Jazz Team Server does not offer possibilities tocreate links from within artifacts. A solution would be to create a work item thatonly includes information about the resource leak and specifies which part of thedesign document is affected by the leak. This has to be a manual process though,as the user has to open the design document, find where the affected part is, andsummarize this information in the work item.

Q7 What other traceability can static code analysis assist?

Section 8.1 describes how and which artifacts are affected by static code analysis.Since they are related, traceability should exist between static code analysis artifactsand the related artifacts. In the implementation, a “Test Case” is linked to an“Implement” work item which in turn is linked to some SCA artifacts. This providestraceability between the test case and static code analysis. This is also true for a“Requirement” which is affected in the same way.

The Jazz Team Server has a mechanism for link rendering (see section 5.2.4)that can be used to provide the properties described in figure 8.2. The returnedinformation from the target of the link is based on the representation of that artifact,and in the Jazz Team Server, this is an overview of the artifact as shown in the JazzTeam Server applications. This is discussed further in section 8.3.2.

53


8.2 Conclusions

8.2.1 Integrating SCA into a development process

This thesis has described some methods of how and where to integrate static codeanalysis into a development process. A discussion about what artifacts are relatedto static code analysis has also been provided. The affected artifacts are verycoarse grained, and the reason for this is discussed below in section 8.3.3. Theimplementation in this thesis was not able to integrate traceability between allthese artifacts and static code analysis artifacts in the Jazz Team Server. This isdiscussed below in section 8.3.1.

8.2.2 Traceability of SCA artifacts

Conclusions from the theoretical study specifies that links to static code analysisartifacts should include properties defined in figure 8.2. The Jazz Team Server pro-vides links with only one property; a name. These links are bi-directional, providinga little more traceability than simple links. The Jazz Team Server does provide afeature that can be used to improve links to static code analysis; link hovering (seesection 5.2.4). The implementation of this thesis was not able to implement the linkhovering in links to SCA artifacts because of limitations in the java libraries. Thisis discussed below in section 8.3.2.

8.3 Discussion

This section discusses the results, conclusions and lessons learned from this thesis.

8.3.1 Integrating SCA into a development process

Integrating static code analysis into a development process can be very rewarding.The discussion of the answers to questions Q1-Q4 in section 8.1 provide insight inhow static code analysis can be integrated into the development process. There areother ways to do this and one aspect that is of concern is when and how to usestatic code analysis on integrated components. Section 3.6 states that this shouldbe done during integration testing. One thing to consider is to utilize the propertiesof static code analysis fully, namely that SCA can be used before source code iseven delivered to testers. A work team which only focuses on finding SCA defectsin integrated components - even before integration testing - may be more profitablethan waiting for testers to do the analysis. This conclusion is based on the fact thatdefects are more expensive to correct the further they creep into the developmentprocess (see section 2.1). It is up to the development team to find out which methodworks best for them.

The implementation of this thesis was not able to create traceability betweenall SCA related artifacts (see section 3.6). This is mostly because of the lack of

54

8.3. DISCUSSION

functionality in the java libraries that were used. Another flaw in the method wasthat the Jazz Team Server does not support representation for all related artifacts.

8.3.2 Traceability of SCA artifactsNot many conclusions were possible to make through the methods of this thesis.The java libraries that were used in the implementation were not able to createany further traceability than what was already defined in the Jazz Team Server.The libraries provided functionality to operate in the CCM domain, which doesnot include artifacts from other domains such as test cases or requirements. Theonly possibility was to manually create links between domains (see section 6.2.1)through a web client. Links could then be copied between work items in the CCMdomain. This limited the use of the implementation to only operate in the CCMdomain, which denied access to manipulate resources from the requirements phaseand validation & verification phase.

The java libraries used in the implementation were not able to provide a modifi-cation of link rendering (see section 5.2.4). This thesis was not able to find a methodfor doing the modification, but a start would be to create a new representation ofstatic code analysis artifacts. The new representation would specify the propertiessmall preview and large preview (see section 5.2.4) as the link properties defined infigure 8.2.

8.3.3 Lessons learnedThis section discusses some lessons learned from this thesis. The problems thatwere discovered during this thesis are discussed, and for each problem, a possiblemethod of how to avoid this problem in the future is discussed.

• In the beginning of this thesis, the specifications of the problems to be solvedwere not defined. The factors that played part in what this thesis wouldinvestigate were that it should be a part of the iFEST project, it should inves-tigate the possibility of porting OpenGL to OSE (and hopefully implementit) and also incorporate static code analysis somehow. These are three differ-ent threads, which all were - more or less - woven together in this master’sthesis. This is not a good approach to defining a problem statement. Eachof the three factors can be investigated as an own master’s thesis, and this isreflected in this thesis. This is because the restrictions that has to be madeto each factor because of time constraints makes it very difficult to explainall factors while at the same time maintaining a concise report. This problemwould never have existed if the problem statement was defined before thisthesis began the investigation. This also applies to the broadness of the prob-lem statement. If the factors were fewer and more concise, then it would havebeen much easier to perform this thesis. The lesson learned is that too manyfactors which are not concise enough leads to many difficulties. To avoid this,a clear and defined problem must be stated before the thesis is begun.

55


• The integration architecture that was chosen did not provide the possibility toanalyse traceability between SCA artifacts and all related artifacts concludedin section 3.6. This created problems when trying to verify or analyse the con-clusions from the theoretical study with an implementation. Since artifactsderived in the conclusions were not represented in the Jazz Team Server, theycould not be analysed. This thesis chose IBM Jazz because it initially seemeda good candidate for investigating the questions asked. The choice was basedmostly on Jazz’s importance to the iFEST project, and the connection toOSLC which is an interesting architecture for integrating resources of the lifecycle. This problem could possibly have been avoided if several integrationarchitecture would have been compared before choosing the one to use in thisthesis. The comparison would be based on how well the integration architec-ture could be related to the development life cycle studied in the theoreticalstudy. This includes development life cycle phases and respective artifacts.

• The java libraries that were used in the implementation of this thesis didnot provide much to the analysis of traceability in the Jazz Team Server.They could not modify any properties of artifacts of relevance to traceability.The libraries only provided functionality to add or modify already existingproperties of the Jazz Team Server such as artifacts or links. While this pro-vided methods to integrate development engineering tools into the Jazz TeamServer, the traceability between artifacts could not be modified. The librarieswere chosen because of time constraints in the thesis, mostly because no othertools were found to integrate SCA artifacts and traceability to the Jazz TeamServer. This problem could have been avoided by having more time to inves-tigate the possibilities of the libraries before they were used. That creates anew problem though, which is finding another tool to modify traceability ofthe Jazz Team Server. A solution to that would be to use another integra-tion architecture in the thesis. The iFEST project is investigating a numberof different integration architectures. A better suited integration architec-ture could be found in the list of integration architectures investigated by theiFEST project.

• The artifacts related to static code analysis derived from the theoretical studyof development life cycle phases were very coarse grained. Development lifecycle phases include different activities and artifacts depending on the devel-opment process used. This thesis describes development life cycle phases asa general idea, which simplifies activities and artifacts. SCA artifacts weretherefore related to non-detailed related artifacts. While this does give someinsight in what artifacts are affected by static code analysis, a better insightwould be to understand in detail what artifacts are related. This problemwould have been avoided if a specific development life cycle model with specificartifacts would have been chosen instead of an overall picture of developmentlife cycles.

56

8.4. FUTURE WORK

• The original approach for the use case was to do all or part of porting OpenGLto OSE, but during the time of this thesis this was found to be too big of ause case. This caused problems with the time plan and the approach had tobe redesigned. This was discovered in the later stages of the thesis, meaningthere was not a lot of time to design the new approach. This is reflected inthe thesis in the sense that the use case did not provide very much to theconclusions of the thesis. The new approach was to describe the architectureof the source code package with the use of a static code analysis tool. Whilethis is an asset to ENEA, it did not provide any additional conclusions to thisthesis. The background, results and discussion of the use case have thereforebeen placed in appendix A.

8.4 Future Work• This thesis concludes that static code analysis should be integrated with the

compiler, but not exactly how this can be done. Since a compiler and a staticcode analysis tool are similar in the sense that they parse source code in orderto understand what it does, there are incentives for integrating them. Futurework would be to investigate how this can be done. S. Tucker Taft discussesand motivates how and why this can be achieved in [13].

• The functionalities of the implemented java client can be used as a basis formodifying development engineering tools to add or change artifacts in the JazzTeam Server. This would improve the efficiency of engineers since they canupdate the development project in the Jazz Team Server automatically in theirown tool environment instead of manually creating and linking artifacts in aweb client. This means that the engineers can work independently in their owndevelopment environment while at the same time contribute information aboutthe development project to other engineers. When they need informationabout the project, such as traceability relations, they can use the Jazz TeamServer to find the up-to-date information.

• The traceability links between artifacts in the Jazz Team Server do not includemuch information. Development engineers using the JTS would benefit fromhaving richer links to SCA artifacts. One method to implement this wouldbe to modify the link rendering property of the JTS described in section5.2.4. The last paragraph in section 8.3.2 describes a possible method to dothis. Unfortunately the tools used in this thesis were not able to perform themodification, and a concrete method was not found either. Future work wouldbe to investigate how to achieve this.

• This thesis focuses on the general picture of development life cycles, whichled to the artifacts listed in the answer to question 3 being coarse grained. Inorder to analyse more fine grained artifacts, a specific development life cycle

57


model has to be used. A list of specific software engineering processes can befound in [36]. By analysing these more fine grained artifacts, and determininghow they are affected by static code analysis, a better sense of traceability forengineers in the development life cycle would be present. This is because theengineers receive more details about the relationship between the artifacts,e.g. a SCA artifact is linked to a specific part of a detailed design instead ofthe whole detailed design document.

• The implementation of this thesis only modified artifacts in the CCM appli-cation because of constraints in the java libraries that were used. This meantthat the SCA artifacts could only be directly linked to work items. While thisprovided an indirect linkage (through the work item) between for instancea test case and a SCA metrics report, it is not an optimal solution. A testcase should be directly linked to the SCA metrics report to ensure as goodtraceability as possible, but to achieve this, another tool or method has to beused other than the java libraries used in this thesis. Future work would beto investigate how to modify artifacts from other applications, and not onlythe CCM application.

• Since the IBM Jazz project is not in a final state during the writing of thisreport, many new features and artifacts will be added to it. These have notbeen considered in this thesis, and could be part of future work. See section8.4.1 below.

8.4.1 The IBM Jazz ProjectThe IBM Jazz project was constantly delivering updates to the Jazz Team Serverduring the time of this thesis. There are many new features that are not included inthe thesis, and they could be investigated and integrated as future work. The JazzTeam Server only implements the domains Requirements Management, Change andConfiguration Management, Quality Management and Source Control Managementas of this thesis. This is not sufficient to provide artifact representations of all arti-facts related to static code analysis. The Architecture Management (AM) domainis defined in OSLC and is currently part of future integration to the Jazz TeamServer. The AM domain handles integrations related to models and other artifactsused during analysis, design and construction and will have related artifacts to staticcode analysis.

58

Bibliography

[1] iFEST, “industrial Framework for Embedded Systems Tools.” http://www.artemis-ifest.eu/.

[2] ARTEMIS, “ARTEMIS Joint Undertaking.” https://www.artemis-ju.eu/.

[3] industrial Framework for Embedded Systems Tools, “Full Project Proposal.”.

[4] B. Higgins, “Jazz Foundation REST Services, retrieved online 2010-10-22.”https://jazz.net/wiki/bin/view/Main/JazzRESTServicesMain, Septem-ber 2009.

[5] E. Kit and S. Finzi, Software testing in the real world: improving the process.ACM Press/Addison-Wesley Publishing Co. New York, NY, USA, 1995.

[6] P. Emanuelsson and U. Nilsson, “A comparative study of industrial static anal-ysis tools,” Electronic notes in theoretical computer science, vol. 217, pp. 5–21,2008.

[7] M. Ågren, Static code analysis for embedded systems. PhD thesis, 2009.

[8] J. Wilander, Security intrusions and intrusion prevention. PhD thesis, Mastersthesis, Linköpings universitet, http://www.ida.liu.se/~johwi/, 2002.

[9] W. Bush, J. Pincus, and D. Sielaff, “A static analyzer for finding dynamic pro-gramming errors,” Software: Practice and Experience, vol. 30, no. 7, pp. 775–802, 2000.

[10] J. Wilander and M. Kamkar, “A comparison of publicly available tools forstatic intrusion prevention,” 2002.

[11] E. Veenendaal, “Standard Glossary of Terms Used in Software Testing,” Inter-national Software Testing Qualifications Board, 2007.

[12] F. Gwyn, “Klocwork Truepath, generating accurate scalable whole programanalysis,”

[13] S. Tucker Taft, “Integrating static analysis with a compiler anddatabase, retrieved online 2010-12-22.” http://embedded-computing.com/integrating-static-analysis-a-compiler-database, February 2010.

59

http://www.artemis-ifest.eu/

http://www.artemis-ifest.eu/

https://www.artemis-ju.eu/

https://jazz.net/wiki/bin/view/Main/JazzRESTServicesMain

http://embedded-computing.com/integrating-static-analysis-a-compiler-database

http://embedded-computing.com/integrating-static-analysis-a-compiler-database

BIBLIOGRAPHY

[14] E. Euler, S. Jolly, and H. Curtis, “The failures of the mars climate orbiter andmars polar lander: A perspective from the people involved,” in Proceedings ofGuidance and Control 2001, pp. 01–074, 2001.

[15] G. Brat and R. Klemm, “Static analysis of the mars exploration rover flightsoftware,” Proceedings of the First International Space Mission Challenges forInformation Technology, pp. 321–326, 2003.

[16] CERT Coordination Center, “Cert/cc statistics 1995 - q3 2008, retrieved online2010-09-10.” http://www.cert.org/stats/, February 2009.

[17] T. McCabe, “A complexity measure,” IEEE Transactions on software Engi-neering, pp. 308–320, 1976.

[18] H. Bill, Making software measurement work. John Wiley & Sons, Inc., 1993.

[19] S. Roger and I. Darrel, Software engineering: a practitioner’s approach. Mc-Graw Hill, 1992.

[20] V. Ambriola and V. Gervasi, “Representing structural requirements in softwarearchitecture,” in Proc. of the Int. Conf. on Systems Implementation, Citeseer,2000.

[21] S. Greenspan, J. Mylopoulos, and A. Borgida, “Capturing more world knowl-edge in the requirements specification,” in Proceedings of the 6th internationalconference on Software engineering, p. 234, IEEE Computer Society Press,1982.

[22] G. Sunyé, F. Pennaneac‘h, W. Ho, A. Le Guennec, and J. Jézéquel, “UsingUML action semantics for executable modeling and beyond,” in Advanced In-formation Systems Engineering, pp. 433–447, Springer, 2001.

[23] M. Aoyama, “New age of software development: How component-based soft-ware engineering changes the way of software development,” in 1998 Interna-tional Workshop on CBSE, Citeseer.

[24] G. Spanoudakis and A. Zisman, “Software traceability: a roadmap,” Handbookof Software Engineering and Knowledge Engineering, 2005.

[25] O. Gotel and C. Finkelstein, “An analysis of the requirements traceabilityproblem,” in Requirements Engineering, 1994., Proceedings of the First Inter-national Conference on, pp. 94–101, IEEE, 2002.

[26] B. Ramesh and M. Jarke, “Toward reference models for requirements trace-ability,” IEEE Transactions on Software Engineering, vol. 27, no. 1, pp. 58–93,2001.

[27] M. Lindvall and K. Sandahl, “Practical implications of traceability,” Software:Practice and Experience, vol. 26, no. 10, pp. 1161–1180, 1996.

60

http://www.cert.org/stats/

[28] A. Egyed and P. Grunbacher, “Supporting software understanding with auto-mated requirements traceability,” International Journal of Software Engineer-ing and Knowledge Engineering, vol. 15, no. 5, pp. 783–810, 2005.

[29] A. Marcus, X. Xie, and D. Poshyvanyk, “When and how to visualize traceabilitylinks?,” in Proceedings of the 3rd international workshop on Traceability inemerging forms of software engineering, p. 61, ACM, 2005.

[30] “Open Services for Lifecycle Collaboration.” http://www.open-services.org/.

[31] IBM Rational, “Jazz community site.” http://jazz.net/.

[32] R. Fielding and R. Taylor, “Principled design of the modern Web architecture,”ACM Transactions on Internet Technology (TOIT), vol. 2, no. 2, pp. 115–150,2002.

[33] IBM Software, “Rational Software Analyzer.” www.ibm.com/software/awdtools/swanalyzer/.

[34] Scientific Toolworks, Inc., “Understand.” http://www.scitools.com/.

[35] Klocwork, “Klocwork Architect.” http://www.klocwork.com/products/insight/architect-code-visualization/.

[36] , “Software Engineering Process Technology (SEPT).” http://www.12207.com/.

[37] D. Blythe and A. Munshi, “OpenGL® ES Common/Common-Lite Profile Spec-ification,” Khronos Group Inc, version, vol. 1, no. 02, 2004.

http://www.open-services.org/

http://www.open-services.org/

http://jazz.net/

www.ibm.com/software/awdtools/swanalyzer/

www.ibm.com/software/awdtools/swanalyzer/

http://www.scitools.com/

http://www.klocwork.com/products/insight/architect-code-visualization/

http://www.klocwork.com/products/insight/architect-code-visualization/

http://www.12207.com/

http://www.12207.com/

Appendix A

Use Case

The use case is of interest to ENEA, but does not provide any conclusions to thequestions asked in this thesis. This appendix describes OpenGL, and illustrates theresults from analysing the architecture of the source code package. A discussion ofthe use case is provided in the last part of this appendix.

A.1 Background

A.1.1 OpenGL ES 1.1

OpenGL Embedded Systems 1.1 (from here on called OpenGL) is a software inter-face to graphics hardware, specifically designed for graphics hardware running onembedded and mobile devices. The interface consists of a set of procedures and func-tions that allow a programmer to specify the objects and operations involved in pro-ducing high-quality graphical images, specifically color images of three-dimensionalobjects[37]. A typical program that uses OpenGL begins with calls to open a win-dow into the framebuffer into which the program will draw. Then, calls are madeto allocate an OpenGL context and associate it with the window. These steps areperformed by using a companion API1, and are thus not executed by OpenGL. Thecompanion API used in this thesis is the Khronos Native Platform Graphics Inter-face (from here on called EGL). Once the context is allocated, the programmer isfree to issue OpenGL commands such as drawing or rendering geometric objects.

A.1.2 EGL

EGL is an interface between rendering APIs such as OpenGL and an underlyingnative platform window system. EGL provides mechanisms for creating drawablesurfaces onto which client APIs can draw and creating graphics contexts for clientAPIs. The rendering context stores information about the OpenGL state. Thedrawing surfaces are created with respect to a configuration called EGLConfig which

1Application Programming Interface

APPENDIX A. USE CASE

describes the depth of the color buffer components and the types, quantities andsizes of the ancillary buffer (i.e. the depth, multisample and stencil buffers). Thereare three types of drawing surfaces; pbuffers, pixmaps and windows. Windows areused for onscreen rendering while pbuffers and pixmaps are offscreen rendered.

Windows use a rendering model called back buffering. Memory for the colorbuffer used during rendering is allocated and owned by EGL. When the client isfinished drawing a frame, the back buffer may be copied to a visible window, makingthe frame visible.

EGL needs to obtain a physical display that will be connected to the renderingsurface and drawing context. This is done by querying available displays and ini-tializing them either by using the native windowing system or - in cases where nonative windowing system exists - by an own implementation.

A.1.3 Hardware

The platform used in this thesis is the Freescale i.MX31 ADS. It’s specifically de-signed for multimedia and graphics applications that require low power and highperformance. The i.MX31 board GPU’s uses a graphics accelerator MBX R-Swhich provides hardware acceleration for 2D and 3D graphics algorithms such asOpenGL’s.

A.1.4 OpenGL in Linux on the i.MX31

Imagination Technologies has provided source code for OpenGL support in Linux forthe i.MX31. This includes hardware-specific source code that is needed to operateOpenGL functions on the MBX R-S graphics accelerator.

A.2 Results

Critical modules

The following picture illustrates modules that were identified as critical.

Windowing

System

OpenGL EGL

EGL entrypoints

User Services

Kernel Services

System

PVR2D

Hardware

definitionsinclude

Include

internal

Include

external

Figure A.1. Critical modules

A.2. RESULTS

Relationships between critical modules

83

32

309 / 46

24

23 / 4

47

30

85 5 /

25

Windowing

System

OpenGL

EGL

EGL entrypoints

User Services

Kernel Services System

PVR2D

47

Figure A.2. Dependencies between critical modules

Figure A.2 above depicts the critical modules and their dependencies. The blacknumbers show the number of dependencies between one module to another. Therectangular arrowheads correspond to a bidirectional relationship where both mod-ules depend on each other. The encapsulated numbers were not found by Under-stand, and were added manually. They were not found because the relationshipincludes function pointers, which are hard to detect with static code analysis. Bymanually investigating the source code, the dependencies were found. Figure A.2above does not include some critical modules, as the picture would be very bloated.They are depicted in the pictures below instead.

Windowing

System

OpenGL

EGL

EGL entrypoints

User ServicesKernel Services

System PVR2D

Hardware

definitions6 18

420 78

207

1127

Figure A.3. Dependencies to hardware definitions


Windowing

SystemOpenGL

EGLEGL entrypoints


System PVR2D

include

71 420

501799 883

351

987

7

Figure A.4. Dependencies to include

Windowing

SystemOpenGL

EGLEGL entrypoints


System PVR2D

Include

internal

239 250

Figure A.5. Dependencies to include internal

Windowing

System

OpenGL

EGLEGL entrypoints


System PVR2D

Include

external64 138

581 241

76

85

2

Figure A.6. Dependencies to include external

Figures A.3-A.6 above depicts the dependencies between the four critical modulesHardware Definitions, Include, Include Internal, Include External and the othercritical modules.

A.3. DISCUSSION

Overview of the architecture

The dependencies to the modules in Includes & internal API were not includedin the overview of the architecture because the picture would be hard to under-stand. Figures A.3-A.6 illustrates the dependencies. Figure A.7 below illustratesthe architecture of the source code package.

Windowing

SystemOpenGL EGL

EGL entrypoints

User Services

Kernel ServicesS

yste

m

PVR2D

Hardware

definitions

Include

Include

internal

Include

external

MBX

driver

MBX

Services

Includes &

internal API

Other

Services

Services

MBX

hardware

Application

gl.h egl.h

User

Space

Kernel

Space

Hard-

ware

Applic-

ations

Figure A.7. Overview of the architecture

A.3 DiscussionThe source code package consists of 187 818 lines of code and 3140 functions, makingthe package very complex. To be able to describe the whole system, compromiseshad to be made, such as narrowing down the amount of modules to display in thefinal architecture figure. In reality, the package consists of more modules where eachmodule contains many internal modules as well. The internal modules were mainlydisregarded except in the modules User Services and Kernel Services. Even in thosemodules all services except one were bundled together in one internal module.


An interesting note of the architecture is that it is not very modular. Manymodules span across the user space and the kernel space. This is something toconsider when deciding to commence the porting to OSE.

improving software development with static code analysis ... › smash › get › diva2:412947 ›...

Documents