This report will discuss the area of software visualisation and comparison and will move on to the design and implementation of a tool that can perform such functions. It will discuss the usage of such a tool in real world applications. It will describe the much-used software engineering methodology called O.M.T., which was used as a guide to design the tool from the analysis phase through to the implementation phase. This report will also discuss the implementation language, Microsoft’ s Visual C++ Version 5, in the context of implementing the tool specification. Finally, this report contains the results and conclusions that relate to this project.

1.1 Project Goal 5

1.2 What is Software Visualisation and Comparison 5

1.3 Purpose of Software Visualisation and Comparison 9

1.4 For whom is this tool aimed for 9

1.5 Report Structure 10

2.1 Software Visualisation Background 12

2.1.1 Software Visualisation and Comparison 12

2.1.2 History of Software Visualisation 13

2.1.3 Different Types of Software Visualisation 14

2.1.3.1 Program Visualisation 15

2.1.3.2 Visualisation using Semantic Zooming, as used in large data sources16

2.1.3.3 Program Slicing 17

2.1.3.4 Algorithm Animation 17

2.1.3.5 Program Comparison 18

2.1.4 Does Software Visualisation really assist in understanding programs? - Empirical study results 18

2.1.5 The Principle Taxonomy of Software Visualisation and the Software Visualisation and Comparison Tool 20

2.2 Design and ImplementationLanguage Background 24

2.2.1 Object Orientation 24

2.2.1.1 Why use the Object-Oriented approach? 26

2.2.2 OMT - Object Modelling Technique 27

2.2.2.1 The 3 OMT Models 28

2.2.2.1.1 The Object Model 29

2.2.2.1.2 The Dynamic Model 30

2.2.2.1.3 The Functional Model 31

2.2.2.1.4 The Relationship between the 3 models 32

2.2.2.2 The 4 OMT Lifecycle phases 33

2.2.3 The Implementation Language - Microsoft Visual C++ 35

3.1 The Analysis Phase 37

3.1.1 The OMT Analysis: An Overview 37

3.1.2 The Analysis of the SVCT Application 39

3.1.2.1 The Problem Statement 39

3.1.2.2 The Requirements Table 41

3.1.2.3 Use-Case Analysis 44

3.1.2.4 The System Context Diagram 50

3.2 The System Design Phase 51

3.2.1 The OMT System Design Phase: An Overview 51

3.2.2 The System Design of the SVCT Application 51

3.2.2.1 Organisation of the system into subsystems 51

3.2.2.1.1 The Tokenizer Object 52

3.2.2.1.2 The Pixelised Display Object 53

3.2.2.1.3 The Comparison Object 54

3.2.2.2 Data Storage Approach 55

3.2.2.2.1 The Logfile Object 57

3.2.2.2.2 The FileInformationArray Object 58

3.2.2.3 Estimation Of Hardware and Software Requirements 59

3.2.2.4 Software Control Implemtation 60

3.2.2.5 Effects of these decisions on the system design thus far 60

3.2.2.5.1 The System Design Phase: Object Models 61

3.2.2.5.2 The System Design Phase: Dynamic Model 63

4.1 The Object Design Phase 66

4.1.1 The OMT Object Design Phase: An Overview 66

4.1.2 The Object Design of the SVCT Application 66

4.1.2.1 Initial Computer Domain Considerations 66

4.1.2.2 The Effects that Visual Programming had on the project design and implementation 68

4.1.2.2.1 The IDE 68

4.1.2.2.2 The MFC Document-Frame-View Architecture 68

4.1.2.2.3 Serialisation 71

4.1.2.2.4 Events and Message Maps 71

4.1.2.2.5 Visual Resources 71

4.1.2.3 Other modifications to the high-level object specification 72

4.1.2.4 Design Algorithms to Implement the operations 72

4.2 The Implementation Phase 74

4.2.1 The OMT implementation Phase: An Overview 74

4.2.2 The Implementation of the SVCT Application 74

4.2.2.1 Extensibility 75

4.2.2.2 Reusability 75

4.2.2.2.1 Sharin newly written code within the project 75

4.2.2.2.2 Use of previously written code 75

4.2.2.2.3 Use of code specially written to be reused 76

Appendix A - A Principle Taxonomy of Software Visualisation

Appendix B - Use Cases: Adopted by UML and OOSE but not by OMT1

Appendix C - Control Constructs and the assigned colours 93

1. Introduction

The goal of this project is to research, analyse, design and implement a software based tool which can visualise software code and can compare different files of code against each other to highlight similarities and differences. The student assumes that this tool will be able to visualise and compare C++ source code. There are 2 reasons for this. The first is that there are a huge amount of languages in the software programming world today. It is infeasible for such a tool to be created in s uch a short time window that could handle all of these languages. Secondly, of the multitude of languages available today, many are becoming obsolete. C++ has been chosen because it is a modern language, in both its object-oriented structure and in its us e by many software facilities today.

Note: An internet webpage has been set up in conjunction with this project to display the latest information on the project. The URL is as follows:

http://www.csn.ul.ie/~mrmen/fypmain.html

It is often very difficult to see the construction of a source code file by simply reading it. Likewise, when given 2 pieces of code to compare for similarities and differences, it can become a daunting task to accurately com pare the files. This is where a software visualisation and comparison tool comes in. By visualising a source code file, it can become significantly easier to quickly read through and identify all major components of it. Also, comparison can be performed a t the touch of a button by comparing the quantity and type of information in each source code file.

One may ask what is meant by such broad terms as Software Visualisation and Software Comparison. There are, in fact, several different forms of each. Software Visualisation can encompass anything from plotting records of the average num ber of sunspots per month, to displaying of a sound wave spectrum to the screen. Software Comparison can be defined as the use of computers to perform a similarity-checking process upon two or more entities, whether they are analytical results or simple f iles.

In the context of this project, the Software Visualisation process will be involved with the colouring of the code in a programming language source code file according to the usage of control constructs and tokens within the file . For example, if a user wishes to analyse a source code file with a "for" statement in it, then the Visualisation process would be able to identify where the "for" statement is and colour it with a predefined colour. The idea behind t his is that a user can open a source code file and be able to see what constructs are being used in the code and where they are being used. This can be further used to compare two different source code files. For example, if the user wishes to open two d ifferent source code files and see if they are similar, or even copied, the coloured control constructs and tokens would make it easier for the user to identify what is similar and what is not. See Figure 1.1 for a visual example of this.

Figure 1.1: Example of Source Code Visualisation

One problem that may be encountered when visualising a source code file is that, if it is a big file, not all of the file can be viewed at once, unless a massive screen resolution is available. At the present day , there are no screen resolutions commercially available to the ordinary user that could perform such a function. A viable alternative to this is to ‘shrink’ down the coloured source code until only the corresponding coloured lines can be seen and the tex t cannot be read any more. By this means, it becomes possible to see the control constructs of the code in a much more miniature form. The ideal magnitude of shrinkage is a height of one pixel per normal text line. By condensing down the code to have a ‘o ne pixel line per code line’ representation, it is possible, in theory, to display over 1 million lines of code at a screen resolution of 1280 * 1024 as this provides for 1,310, 720 pixels [13]. Figure 1.2 shows how the code as shown in Figure 1.1 may be reduced to a tiny area.

Figure 1.2: Reducing the Source Code down to pixelised form.

In the context of this project, Software Comparison means testing two or more source code files for boundary condition similarities. This means that all constructs with boundary coefficients are compared against corresponding con structs in other source code files, and the user is notified of the results. From this, the percentage similarity between source code files is calculated, which is a measure of the success rate of the comparison tests.

3. Purpose of Software Visualisation and Comparison

Why do we have the need for software visualisation and comparison tools? There are many reasons for this

• Programming tutor aid.
• Program Debugging
• Tracing program execution
• Algorithm Analysis
• Semantic Difference Analysis
• Algorithm Animation
• Program Slicing
• Massage-Pattern Visualisation

These are expanded upon in Chapter 2: Background

Primarily, the Software Visualisation and Comparison Tool that is laid out in this report is aimed for college lecturers and software debuggers in industry. Different student assignments from lecturers can be compared by the lecturer to see if there has been any copying of code amongst the students, as is sometimes the case with new college programmers. An often misleading perception amongst this group is that if a student copies another students source code and just changes the names of the variables and functions, the copying will not be noticed by the lecturer. But the very nature of this tool is to ignore the variable and function names allocated by the student and analyse the construction of the source code instead. It i s very unlikely that two students will write the same code for a given task in all but the smallest and most trivial of assignments. The code visualisation and comparison will ensure that variable and function name changing will prove to be useless. The l ecturer will be able to locate the copying immediately from the identical code construction and action can be taken against the student involved.

Chapter 2 discusses the background theory that is involved with the SVCT project. Chapters 3 and 4 discuss the analysis, design and implementation of the SVCT. Chapters 5 and 6 discuss the results and conclusions about the to ol development and chapters 7, 8 and 9 feature the acknowledgements, references and appendix for the project.

Chapter 2 reviews the background theory to the project and is supplied in three sections. The first section deals with the Software Visualisation area as it appears in its different forms. The second section refers to the design process used in the development of the tool, namely OMT, and the third section presents a discussion on the implementation language, Microsoft Visual C++ 5.

Chapter 3 reviews the analysis and design process that was involved in developing the tool. The OMT Analysis and System Design lifecycle phases are documented along with the some of the actual analysis and design performed whilst developing the tool.

Chapter 4 reviews the OMT Object Design and Implementation phases for the tool development.

Chapter 5 presents the results that have been obtained in the project implementation and the current project status at time of going to print.

Chapter 6 presents a number of conclusions about the project development, the mechanism’s involved in developing the project, the implementation language and aout the Software Visualisation area.

Chapter 7 acknowledges those who have helped with their invaluable input into the project.

Chapter 8 contains a comprehensive list of books, papers and websites that have been successfully searched for information and added to this project.

Chapter 9 contains an Appendix

1. Background

Software Visualisation can be defined as the use of graphical and textual formalisms to describe the execution of computer programs [8]. It is the use of visualisation and animation techniques to help people understand the ch aracteristics of programs [9]. Software visualisation tools use graphical techniques to make software visible through the display of programs, program artefacts, and program behaviour. The essential idea is that visual representations can make the process of understanding software easier [23].

Software visualisation is the use of computer graphics and animation to help illustrate and present computer programs, processes, and algorithms. [14]. [8] stated that it the use of graphical and textual formalisms to describe th e execution of computer programs. [9] defined it as the use of visualisation and animation techniques to help people understand the characteristics of programs. Software comparison can be said to be inherent when tw o or more entities are visualised.

Software visualisation tools use graphical techniques to make software visible through the display of programs, program artefacts, and program behaviour. The essential idea is that visual representations can make the process of understa nding software easier [23]. When designing visualisation tools, [19] noted that visualisations must be able convey the required information precisely and reliably without the use of formal notation, if they are to be easily understood.

Software Visualisation tools can be useful when using modern software development methods. Program visualisation (a form of software visualisation, see chapter 2.1.3.1) has an important role to play when performing requirements validati on, rapid prototyping, training, monitoring and testing.

Where did the idea of software visualisation come from?

Research into the Software Visualisation area began back in 1947, when the power of using visual representations to aid the understanding of computer programs was first realised. In 1947, Goldstein and von Neumann demonstrate d to the world the use of flowcharts to represent flows in software systems, and in 1959, Haibt developed a system that could automatically produce flowcharts from Assembler and Fortran programs. During the 1960’s, the emphasis shifted away from the v isualisation of code using flow charts to using dynamic visualisation techniques to address the visualisation of data structures. This approach was pioneered by Knowlton of Bell Labs [24], who showed this approach using list manipulation of their own lang uage. Baecker's (1968) debugger for the TX-2 computer produced static images of the display file, but it was live and interactive.

During the 1970’s, flowcharting made a comeback with Nassi-Shneiderman diagrams. These flowcharts were produced to counteract the then current ideas of flowcharting, which had an unstructured nature. Roy and St. Denis (1976) then de veloped a system for automatically generating Nassi-Shneiderman diagrams from source code through a specialised compilation process. The second half of the seventies saw a new form of software visualisation called ‘pretty-printing’. This term was posed by Ledgard (1975), to describe the use of spacing, indentation and layout to make source code easier to read in a structured language. The latest system that supports ‘pretty-printing’ to be released was produced by Hueras & Ledgard's in 1977. A more re cent extension from this idea is computerised typesetting, which provides for better code presentation.

During the 1980’s, modern SV research began with the introduction of the bit-mapped display and window interface technology. In 1988 for example, a tool was introduced called the Balsa-II, which allowed students to interact with hig h level dynamic visualisations of Pascal programs. [14]

The 1990’s have seen a continuation of ever more detailed visualisations of different entities, including parallel program visualisation [11] and 3-D Computational Visualisations [12]

When designing an SV system, it is important to note the system's intended goals and select the content accordingly. For example, systems designed for classroom teaching might intentionally show algorithm-level displays and avoid program-level displays in order to keep the students' minds distracted from implementation details. Systems designed for expert or even novice interactive use might require the ability to move smoothly between algorithm-level and program-level displays d epending on their need [14].

There are many different types of Visualisation systems available to the analyst and programmer today. The following is just a brief review of just some of the methods that are employed by such systems.

Program Visualisation has been defined by several authors, but the general consensus is that it is the use of various techniques to enhance the human understanding of computer programs, while visual programming is the use of "vis ual" techniques to specify a program in the first place [14]. The program is specified in the conventional, textual manner, and the graphics are used to illustrate some aspects of the program, or its runtime execution [20].

Program Visualisation can be broken down into 2 subsets, i.e. code and data visualisation [14]. These illustrate visualisation of the textual program code that the programmer has entered. This kind of visualisation is useful for large s oftware project analysis.

Three basic methods that are used when visualising programs are listed as follows

1) Software Structure

2) Run-time behaviour

3) The Source Code

Colouring the code has become a widely used form of code visualisation.

The Software Visualisation and Comparison Tool under development in this project uses the Program Visualisation technique to visualise source code by colour-coding it according to the syntactical constructs contained within it.

In software visualisation, illustrating the operation of very large program or programs working on very large data sets has remained one of the key open problems. [18] describes an approach called Semantic Zooming, which uses abstra ct, clustered graphics to portray program operations on the entire data set. This allows the user to zoom in and examine details. At the magnified level, the interface adjusts to reflect displays common in existing algorithm animation and program visualis ation systems. SeeSoft, a program developed by Eick, Steffen, Joseph and Sumner, provides a columnar representation of source files in which one line of pixels on a display corresponds to one line of source code. By using different colour mappings, the system presents a number of software engineering metrics about the code. This is discussed in [17].

The Software Visualisation and Comparison Tool under development in this project makes use of a technique similar to that as described above, i.e. ‘zoom in’ to the source code and provide a pixelised representative view of it. Note that the colour-codes assigned to the sourcecode, as described in chapters 1.2 and 2.1.3.1, are used in the pixelised representative view also.

Program Slicing is an automatic technique for determining which code in a program is relevant to a particular computation [15]. Program slicing is useful in program debugging, software maintenance and program understanding. Progr am slices can be used to reduce the effort in examining software by allowing a software analyst to focus attention on one computation at a time [25].

[15] has produced a software visualisation tool with an interface that allows slicing at the statement, procedure or file level. It provides fast visual feedback on slice structure. This operates on the basis that statements that take p art in a slice (i.e. statements that have an effect on the computation in question) are coloured, and statements outside the slice are not.

The overall effect of slicing is that it reduces the overall amount of code that the code analyst has to read in order to investigate which functions and statements have a direct effect on a computation.

Algorithm visualisation (or animation) is understood to be the visualisation of a high-level description of a piece of software [14]. The difference behind this and code visualisation is that, unlike code visualisation, algorithm animation ignores the actual presentation of the code and deals with the code in a much higher abstraction [20]. The idea behind algorithm animation is that it graphically displays an algorithm and the variables that interact with it. It allows the user to iteratively walk through the algorithm, updating the variable values. This is an example of dynamic visualisation. For example, this can be used to teach constructs from simple for loops to complex sort and search algorithms. See chapter 2.1.4 for info rmation on the use of an Algorithm Analysis Tool as an instructional aid.

Program Comparison means that two or more programs are observed with a view to seeing similarities between them. An example usage of this can be found on the Unix Operating system. In this environment, diff is a standard tool for comparing two files. Three versions are available. There are versions of diff that perform three way comparison of files (diff3), side-by-side comparison (sdiff), and graphical interfaces for showing the diff output (gdiff). [Ball, Eick].

Another graphical utility that is used to find the differences is the SeeDiff utility developed by the Visualisation Group at the Software Production Research Department, Bell-Labs [24]. It is capable of viewing two text files (includin g source code files) and colouring them according to similarities and differences found between them.

Software visualisation systems can be used in teaching to help students understand how algorithms work, and they can be used in program development as a way to help programmers understand their code better [14]. As discussed in c hapter 2.1.3.2, pixelised representational views are just pictures of the source code. Pictures are more concrete than text. They have some attributes that text doesn’t feature. These include

• a graphical means for expressing relationships (by their very nature)
• animation of graphics to further enhance relationship understanding.

[20] speaks of different experiments in which normal code text was tested against visualised code and flowcharts for understandability. Unfortunately, his tests proved inconclusive overall. But he put this down to the difficulty in obta ining equal test groups and tests.

[16] performed another experiment to investigate the benefits of a Software Visualisation Algorithm Analysis Tool, called XTango. This tool was tested on two groups of students. One group of students received a handout and was taught th e Shellsort algorithm using the tool and another group were also given a handout and listened to a lecture featuring drawings on a blackboard. Later the students were tested on their understanding of the ShellSort algorithm and their impressions of the an imation system. Results obtained from student feedback concluded that it was clear that the XTango algorithm analysis tool was a great help in aiding comprehension of the algorithm. The group of students that had used the Software Visualisation Algorithm animation system had a better understanding of the sort than those who had attended the lecture.

Given these results, why is Software Visualisation technology not being used and why are the new visual systems not being widely adopted? One likely answer is that software engineers (and their employers) have not seen demonstrable gains in using this technology. It is clear that if software visualisation systems are to make a contribution to software engineering, then solid results proving their benefits will be necessary [14].

When initially determining a general background understanding of a system, it is necessary to take account of the potential characteristics of that system. [14] considers a Principle Taxonomy of Software Visualisation. A Software Visualisation taxonomy is a method of describing the collection of potential characteristics of program visualisation systems [20]. The taxonomy mentioned here analyses 34 properties of Software Visualisation systems. The characteristics have been organi sed into hierarchical branches of 6 broad categories. See Appendix A – The Principle Taxonomy of Software Visualisation for a complete list of the potential Software Visualisation characteristics determined by Price, Baeker and Small.

Over the following paragraphs, the student will discuss only the most relevant aspects defined by the software visualisation taxonomy in relation to the Software Visualisation and Comparison Tool being developed. This process produces a pseudo-specification for the project tool.

SVCT: The SVCT system will be able to handle C++ files, H (header) files

and Bitmap Files. It will not be able to handle any other types of file.

SVCT: Program Visualisation

SVCT: Code Visualisation

SVCT: The primary target medium is a graphical workstation of a Microsoft

Windows variety. Either Windows 95, 98 or NT will suffice.

SVCT: Coloured textual lines and corresponding coloured pixelised lines.

Animation and sound will not be considered.

SVCT: The user will use buttons and drop-down menus.

Taxonomy: For what purpose is the system suited?

To implement the Software Visualisation and Comparison Tool, a design strategy and implementation language had to be chosen. The student felt that the tool would be best implemented using an Object-Oriented technique, such as O.M.T, and an O bject Oriented language that was capable of producing an effective front-end GUI, such as Microsoft Visual C++.

Object-Oriented programming is a data-centred view of programming, in which data and behaviour are strongly linked. Data and behaviour are conceived of as classes whose instances are known as objects [1]. The 4 major aspects of the Object-Orient ed approach are as follows: [22]

• Identity

• Objects are distinguishable entities

• Classification

• Objects with the same attributes / behaviour are grouped into a class
• An object is referred to as an instance of a class
• Behaviour is accessed using operations
• An operation is an action or transformation that an object performs
• A method is a specific implementation of an operation in a given class

• Polymorphism

• Same operation has different behaviour in different classes
• An operation is polymorphic if there is more than one method implementing it.
• Object-Oriented programming languages support polymorphism by selecting the method according to the class of the object.

• Inheritance

• Uses a hierarchical relationship to share attributes and operations among classes.
• Superclesses can be refined into subclasses
• A subclass inherits all the properties of its superclass and then adds its own properties.

The other major concept involved in Object-Oriented programming is Encapsulation (Information Hiding). This means that aspects of objects are separated into internal and external aspects. (Note: C++ supports this through means of public and private att ributes and method separation.) The purpose of encapsulation is to protect private data from being directly accessed by methods alien to the class in which they are defined. The advantage being, that if only methods of the native class to the data can acc ess the data, then it is easier to trace which methods could be causing bugs during debugging.

1. Why use the Object-Oriented approach?

There are 2 reasons for the student to use this approach:

The OO approach provides for many advantages over the more traditional, functional style of programming. The advantages are:

• Modularity and easier maintenance.

• Easier task allocation

• Intuitive Specification

The majority of the software industry now sees Object Orientation as being the way forward in terms of software development. This is due to its successful introduction in the early 1990’s into large software projects of many multi-national software / software related companies. One such example is the use of the OO specifying technique O.M.T into the Design Department at Tellabs, Shannon, Co. Clare. Currently, this company is developing A.T.M. (Asynchronous Transfer Mode) Network Systems using OO m ethodologies and tools. Gaining experience in this area may prove beneficial for the student in future software development projects.

1. O.M.T. – Object Modelling Technique

A Software Engineering Methodology is a process for the organised production of software, using a collection of predefined techniques and notational conventions {22]

The Object Modelling Technique is such an Object-Oriented software engineering methodology, which incorporates system analysis and modelling before system implementation. It is an approach to software development based on modelling obje cts from the real world and then using the model to build a language-independent design organised around those objects [5]. The OMT extends from the analysis of the problem through design to implementation, the main focus being on analysis and design. The major advantage to this approach is that design flaws are discovered at design time, and not during implementation time, where they can be costly in time (and money in industry) to repair. It forced the student to focus a lot more closely on the applicat ion domain rather than on implementing the code straight away for the project. Performing such an action would have proved to be less productive as the project continued, as it would have been probable that the student would not have clearly identified an d understood the requirements for the project and would have had less of a chance of clearly identifying the modular classes as effectively as would otherwise be.

The OMT is a methodology for OO development and a graphical notation for representing OO concepts [5]. The OMT defines three different types of models and four different phases of the project lifecycle.

1. The 3 O.M.T. Models

A model is an abstraction of something that is created to aid understanding, to reduce complexity and to test a physical entity before building it. [22] The main issues when modelling are that the important aspects of the project are modelled , and that the important requirements are the deciders as to what is and what is not important. The three models can be summarised into Table 2.2.2.1

MODEL	REPRESENTS	ASPECTS
Object	static, structured	data
Dynamic	temporal, behavioural	control
Functional	transformational	function

Table 2.2.2.1 – The 3 O.M.T Models

 

1. The Object Model

The object model describes the static structure of the system and is based on modelling the system data. It graphically shows the entities that exist within the system and the relationships that can exist between the entities. It also shows the attributes and operations that exist within each entity. The object models are the framework into which other model are placed [22] Objects models naturally fit into the software lifecycle because they promote understanding of the real wor ld and provide a practical basis for implementation in an OO computer language. Objects are just instances of classes and are can be identified as nouns in problem statements.

Relationships between objects are known as links or Associations. These can be inherently bi-directional and can be identified as verbs in problem statements. Aggregation is a tightly coupled form of association with extra semantics . Typically, it is used when representing sub-component objects from a main object. An example of this is ‘A line is part of a bitmap’. In the object model diagram, a white diamond represents aggregation.

In O.M.T, inheritance is known as Generalisation. Generalisation is the relationship between a class and one or more refined versions of it, i.e. the relationship between a superclass and a subclass. A subclass is allowed to use (or inherits) the functions of a superclass and can also add its own functionality to those operations within itself. Generalisation has the following features Generalisation is a useful vehicle of reusing code during implementation time. It simplifies conce pts by reducing the number of independent features in a system by avoiding unnecessary duplication of code wherever possible. A subclass may achieve this by overriding a function in a superclass by defining a function in the subclass with the same name [5 ]. An example of generalisation is ‘A C++ file is a Computer file’.

2. The Dynamic Model

The dynamic model describes the temporal or behavioural aspects of the system. This model captures control, that aspect of the system that describes the sequences of operations that occur, without regard for what the operations d o, what they operate on, or how they are implemented. The dynamic model deals with causally related events (i.e. event that have an effect on each other), and can also be applied to represent synchronous concurrent events (i.e. events that have no direct effect on each other). Graphically, it is a collection of event traces and state diagrams that interact with each other via shared events [5].

An Event is a unique one-way transmission of information that occurs at a point in time. A Scenario is just a sequence of events and an Event Trace is a diagram that simply shows a scenario at work between two or more objects.

A State Diagram relates the events and states of the system, where a state can be defined to be ‘an abstraction of attribute values and links of an object, which represents the response of an object to inputs. A state has duration and i s sometimes associated with a continuous operation (called an Activity) or an operation that occurs instantaneously (called an Action)’ [5].

State diagrams can refer to the other two models of the system. Actions on state diagrams refer to actions in the functional model (see 2.2.2.1.3 The Functional Model) and events become operations on objects in the object model. Also, U se Cases (see chapter 3.1.1) can often be thought of as an Analysis Phase (see 2.2.2.2) forerunner of the system dynamic model, due to the similarities in working with scenarios [7].

The dynamic model is particularly suited towards the design of the user-interface, because the GUI is the main area of control offered to the user.

3. The Functional Model

This third and final model represents the transformational aspects of the system, including functions, mappings, constraints and functional dependencies [22]. In simple language, it captures what the system does (and not how or when it do es the operations). This model stems from the traditional style of programming and tends towards using data flows and processes. DFD’s are normally used to form the basis for the code structure inside the methods. Graphically, the functional model is desc ribed using Data Flow Diagrams (DFD’s). A DFD is a graph that represents the flow of data values from their sources in objects to their destinations in other objects. [22].

Data Flow Diagrams are comprised of the following four features:

1. Processes

These have inputs and outputs and is used to transform data values

2. Data Flows

These represent the actual values.

3. Actors

These are the active objects that drive the data flow diagram. An example of such is a Graphical User Interface.

4. Data Store

are accessed to do something) within a DFD which store data for later access. This model is the least used of the three models as it reflects traditional programming practices and not a data-oriented or object-oriented approach.

1. The Relationship between the three models.

The 3 O.M.T. models described above show 3 complete orthogonal views of a system covering the structure, behaviour and data flows that can occur inside a system. So, what is the rel ationship between the 3 views? The answer lies in Figure 2.2.2.1.4

Figure 2.2.2.1.4 – The Relationship amongst the 3 OMT models.

There are many differing software methodologies in use in industry today. One such methodology is OOSE (Object Oriented Software Engineering), devised by Ivar Jacobson in 1992. [6]. This methodology is centred on the application of Use-Cases (see chapter 3.1.1).This methodology consists of three phases in the lifecycle, i.e. Analysis, Construction and Testing.

The lifecycle of OOSE consists of gathering the requirements of the system and analysing them. At this phase, use cases are employed to help develop models that give a greater understanding of the system. They define the way that the sy stem will function. These models focus on the end-application rather than on how the system will be implemented. At the construction phase, the models are further developed and the full system is designed and implemented. The testing phase integrates the full system together and verifies that the correct system has been constructed. When integrating the system, use cases are integrated into the system one at a time.

In contrast, the OMT methodology, used in this project, consists of 4 phases, as can be viewed in Figure 2.2.2.2

Figure 2.2.2.2 – The O.M.T. Lifecycle

Briefly, the four phases can be summarised as follows:

• Analysis

• System Design

• Object Design

• Implementation

This cycle is an iterative cycle, which means that the cycle once completed is run over again, with improvements and error corrections taking place on each iteration.

Note: these topics will be discussed in much more depth with the accompanying designs in Chapter 3 and Chapter 4.

There are many different languages and operating systems currently available in industry today that are flexible, versatile, documented and relatively inexpensive. Therefore, there was a large choice of languages from which the student could cho ose from to implement the Software Visualisation and Comparison Tool.

Firstly, a platform had to be chosen. The student chose to implement on the Microsoft Windows platforms, i.e. Windows 95, Windows 98 and Windows NT. The reason for this was that though the student has had some experience with a viable alternatives (i.e . Linux), it was felt that choosing this operating system could have made the project larger than was necessary, given the allocated project timescale.

Next, the student had to pick a suitable language for the project implementation. The language that was chosen was Microsoft’s Visual C++ Version 5. So, what are the reasons behind this choice of language?

2. The language compiler creates executables that are much faster than its easy Visual Programming cousin, Visual BASIC. With plenty of lower specification machines still in use around offices and R&D centres, it was deemed essential that the program execute as fast as possible. Given that program visualisation processing could involve thousands, possibly hundreds of thousands of lines of code and more, it was felt that waiting around for the tool to process the source code file would be undesirable.
3. Visual C++ provides access to building visual documen-centric (i.e. document centred) GUI’s by providing wrapper classes in the form of a library (called MFC, Microsoft Foundation Classes) to the Windows API. This was deemed especially useful for draw ing representative pixelised views of the coloured code (i.e. a bitmap, in the case of this project). In theory, this makes the calls to the operating system easier to use, as there are thousands of Window API calls in existence, and they are widely known to be extremely difficult to master.
4. Visual C++ is an industry standard which is used to program many (if not the majority) of Windows visual-interface applications. Gaining experience with such a language could prove useful for the student in future projects in industry.

It must be noted that JAVA is an extremely viable alternative language that can be used for GUI programming. Unfortunately, true JAVA is not available for the Windows PC, and it was felt that the effort of learning a completely new language (from the s tudent’s point of view) such as Microsoft’s operating-system-specific language, Visual J++ would not be worth the effort.

Unfortunately, Visual C++ has its drawbacks and they can be listed as follows:

1. It is specific to only Microsoft’s Windows operating systems.
2. It imposes a predefined structure to any SDI (Single Document Interface) or MDI (Multi-Document Interface) project created.
3. It is a programming language that has a steep learning, one that this student had to climb. It introduces topics like Serialisation, Runtime classes and Menu system message mapping programming to the student C++ programmer.

3. SVCT Design

This chapter will report on the design process used by the student and the SVCT designs themselves produced at each stage. The design process consists of the Analysis Phase, the System Design Phase and the Object Design Phase.

1. The Analysis Phase
1. The OMT Analysis: An Overview

1. The goal of the first stage of the analysis is the Problem Statement. This states the basic goals of the project in simple English terms that are easily understandable. It is built up through interaction between the analyst/ programmer and the end-user. It is the first stepping stone to defining a good system, as it sets a basis for the Requirement Table to be built from.
2. The Requirements Table sets out in a bit more detail, the end-user features of the application. This divides the requirements into their own individual block. Each has a number, a priority and is assigned either a hardware or softwa re context.
3. The goal of the third stage is to produce Use-Cases for each of the requirements. Error conditions and expected exceptions are taken into account at this stage. These types of errors are more prevalent in systems that depend heavily on user and file input. Note: The application of Use-Cases to requirements analysis stage was not included in the original definition of OMT as defined by Dr. James Rumbaugh in 1991 [5]. A revision of OMT occurred in 1994 that led to the addition of use cases to the formal methodology [10].

Use-Cases can be defined to be the way in which multiple related scenarios can be enacted, and are taken from the end-users point of view (i.e. no computer-domain references are made at this stage). They investigate and act out t he goals to which a system must conform. They are an essential tool used to capture the interaction scenarios between the user and the system under development. A Scenario depicts sequences of incidents that occur which cause an object to change st ate, for example, an object exchanging information with another object. Actors carry out use cases. Examples of actors may be the end user, a database administrator, a computer operator, another computer system application, or another entity needi ng to exchange information with the system [2]. A single actor may perform many use cases, and conversely, a use case may have several actors performing on it [3].

Use-case analysis may seem trivial but are a very important aspect of the analysis phase, as they can help to detect analysis errors early on in the project lifecycle, and not at the design or implementation phases. Analysis errors occu r when either a user requirement is missing, a user requirement is misunderstood or an unnecessary requirement is included. The cost of discovering analysis errors through out the different phases of a project lifecycle is in Figure 3.1.1



Figure 3.1.1 - Cost of Fixing Analysis Errors at different stages of a project lifecycle

4. The goal of the final stage of the analysis is to produce a System Context Diagram, which comprises of the main entities derived from the first three stages of the Analysis Phase. Constructing prototypes at the end of the Analysis phase is enco uraged so that the analyst can see how the analysis is moving towards the final application. The System Context Diagram and prototype form the basis on which the System Design can be developed.

1. The Analysis of the SVCT Application
1. The Problem Statement

The task is to implement a tool that performs visualisation of source code files and comparison of 2 or more of source code files. This tool shall compare / highlight similar control constructs and keywords.

Source code shall be visualised in the following manner.

The tool shall display source code on the screen in a normal source code editor-type manner, in a multi-coloured textual manner, and in a multi-coloured pixelised manner. For the multi-coloured textual manner, the colours are representa tive of the different control constructs and keywords that can be found in the source code file. The representation will effectively be a profile of the constructs and loops. The tool must also be able to produce the multi-coloured pixelised representatio n of the source code on demand. This representation will be a size-reduced representation, which will consist of lines of pixels instead of lines of text. Each line of pixels will represent a line of text and will be allocated a colour according to the co lour of the corresponding line of text. In this way, hundreds of lines of code can be represented on a small single image. The user will have the option to zoom into and to zoom out from the pixelised representation. The user shall also be provided with a facility that allows the user to see a legend that will inform the user of what the colour assignments are.

It shall compare two or more source code files in the following manner.

The user selects two or more files to compare. The two or more multi-coloured text files and the two or more multi-coloured pixelised files appear side by side, and then the tool produces a report on the screen to the user with info rmation related to the similarities found between the source code files. This information will classify similarities as identical loop boundaries occurring in the same types of loops in different source code files. Whilst calculating and counting the numb er of similarities, it will also count up the number of differences, and will produce a percentage similarity at the end of the report.

2. The Requirements Table

Req. No. - Requirement Number

P. A. N - Priority Assignment Number (1 is the highest, 3 is the lowest

A. D. - Allocation Domain (= s/w or h/w)

 

REQ. No.	REQUIREMENT	P.A.N	A.D
1	Allow the user to have multiple files and multiple types of files open at once.	1	s/w
2	Allow the user to save and print all types of files that can be opened by the user..	1	s/w
3	Allow the user to set-up the printer.	1	s/w
4	If a user is saving a file to a filename that already exists, prompt the user to overwrite the file, ignore the file or cancel saving the file.	1	s/w
5	Allow the user to view a list of previously opened files in the File drop-down menu.	3	s/w
6	Allow the user to maximise, resize, minimise and close all windows owned by the tool.	1	s/w
7	Allow the user to show and hide the tool bar and the status bar from a drop-down menu.	3	s/w
8	Allow the user to have the full functionality of a typical ‘Window’ drop-down menu.	2	s/w
9	Allow the user to view an About Box	3	s/w
10	Allow the user to view the current system time and date on the status bar.	3	s/w
11	Allow the user to use buttons to open and close a file, cut, copy and paste information, print the current file, open the about box and open the help file	2	s/w
12	Allow the user to start the tool from double clicking on the tool icon in windows explorer.	1	s/w
13	Register all file types that the tool uses with the Windows registry.	2	s/w
14	Allow for the use of scroll bars (vertical and horizontal) for all windows owned by the tool.	1	s/w
15	Allow the user to use a help file for the tool.	2	s/w
16	Show the user a splash screen every time the user starts up the tool. Ensure that vital information about the tool is displayed on the splash screen.	3	s/w
17	Allow the user to click on the splash screen to close it down without having to wait for it to close.	2	s/w
18	Create a set-up utility for the tool.	1	s/w
19	Allow the user to display the code file in a multi-coloured textual form with a ‘Display File’ command	1	s/w
20	Allow the user to display code file in a code editor-type form with a ‘Display File’ command	1	s/w
21	Allow the user the option to perform either Requirement 1 or 2 when a code file is selected to be opened.	1	s/w
22	Allow the user to open a corresponding pixelised file for any code file by right-clicking on the code file.	1	s/w
23	Allow the user to select a line on the pixelised file and for the tool to show the corresponding code file at the same line	2	s/w
24	Display a progress box when processing the ‘Display File’ command, to inform the user how much of the source code file has been processed.	3	s/w
25	Allow the user the option to cancel the called ‘Display File’ operation before it has finished	3	s/w
26	Display a progress box when processing the ‘Display Pixelised File’ command, to inform the user how much of the pixelisation function has been processed.	3	s/w
27	Allow the user the option to cancel the called ‘Display Pixelised File’ operation before it has finished	3	s/w
28	Allow the User to zoom in and out of the Pixelised File	2	s/w
29	Allow the user to view the current co-ordinates of the mouse pointer when it is over a pixelised file.	2	s/w
29	Allow the user to zoom in and out of the Pixelsied File	2	s/w
30	Allow the user to open previously saved pixelised representation files and Comparison Report Files.	1	s/w
31	Allow the user to compare two or more files.	1	s/w
32	When comparing two or more files, display the all of selected file for comparison side by side.	2	s/w
33	Allow the user to view a legend with the corresponding construct mappings.	1	s/w
34	When comparing two or more files, allow the user to view a tool-generated Comparison Report File.	1	s/w
35	Display a progress box when processing the ‘Display Comparison Report’ command, to inform the user how much of the command results has been processed.	3	s/w
36	In the Comparison Report, display the similarities and the percentage similarities between files.	1	s/w

 

3. Use-Case Analysis

Note: this section will only deal with the major use-cases that can occur within the system. To deal with all of them would mean hundreds of scenarios with all of their error conditions being presented, which would be impractical .

Five major use-cases can be listed as follows

1. Open a file to display a code file in a multi-coloured textual form
2. Print a multi-coloured textual code file to the printer.
3. Save an unsaved multi-coloured textual code file to the disk.
4. Select a line on the multi-coloured pixelised file and display the corresponding line on the mulit-coloured textual file.
5. Compare two source code files.

Each use-case depicted here will also have at least one error condition identified with it.

Normal Scenario for Use-Case 1:

The user wishes to open a multi-coloured code file.

The system prompts the user to enter the name of the file that the user wishes to see.

The user enters the name of the file that he wishes to see.

The system informs the user of the progress being made whilst opening the file.

The system shows the muti-coloured code file to the user.

Error Condition Scenario for Use-Case 1:

The user wishes to open a multi-coloured code file.

The system prompts the user to enter the name of the file that the user wishes to see.

The user enters the name of the file that he wishes to see.

The system informs the user that the file cannot be found / does not exist.

The user cancels the operation.

Error Condition Scenario for Use-Case 1:

The user wishes to open a multi-coloured code file.

The system prompts the user to enter the name of the file that the user wishes to see.

The user enters the name of the file that he wishes to see.

The system informs the user of the progress being made whilst opening the file.

The system infomr sthe user that the file cannot be opened / is corrupt.

The user cancels the operation.

Error Condition Scenario for Use-Case 1:

The user wishes to open a multi-coloured code file.

The system prompts the user to enter the name of the file that the user wishes to see.

The user enters the name of the file that he wishes to see.

The system informs the user of the progress being made whilst opening the file.

The user cancels the operation.

The system stops opening the file.

Normal Scenario:for Use-Case 2:

The user wishes to print the selected multi-coloured code file to the printer.

The system informs the user of the current default printer and other relevant print

information.

The user selects to print the multi-coloured code file

The system informs the user of the multi-coloured code file pages being printed.

The system informs the user that the multi-coloured code file pages are printed

The user acknowledges the system.

Error Condition Scenario for Use-Case 2:

The user wishes to print the selected multi-coloured code file to the printer.

The system informs the user of the current default printer and other relevant print

information.

The user selects to print the multi-coloured code file

The system informs the user of the multi-coloured code file pages being printed.

The system informs the user that there has been an error printing the multi- coloured code file pages

The user acknowledges the information and cancels the print job.

Error Condition Scenario for Use-Case 2:

The user wishes to print the selected multi-coloured code file to the printer.

The system informs the user of the current default printer and other relevant print

information.

The user selects to print the multi-coloured code file

The system informs the user of the multi-coloured code file pages being printed.

The system informs the user that there has been an error because there is no printer connected to the system.

The user acknowledges the information and cancels the print job.

Normal Scenario for Use-Case 3:

The user wishes to save a multi-coloured code file to a disk.

The system prompts the user to enter the name of the multi-coloured code file

and the location to save it.

The user informs the system of the name of the multi-coloured code file and the location to save it.

Error Condition Scenario for Use-Case 3:

The user wishes to save a multi-coloured code file to a disk.

The system prompts the user to enter the name of the multi-coloured code file

and the location to save it.

The user informs the system of the name of the multi-coloured code file and the location to save it.

The user cancels the save operation.

Error Condition Scenario for Use-Case 3:

The user wishes to save a multi-coloured code file to a disk.

The system prompts the user to enter the name of the multi-coloured code file

and the location to save it.

The user informs the system of the name of the multi-coloured code file and the location to save it.

The user cancels the save operation.

Normal Scenario for Use-Case 5:

The user wishes to select two or more files for comparison.

The system requests that the user enters the name of the first source code file

The user enters the name of the first source code file to be compared.

The system requests that the user enters the name of the second source code file

The user enters the name of the second source code file to be compared.

The system displays the two corresponding multi-coloured code files and the two corresponding multi-coloured pixelised files side by side.

Normal Scenario for Use-Case 5:

The user wishes to select two or more files for comparison.

The system requests that the user enters the name of the first source code file

The user enters the name of the first source code file to be compared.

The system requests that the user enters the name of the second source code file

The user enters the name of the second source code file to be compared.

The system displays the two corresponding multi-coloured code files and the two corresponding multi-coloured pixelised files side by side.

The user cancels the request.

1. The System Context Diagram

Figure 3.1.2.4 – System Context Diagram

Construction of a basic prototype was performed during this stage of the Analysis phase of the project. This graphically illustrated the menu system required for the requirements as specified in the Requirements Table. The protot ype was programmed using Microsoft’s Visual BASIC Version 5 programming language. This language is known in industry as being very suited to rapid prototyping and it proved to be that.

1. The System Design Phase
1. The OMT System Design Phase: An Overview

Once the problem has been analysed, the analyst makes a decision on what approach to make towards the design, i.e. the analyst must now decide on how the problem is to be solved. . System Design is a high-level strategy for solving the problem a nd building a solution. This phase includes breaking down the system into subsystems where necessary. Major conceptual and policy decisions that form the framework of the project are made here [5]. Different types of applications require different system architectures, therefore a different emphasis can be placed upon the three OMT models. The relevant decisions that the student must make are:

Organise the system into subsystems.

Choose an approach to data storage

Estimate Hardware and Software Requirements

Choose software control implementation

Effect of these decisions on the system design thus far.

2. The System Design of the SVCT Application

The Analysis clearly states what has to be performed by the fully implemented tool. The system must now be broken down into subsystems so that each subsystems can be tackled in detail later.

The main subsystems in the tool are as follows:

1. The Tokenizer subsystem.
2. The Pixelised Display subsystem
3. The Compariosn subsystem.

In effect, these subsystems form the basis for the initial classes that the system can be built around

1. The Tokenizer Object

This object will be responsible for the handling of the source code files and

visualising of the source code with different colours according to the different control constructs contained within in the file. The user will invoke this object when he selects to open a source code file. The object will then read the source code file into a line-storage area. It will then read the source code from the line-storage, one line at a time, and parse it to identify whether the line of code contains any language-specific control const ructs. The parsing shall work as follows. Firstly, it will be involved in reading in one character at a time from the line-storage area and placing it into a temporary line-storage area, which will only contain the characters that have been read in from t he line-storage area so far. Each time a character has been read in to the temporary line storage area, it compares its contents against a set of predefined tokens to see if its contents match a defined token.

In the case of visualising for a multi-coloured code file, the tool will keep a record of what type of keyword defines the line colour and the location of the keyword. It will then correspondingly assign that colour to the rest of t he code in that line, unless a different type of construct is found within the line, in which case, the rest of the line will be assigned the colour the particular keyword and act as before.

In the case of visualising for a code-editor type window, the tool will keep track of what keyword was found, assign only the keyword itself a colour and then empty the temporary line-storage area. It will then r ead in the next character from the line-storage area and placing it into a temporary line-storage area as before, and colour the rest of the line to a default colour unless a another keyword is found, in which case, only the keyword is given is colourised once again. This continues on for the rest of the source code file being opened. Once reading the source code file is complete, the object displays either the source code file in either its multi-coloured textual form or in its code-editor type form, wha tever has been specified by the user.

2. The Pixelised Display Object

This class will be responsible for displaying the pixelised representative view of

the multi-coloured textual code file to the user. It will primarily play the following role. Once the user has displayed the multi-coloured textual code file to the user, the user may select that a pixelised view be displayed. This obje ct will read colour and line information that relates to the corresponding multi-coloured textual code file from a storage area (see chapter 3.2.2.2) and will display a correspondingly coloured pixel-line file to the user.

3. The Comparison Class

textual code files and pixelised representative files to the screen when the user wishes to perfrom a comparison. Then, it is also responsible for searching for similarities between two or more user-specified files, displaying the resul ts to the user and calculating a percentage similarity based on the files which have been compared.

The object shall operate as follows: The user specifies which files to compare. The first file selected by the user will act as a base file with which the other files (secondary files) will be compared against. The object retrieves the data from a file information storage area one at a time and places the information from each file into separate temporary storage areas. Then the object will compare the contents of each secondary temporary storage area against the contents of the base fi le temporary storage area. Similarities can be illustrated with the following example as follows: if the temporary-file–information-storage-area is found to contain a ‘for’ statement with the same boundary conditions as a ‘for’ statement with the same bou ndary conditions in the base file temporary-file-information-storage-area, a similarity is said to have been detected. The number of similarities is then updated. Likewise, if the temporary-file-information-storage-area is found to contain a ‘for’ statement with certain boundary conditions but is not found in the base file temporary-file-information-storage-area, (or vice versa), a difference is said to have been detected. The number of differences is then updated. Similarity details are alw ays logged into a temporary report storage area. Then the object calculates the percentage similarity using the numbers of similarities and differences as inputs. This information is added to the report temporary storage area. Finally, the object displays this information to the screen.

1. Data storage approach

Oriented systems, because the focus of these systems is centred on the data and the operations that transform them. There will be several different needs for data storage in the tool. They are listed as follows:

• A storage area is needed to store information about the source code file that has been read in. This information contained in this storage area will be used by the Pixelised Display class to draw the pixelised representative view of the multi-coloured textual code file This information will also be used to fill the a temporary storage areas as used by the Comparison Class. This will be known as the File Information Array
• A storage area is needed to hold the data held by the Comparison temporary-file –information-storage-area. This will be known as the Temporary Comparison Array
• A storage area is needed to hold the data held by the Comparison Class temporary report storage area. This will be known as the Temporary Report Array.

The main type of storage areas readily available to the designer are databases, memory and disk storage.

The student decided that databases would not feature in this project for several reasons:

1. They add to the complexity of the project and an investigation would have to be undertaken as to what calls would have to be learned and used to interface correctly with a chosen database, for example, the Paradox database. It was f elt that this would be adding more complexity to an already difficult project.
2. The tool would not be able to function correctly without a database like Paradox always being available to the user.
3. Adding databases may be seen as overkill for the use that it would actually receive in this project.

The student has opted mainly for the use of Main Memory as a storage area because memory is relatively fast, easy to work with and suitable for nearly types of temporary storage operations. The one disadvantage of using memory to store all the data is that older computers may not have plenty of RAM. This will slow down the visualisation process if many other applications are running or if the user is attempting to visualise very large source code files. But this is not a major concern, as Visual C++ was designed to produce relatively fast applications and the developer can recommend a minimum configuration for optimum performance.

Disk Storage will also be used in this project. It will be necessary to save the File Information Array to disk after a visualisation has been performed. This is so that the user can generate a Comparison Report even after the multi-col oured textual code file has been closed. Therefore, each source code file that has been visualised will have a corresponding ‘Logfile’. The logfile will contain a copy of the File Information Array for that file. If the user later requests to do a compari son that involves a source code file, the comparison Class will access this logfile and read its contents into the Temporary Comparison Array.

This object will be responsible for storing and retrieving the FileInformationArray from log files corresponding to visualised textual code files. A logfile is created when a source code file has been visualised and the FileInfor mationArray needs to be written to disk. This is so that the Comparison Object can open a logfile at any time and use it to take part in the comparison.

When the FileInformationArray needs to be written to a logfile. The following takes place.

The object reads in the name of the multi-coloured textual code file and makes the name of the logfile to be opened and written to. The logfile is then opened to be written to. As a precautionary measure against opening log files that h ave now been created by the tool, the file key "SVCTv1" is written to the start of the file as a type of key to the file. Then the FileInformationArray is to the Array_File_Buffer, which is then written to the file. On completion of this task the object c loses the logfile.

When the FileInformationArray needs to be extracted from the logfile. The following occurs.

The object opens the logfile for reading and expects to see the file key ‘SVCTv1’ (ie the first entry in the logfile). If the first entry is not equal to the file key, the object informs the user that this logfile is invalid, closes the logfile, and aborts the comparison tests. If the first entry is equal to the file key, the object copies the FileInformationArray into the Temporary Comparison Array of the Comparison Object. Then it closes the logfile.

The File Information Array will be structured as follows:

Line_Number, - This contains the line number in qeustion

Line_Length, - This contains the length of the line in characters should version 2 choose to display the pixelised lines according to the length of the textual lines.

Bound_1, - This may hold a numerical bound value that has been read from a construct. It will be used when comparing two or more files for similarities.

Bound_2, - This may hold a numerical bound value that has been read from a construct. It will be used when comparing two or more files for similarities.

The Bounds are used to hold numerical data that was detected as a number straight after a control construct. Figure 3.2.2.2 illustrates an example of Bound assignment.

Figure 3.2.2.2 – Bounds Assignment example

As this is a tool that visualises and compares source code, it stands to reason that there will be no hardware directly involved in the running of the tool. It is decided that the minimum hardware configuration of the P.C. that i s to run this tool is as follows:

• Pentium 75 Mhz,

• 16 Mb RAM,

• 800x600 minimum screen resolution, 1024x768 or greater recommended,

• 65536 (High Colour) colours minimum,

It is decided that the software requirements are

• Microsoft Windows 95m 98 or NT.

See chapter 2.2.3 for more information.

Control can be implemented in several different ways over the software. It is normal that there is only one control style for the whole system. This tool will employ External Control. This is the flow of externally visible events among the objects in the system [5]. Even though this is an object-oriented system, it can be described as a procedure-driven system in terms of software control. This means that control resides within the program code, and does not mean that the system has been designed using traditional functional software engineering methodologies. In terms of software control, procedure-driven systems operate as follows:

Procedures issue requests for external input and then wait for it; when the input arrives, control resumes within the procedure that made the call [5].

After taking the preceding system policies into consideration, it is now possible to provide a more detailed set of classes with some corresponding attributes and methods.

Figure 3.2.2.5.1 (a) – The Tokenizer Object

Figure 3.2.2.5.1 (b) – The PixelisedDisplay Object

Figure 3.2.2.5.1 (c) – The Comparison Object

Figure 3.2.2.5.1 (d) – The FileInformationArray Object

Figure 3.2.2.5.1 (e) – The LogFileObject

Figure 3.2.2.5.2 (a) – State Diagram for filling the FileInformationArray whilst visualising a multi-coloured textual code file.

Figure 3.2.2.5.2 (b) – State Diagram for displaying the pixelised representative view from the File Information array

Figure 3.2.2.5.2 (c) – State Diagram for filling the Tempoarary Comparison Array from a logfile.

1. The Object Design Phase
1. The OMT Object Design Phase: An Overview

Whereas the Analysis Phase determines what is needed to be done and the System Design determines how the student is to approach the problem with high-level objects deigned, the Object Design Phase expands the full class definitio ns, with attributes and operations included, to suit the implementation language of the project. This also includes detailing algorithms and data structure. So, in effect, the Object Design phase deals with the computer domain details of the high-level re quirements as specified earlier in the lifecycle, and adds new computer domain details if necessary. [5] states that the following can be undertaken in this phase.

• Design algorithms to implement the operations

• Ensure coherence of entities.

An additional step that will be undertaken before the above steps are accounted for, is that of the effect of the computer domain language upon the objects modelled in chapter 3.

1. The Object Design of the SVCT Application

At this phase, some adjustments and decisions must be made regarding the high-level classes defined in chapter 3.2.2. Firstly, a device context must be chosen for the Pixelised Display object. The nearest entity that matches the definition and usage of the Pixelised Display object is a Bitmap. In Windows programming, there are 2 types of bitmap available, Device Dependant Bitmaps (DDB) and Device Independent Bitmaps (DIB). The student has chosen to implement a Device Independent Bitmap because of its natural independence from specific hardware, i.e. DDB’s need specific hardware to run properly and this is obviously a constraint that the tool does not need.

Another consideration that need be made at this phase is the computer language that must be visualised. This was decided much earlier than this stage (for project timing and research reasons) but the language that was chosen to be visua lised is C++. The reasons that C++ was chosen to be visualised and compared are as follows:

• C++ is a very popular language yet a very difficult language to learn if you have not written C or studied object orientation previous to learning it. This makes it an ideal candidate for a language in which assignments will be copi ed.
• C++ is a widely used industry language, and therefore, many people may find use for a software visualisation and comparison tool such as this.
• C++ can be a very difficult language to read and understand clearly. It is hoped that a tool such as this will be able to help in that area by colouring different parts of the code according to their constructs, thus making it easie r to know where control decisions are being made.

described in chapter 3.2.2. This is to be expected because it is very complex and allows for many different applications to be developed, from MS-DOS console applications to powerful Windows GUI applications using an object-oriented int erface to the Windows API. Many new hurdles which the student had to overcome are listed as follows:

The Integrated Development Environment proved to be a much more difficult hurdle than would have been first perceived at the start of the project. A tremendous amount of options are to be had using the IDE, but they did present a learning curve to get used to the IDE, which was quite unexpected.

Visual C++ allows the user to build a comprehensive GUI using the MFC (Microsoft Foundation Classes) provided with the compiler. These offer object-oriented methods to build up a windows application in a much easier way than the event-driven Windows API calls would have had. The Windows API is huge, with more than 2,000 function calls and over 6,00 names when macros are included [4]. The MFC library can be used through calls or by overriding virtual methods defined in the supercl asses in the hierarchy.

architecture. That is, the responsibility of managing a window frame, what’s displayed inside the frame and the storage of the data that the view uses are not left upto one class. These responsibilities are shared amongst three individu al objects that are sometimes created by the IDE. These classes are:

This type of class (derived from the MFC class CDocument) is used to manage the underlying data behind a window. In the implementation of the tool, CDIBDoc and CTokenizerDoc both inherit data and methods from the superclass, CDocume nt. For example when serialising information in the Cdib class, CDIBDoc Serialize method (see chapter 4.1.2.2.3) calls the Cdib::Serialize function which looks after the saving and restoring of information to and from the a storage medium. See Figure 4.1 .2.2.2(a)

The View Class

This type of class (derived from the MFC class CView, which is derived from CWnd) is used to represent the information of the document. The view uses the documents access functions to work with the information. It must be noted that document windows cannot share views. There is at least one viewper document window.

The Frame Class

This type of class (derived from the MFC class CMDIFrameWnd and CMDIChildWnd for this MDI tool (see the next paragraph)) contains or surrounds the view. See Figure 4.1.2.2.2(c). Therefore, it too is a window. It is called the no n-client area of the window, which doesn’t share the same properties as the view window it surrounds.

Figure 4.1.2.2.2(c) – Frame window in the SVCT tool.

So what keeps all of these corresponding classes together, especially when they all are derived from different superclasses. The answer is the Document Template. This is an entity defined inside the MFC code that points to do cument, view and frame classes. In MDI applications (as this one is), there is one template object for every type of documents window that the application can create. Document templates are also used when the user wishes to open a file and save a file etc . It reads in the filter of the file (e.g. the ‘cpp’ part of a C++ filename) and cycles through the document templates until it finds a document template with an identical filter match. If it couldn’t find a match, the file that the user was trying to ope n cannot be opened by the application. This is also used when the user wants to print the currently selected file, whether it be (for this application) a C++ file, a header file or a bitmap file. The document template receives the filter of the file from the application and sets up the printing accordingly [4]

MFC contains 3 predefined techniques for saving data from objects to storage areas, called Serialisation. It is capable of writing whole object to a disk. This has a major consequence for one of the high level objects identif ied in chapter 3. It was the purpose of the logfile to write out the FileInformationArray object to the disk in the form of log files. But MFC now provides a fast and cleaner solution to the LogFile objects existence. So, the FileInformationArray will no w be written to disk using its serialisation function. The student has decided that the files saved through using serialisation will still be called Log Files for the sake of consistency.

Events are triggered when the user interacts with the program. Message Maps are functions implemented in the MFC library that carry the meaning of the event to an appropriate method in the MFC library. This can then be overridden in a subclass and a new meaning can be given to the event. There is a clear example of this in the SVCT tool. The message that is sent to the window when the user ’right-clicks’ on a coloured text window has been overridden so that instead of nothing hap pening, a bitmap appears instead.

Visual C++ provides a small icon editor for the programmer to paint application icons with. This allowed the student to design icons for the tool.

4.1.2.3 Other modifications to the high-level object specification.

Two more modifications are to be made to the objects to ensure compatability with the system and to provide for modularity.

Firstly, the FileInformationArray is to be changed to become a linked list of FileInformationarrays. This ensures that there will be a FileInformationArray slot available for, at the very most, one line of code.

Also, the Tokenizer object is to be subdivided into separate smaller classes. This is because its original design left it carrying out a number of tasks on its own, which isn’t desirable in object orientation because this means that the re is a lack of coherence within the object. Its constituent components are a textbuffer class (to read and write files to the disk), a Visual C++ Edit View window and derived views so that the text can be displayed on the screen and can be parsed to deal with the tokenizing.

The heart of the application has to be in the cplusplus.cpp file. The main function in here is ParseLine. It parses one line at a time and is called from the DrawSinglLine method, a member of the CSVCTTextView class.

The algorithm is as follows:

(Note: a block is said to be a word to check against the keywords)

It determines the length of the line and

The above is essentially the algorithm. It ensures that every character of every line is checked and, and that every token is checked to see if it’s a keyword. Eventually, the whole source code file is accounted for and is eventu ally displayed to the screen. Note that when the line type is set to e.g. ‘red’ for a ‘for’ loop, this is not set back to ‘empty’ (its original value) until the end of the line is reached or another keyword is found.

The list of keywords and the corresponding colour assignments are in Appendix C.

1. `The Implementation Phase
1. The OMT Implementation Phase: An Overview

OMT refers to the Implementation Phase as an extension of the design process that should be a straightforward and mechanical step. Issues here are carried down from the Analysis and Object Design Phase and can be noted as follow s:

• Robustness

• Extensibility

• Reusability

1. Share newly written code in a project
2. Use previously written code that has already been tested and works correctly.

[5] states that this stage should be much more mechanical than the three previous stages because all of the analysis and design work should be completed and there should only be programming work with no decisions needing to be ma de. According to the recommendations set out at the start of this phase, the student will look at the areas of robustness, extensibility and reusability.

The student believes that the software visualisation and comparison tool is adequately extensible. One prime example of this is this interface between the C++ parser and the rest of the code. The parser code in the ‘cplusplus.cpp ’ file is not a member of any of the classes and it only depends on the colours being made available at CSVCTTextView::GetColor. This makes it reasonably easy to extend the parsing capabilities of the tool to parse other languages. Also, the type and siz e of information being compared can be easily changed because the FileInformationArray, the TemporaryComparisonArray and the TemporaryReportArray all have the same structure.

This tool makes use of both types of software reuse.

The tool uses practically the same code to open and display 2 different file types, i.e. C++ and a C++ header file. The only code that had to be added was a document template for the C++ header file. Otherwise, it can be displaye d using the very same code that the C++ source code file is displayed with.

This tool also uses some previously written code that was made open source by the authors. In recognition of this, they will be mentioned in my acknowledgement list. This code helped in getting text to the text window.

Visual C++ provides some standard components code with the IDE. One such example of use of Microsoft’s code in this project is the code that enables the splash screen to appear on start-up of the tool.

Also, although there is no code directly inside the tool from the Microsoft help files, the help files did provide good examples on how to set up document templates and menus, without which, the project would not be as strong.

At what stage is the implementation of the Software Visualisation and Comparison Tool at, currently.

The main goal of this project was to be able to research, develop and implement a tool that a lecturer could use to see if the software assignments that he / she was getting back from the students were copied. This was to have been det ermined through visualising the code with different colours, the colours being assigned according to the control constructs and keywords lying inside the code. The question that must be asked is ‘Is it possible to be able to tell if student have being co pying from each other’ using the current version of the SVCT. And the answer is YES, using the source code display alone, it is possible to put two or more files side by side on the computer screen and compare them by watching for matching colours, (and h ence, constructions)

But this is not the only method specified by the user (lecturer in the case) of how to visualise the code. There is another method. This method uses the code profiling technique to display one coloured pixel line per one coloured line o f code. The question that must be asked is ‘Is it possible to be able to tell if student have being copying from each other using this technique? At the time of print, the bitmap file can draw lines to the screen but cannot display dynamic source code fi le information at the moment because the linked list of FileInformationArrays has not been implemented yet. The student aims to try to have this working somewhat better by the time of the bench demonstration on Wednesday 28^th April, 1999.

The final method is the comparison method. This involves taking the FileInformationarray contents for different files and doing a comparison of the date. This has not been implemented yet as the FileInformationArray has not been impleme nted yet.

The software visualisation area proved to be an interesting area to investigate as part of this project. In general, there seems to be a lack of books on the subject, but plenty of papers from thos e who put their full-time effort into researching it. The relevance of the area may be considered by some to be small and unprofitable. True, there are not too many software visualisation systems on the market today, as there isn’t a great demand for them . From the student’s research, there doesn’t seem to be any major pulling together of academia which investigates the whole area and large public software firms, who are ignoring the area. Research data seems to be mainly gathered from experimenting with students and seeing what they like.

Microsoft Visual C++ 5 is an extremely difficult language to learn. Even now the end of the project, uncertainties about the language linger with the student. Also, the student found that the on-line documentation to be confusing an d unclear most of the time, and it became apparent that one or two of the books read were practically the same as the documentation, which didn’t help.

The student found that OMT is a very detailed methodology and sometimes a bit puzzling in its approach to object design and implementation. The student found that when documenting the object design stage, that it was more suitable t o actually put it into the implementation chapter in the project report, as the object design is mainly focused towards implementation anyway.

Overall, the student found the project a challenge, both in terms of software visualisation research, Visual C++ and OMT. But the student is pleased that the chance arose to get familiar with these technologies before moving out to industry.

My thanks firstly must go to my supervisor, Mr. Tom Newe, for his helpful guidance and putting up with me running in late to meetings all out of breath. I’d like to thank Liz Kiely for all the moral support when things sometimes seemed l ow. I’d like to thank my parents, who sent me to university with the brightest of hopes, I hope I can pay them back. Many thanks must go to fellow 4^th year, Thomas Quillinan for the load of 2 zip disks and a zip drive for the past six months. A lso my extended thanks to himself again and Gareth Eason, another fellow 4^th year Computer Eng., for use of the skynet and intel megabytes of storage. Thanks to Andrei Stcherbatchenko at CodeGuru.com for helping me with the language and the edi t window and to Hans-Martin Brændmose Jensen for help with the bitmap class. Thanks to John Nelson (ece dept) for introducing me to OMT and to Eamonn McGuinness of the Intel Lab for reinstalling Visual C++ every so often.

A very personal thanks must go to John Stasko, Georgia Institute of Technology, Atlanta, for personally forwarding me some of his co-authored papers on Software Visualisation via surface mail. And finally, thanks must go to the doctors at the Regional Hospital in Limerick who managed to keep my broken hand in reasonably good shape during the last 3 weeks of the project..

8. References

5 [Rumbugh et al]

6 [JACOBSON ET AL, 92]. - [JACOBSON ET AL, 92]

7 [LILLIS, 98]

Shane Lillis; Use Cases: Adopted by UML and OOSE but not by OMT1;

8. [MULHOLLAND, 97].

9. [STASKO, 95].

10 [RUMBAUGH, 94]

11 [Stasko, Kracmer]

John T. Stasko; Eileen Kracmer;

A Methodology for Building Application-Specific Visualisations of Parallel Programs; Atlanta; 1992

12 [Stasko, 92]

John T. Stasko; Three-Dimension Computation Visualisation

Graphics, Visualisation and Usabitity Centre; College of Computing;

Georgia Institute of Technology; Atlanta; 1992

13 [Ball, Eick]

Thomas J. Ball and Stephen G. Eick; Software Visualisation is the Large;

Illinois, 1996

14 [Principle Taxonomy of SV]

http://wwwendres.informatik.tu-muenchen.de/leute/trilk/sv.html

15 [Ball, Eick October 94]

16 [Badre, Beranek, Morris, Stasko]

Albert Badre, Margaret Beranek, J. Morgan Morris, John Stasko.

Assessing Program Visualisation systems as Instructional aids; Atlanta.; 1991

17 [Eick, Steffen, Joseph, Sumner]

18 [Muthukurmarasamy, Stasko]

Visualising Program Executions on Large Data setsUsing Semantic Zooming;

Atlanta;

19 [Dr. Catalin Roman]

Gruia-Catalin Roman; Delbert Hart; Charles Calkins;

Visual Presentation of Software Specifications and Designs; Washington

University;

21. Ball, T. http://www.bell-labs.com/tball
22. Nelson 98 – John Nelson’s Software Engineering Notes, September 1998
23. [BALL, SV]. Ball, T. http://www.bell-labs.com/tball
24. [Bell Labs]; www.lucent.com

Viktor Toth; Visual C++ 4 Unleashed; SAMS Publishing; Indianapolis; 1996

William H. Murray, Chris H Pappas; Windows 95 and NT Programming with

the Microsoft Foundation Class Library; Academic Press; 1996

Shane Lillis

KEYWORDS: Use Cases, Software Engineering Methodologies, requirements analysis,

ABSTRACT:

1 – OMT1 refers to the original introduction of OMT in 1991. This has since been revised and the revised version will be labelled OMT2 in this paper.

1. Introduction - The Development of Use Cases in Software Methodologies.

1. Uses:

This is a relationship between use cases which when used, means that the behaviour defined in the former Use case includes the behaviour exerted by the latter use case.

2. Extends:

When the Object Modelling Technique was introduced in 1991 [RUMBAUGH ET AL, 91], it did not formally specify the utilisation of use cases. The method consisted of 4 phases as seen in Figure 4:

The following is a list of references from which this document has evolved.

Appendix C - Control Constructs and the assigned colours

LIGHT GREEN 102, 255, 153 switch, case, break, default

PINK 255, 153, 255 TRY, CATCH, THROW

RED 255, 0, 0 for

BLUE 0, 0, 255 while

BLUE 0, 0, 255 do

GREEN 0, 255 ,0 if

GREEN 0, 255 ,0 else;

ORANGE 255, 153, 0 struct{}

PURPLE 204, 0, 255 union{}

AQUA 0, 255, 255 template

GREY 128, 128, 128 // and /* */

LIGHT BLUE 153, 255, 255 extern

DARK DULL BLUE 0, 128, 192 preprocessor commands

SILVER 192, 192, 192 new, delete

VIOLET 238, 130, 238 static