A TOOL TO SUPPORT TEACHING OF CONCURRENT PROGRAMMING

By

David Ebo Adjepon-Yamoah (110240945) August 2012 Supervisor: Dr. Marta Pietkiewicz-Koutny

MSc. Computing Science Newcastle University

This report is submitted in partial fulfilment of the requirement for the degree of MSc. in Computing Science.

[Word Count: 17,888]

Declaration
All sentences or passages quoted in this dissertation from other peoples work have been specifically acknowledged by cross-referencing to author, work and page(s). Any illustrations which are not the work of the author of this dissertation have been used with the explicit permission of the originator (where possible) and are specifically acknowledged.

Name: David Ebo Adjepon-Yamoah

Signature: .

Date: 27th August, 2012

Abstract
This document outlines my MSc Dissertation Project, the purpose of which is to develop a tool to support teaching of Concurrent Programming. The teaching tool when developed will aid mostly Java and C++ students to be able to further understand the benefits of Concurrent Programs. The tool provides an opportunity to test the synchronised Concurrent Programs against their corresponding unsynchronised programs. This version will provide visualisation of multithreaded program behaviour and animations of the solutions of the Producer/Consumer problem and Reader/Writer problem.

ii

Acknowledgements
I thank God for his mercies and grace in my life, especially during the period of this MSc dissertation. The development of the teaching tool in this project would not have been possible if it were not for the excellent standard of teaching provided by the staff in the School of Computing Science at Newcastle University together with the outstanding facilities, resources and the staff of the Robinson Library. I would like to thank Dr. Marta Pietkiewicz-Koutny, my project supervisor and lecturer for Concurrent Programming which was extensively used in this project, for her support, and in particular her guidance with the software evaluation, Dr. Nick Cook who taught me Advanced Java Programming, Dr. Steve Riddle and Dr. Claire Ingram who taught me Software Engineering with Group Project. I will also like to thank my Tutor, Dr. Claire Ingram
who challenged me to do my best.

Finally, I thank my mother; Dora Saa Asiedu for her advice and encouragement. I also thank my uncles; Professors Kenneth Kweku Adjepon Yamoah and Alex B. Asiedu for their support in the form of academic advice and financial assistance throughout my studies.

iii

TABLE OF CONTENT
DECLARATION...................................................................................................................... I ABSTRACT ............................................................................................................................. II ACKNOWLEDGEMENTS ................................................................................................. III TABLE OF CONTENT........................................................................................................ IV TABLE OF FIGURES .......................................................................................................... VI TABLE OF TABLES......................................................................................................... VIII 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2.0 INTRODUCTION......................................................................................................... 1 WHAT THE PROJECT IS ABOUT ...................................................................................... 1 THE REASONS FOR THIS CHOICE .................................................................................. 3 AIMS ............................................................................................................................ 3 OBJECTIVES .................................................................................................................. 3 EXPECTED ACHIEVEMENTS .......................................................................................... 4 APPROACH TO THE PROBLEM ........................................................................................ 4 INITIAL AREAS OF RESEARCH ...................................................................................... 5 WORK PLAN ................................................................................................................. 5 OUTLINE OF THE THESIS ............................................................................................... 6 BACKGROUND RESEARCH .................................................................................... 8

2.1 LITERATURE REVIEW ................................................................................................... 8 2.1.1 Concurrent Programming and Its Trends ............................................................... 8 2.1.2 Relevance of Concurrent Programming in the Information Technology Industry 10 2.1.3 Visualisation and Animation Technologies ........................................................... 11 2.1.4 Technologies for Developing the Teaching Tool ................................................... 12 2.1.5 Human Computer Interaction (HCI) Issues .......................................................... 20 2.2 EARLIER WORK DONE IN THIS AREA ......................................................................... 21 3.0 BUILDING THE TEACHING TOOL ..................................................................... 23

3.1 APPROACH TAKEN ..................................................................................................... 23 3.1.1 Project Design ....................................................................................................... 24 3.1.2 Synchronisation Problems (Prototype 1) .............................................................. 25 3.1.3 Graphical User Interface Attempt (Prototype 2) ................................................... 38 3.1.4 Final Project (Prototype 3) ................................................................................... 40 3.2 HIGH-LEVEL EXPLANATION ....................................................................................... 44 3.2.1 Java Classes Overview .......................................................................................... 45 3.2.2 System Overview .................................................................................................... 47 3.3 TESTING ..................................................................................................................... 50 3.4 USER MANUAL ........................................................................................................... 52
iv

4.0 4.1 4.2 4.3 5.0 5.1 5.2 5.3 6.0 7.0 7.1 7.2 7.3 7.4 7.5 7.6

RESULTS AND EVALUATION............................................................................... 56 PRESENTING THE RESULTS ......................................................................................... 56 DISCUSSION ................................................................................................................ 57 EVALUATION OF THE APPROACH ................................................................................ 58 CONCLUSIONS ......................................................................................................... 61 MEETING THE ORIGINAL OBJECTIVES ........................................................................ 61 POSITIVE AND NEGATIVE ASPECTS ............................................................................ 63 FUTURE WORK ........................................................................................................... 64 BIBLIOGRAPHY ....................................................................................................... 66 APPENDICES ............................................................................................................. 69 PROJECT TIME PLAN .................................................................................................. 69 USER MANUAL ........................................................................................................... 70 CLASSES IN PROTOTYPE 1 .......................................................................................... 72 CLASSES IN PROTOTYPE 2 (GUI_PROTOTYPE2 PACKAGE) ......................................... 73 CLASSES IN PROTOTYPE 3 (PROJECT PACKAGE) ......................................................... 74 JAVA DOCUMENTATION (JAVADOCS) FOR FINAL APPLICATION ................................. 74

TABLE OF FIGURES
Figure 1: Multicore chips perform better based on Intel tests using the SPECint2000 and SPECfp2000 benchmarks. ......................................................................................................... 1 Figure 2: Framework of Cognitive Theory of Learning with Media ........................................ 2 Figure 3: Time Estimation of Dissertation (Designed Using Gantt Project 2012) .................... 6 Figure 4: Typical architecture for a parallel and distributed program. ...................................... 9 Figure 5: Parallel computing and the next generation of user experiences. ............................ 10 Figure 6: Java AWT, Swing and Applet Components Hierarchy ............................................ 19 Figure 7: An Overview of the Relationship between Events, Event Dispatcher and Event Handlers ................................................................................................................................... 20 Figure 8: Overview of Evolutionary Prototyping Technique .................................................. 23 Figure 9: Bounded Buffer Demonstration of the Producer/Consumer Solution by Magee and Kramer (2006) [14] .................................................................................................................. 24 Figure 10: Code Snippet of Random Integer Generation and Storage in Buffer of Numbers . 26 Figure 11: Code Snippet of Bounded Buffer Monitor (buffer) in the BufferImplementation Method ..................................................................................................................................... 26 Figure 12: Output of Synchronised Producer/Consumer Solution with Printing Anomaly .... 27 Figure 13: Code Snippet of the Run () Method in the Producer Class with Printing Statements .................................................................................................................................................. 28 Figure 14: Code Snippet of the run () Method in the Consumer Class with Printing Statements ................................................................................................................................ 29 Figure 15: Code Snippet of the put () Method in BufferImplementation<E> Class with Printing Statements .................................................................................................................. 30 Figure 16: Code Snippet of the get () Method in BufferImplementation<E> Class with Printing Statements .................................................................................................................. 31 Figure 17: Output of Resolved Printing Anomaly ................................................................... 32 Figure 18: User Implementation Options in Version 2 of Prototype 1 .................................... 33 Figure 19: Textual Output of Synchronised Implementation of the Producer/Consumer Problem .................................................................................................................................... 34 Figure 20: Textual Output of Unsynchronised Implementation of the Producer/Consumer Problem .................................................................................................................................... 35 Figure 21: Textual Output of Synchronised Implementation of the Reader/Writer Problem (A) ............................................................................................................................................ 36 Figure 22: Textual Output of Synchronised Implementation of the Reader/Writer Problem (B) .................................................................................................................................................. 37 Figure 23: Textual Output of Unsynchronised Implementation of the Reader/Writer Problem .................................................................................................................................................. 38 Figure 24: Imported Packages used in Prototype 2 ................................................................. 39 Figure 25: Prototype 2 Graphic User Interface ........................................................................ 39 Figure 26: Prototype 3 Graphic User Interface for Synchronised Producer/Consumer Implementation ........................................................................................................................ 41 Figure 27: Prototype 3 Graphic User Interface for Unsynchronised Producer/Consumer Implementation ........................................................................................................................ 42
vi

Figure 28: Prototype 3 Graphic User Interface for Synchronised Reader/Writer Implementation ........................................................................................................................ 43 Figure 29: Prototype 3 Graphic User Interface for Unsynchronised Reader/Writer Implementation ........................................................................................................................ 44 Figure 30: Producer/Consumer Solution Class Diagram ......................................................... 45 Figure 31: Reader/Writer Solution Class Diagram ................................................................. 46 Figure 32: Conceptual Class Diagram showing an Overview of the System in Prototype 3 (A) .................................................................................................................................................. 48 Figure 33: Conceptual Class Diagram showing an Overview of the System in Prototype 3 (B) .................................................................................................................................................. 49 Figure 34: Conceptual Class Diagram showing an Overview of the Relationship between the ProducerConsumer_Dialog Class, the ActionListener and the JDialog Libraries ................... 50 Figure 35: Use Case Diagram of Project ................................................................................. 51 Figure 36: Labelled User Interface to show Steps in User Manual ......................................... 53 Figure 37: Snapshot of User Manual in the Final Application ................................................ 54 Figure 38: Terminal to Provide Further Information to Users ................................................. 58

vii

TABLE OF TABLES
Table 1: Milestones and Time Estimation of Dissertation......................................................... 5 Table 2: TIOBE Programming Community Index for July 2012 (Programming Languages Popularity)................................................................................................................................ 18 Table 3: Design Requirements of Project ................................................................................ 25 Table 4: Checks Conducted during System Testing ................................................................ 52

viii

1.0 INTRODUCTION
1.1 What the Project is about

Once upon a time programmers were taught to write sequential programs, with the expectation that new hardware would make their programs perform faster. In the early 2000s, we hit a power wall [1]. Today, all major chip manufacturers have switched to producing computers that contain more than one CPU [2]. A major chip manufacturer, Intel performed tests based on the SPECint2000 and SPECfp2000 benchmarks and identified that, the multicore processors are increasingly performing impressively as against the single-core processors from 2000 through 2008. This is represented in Figure 1 below. They forecast that this performance will increase during the next few years.[3]

(Adapted from Geer D. 2005)[3]

Figure 1: Multicore chips perform better based on Intel tests using the SPECint2000 and SPECfp2000 benchmarks.

Machines with four or more cores are already shipping, and tomorrows machines promise still more cores. However, these additional cores only improve the performance of multithreaded applications. The prevalence of single-threaded applications means that these cores often provide no benefit. To encourage development of multi-threaded applications, many new languages such as C# and Visual Basic.NET have been proposed and introduced to ease the burden of writing parallel programs. While these languages make parallel programming easier than in the past, the effort involved in creating correct and efficient parallel programs is still far more than that of writing the equivalent single-threaded version [4]. Developers must be trained to program and debug with parallel concerns in mind (i.e. deadlock, livelock, race conditions) [4]. Parallel and concurrent programming has rapidly moved from a special-purpose technique to standard practice in writing scalable programs. We need to start teaching courses that prepare students for multicore architectures now, while concurrently updating the whole curriculum. Since parallel and concurrent programming was previously relevant only to the relatively small collection of students interested in highperformance computing, operating systems, or databases, instructors may need help developing course materials for this new subject [5]. Appropriate visual teaching aids such as
1

animations and simulations will also be needed to facilitate easier demonstration of concurrent processes during practical sessions. Practical work has a time-honoured place in the education of scientists and engineers [6]. Teaching aids may also sustain attention and enhance interest in a topic providing they are well presented and colourful. Effective use of audio-visual aids has been shown to improve learning in secondary school pupils [7] and in higher education [8]. Ideas which are linked through visual symbols are also likely to be retained in the long-term memory. It is therefore worth spending a little time thinking out a visual presentation of key concepts, relationships and processes [6]. Such aids will be greatly appreciated by students as they can visualize the implementation of the various threads in a program. Although multimedia environments are becoming widely recognized as effective aids in learning, until recently, there has been no theoretical or empirical framework for how they support learning, as would be needed to guide the efficient design of effective new applications. To address that need, Moreno (2006) proposed a framework of cognitive theory of learning with media (CTLM) which is represented below. [9, 10]

(From Moreno, 2006)[10]

Figure 2: Framework of Cognitive Theory of Learning with Media

Robeck & Sharma (2011) explains that the fundamental within this framework, shown in Figure 2 are three principles. 1. Multimedia: Students learn better from encounters with several forms of media than when information is presented in a single formatfor example, from words and graphics used together, rather than from words alone. When more than one form of media are used, such as when relevant graphics are added to words, learners are induced to select and connect both media, which contribute additively to constructing a mental model. 2. Interactivity: Students learn better by manipulating media and materials rather than by passively observing the processes or products of manipulation by others. Interactivity encourages the processing of new information by engaging students in an active search for meaning that is required to interpret, understand, and connect ideas being represented. 3. Spatial contiguity: Students learn better when multiple sources of visual information are integrated rather than separated. Non-integrated sources of information force learners to hold one source in working memory while attending to the other; mental connections between them are less likely to occur. [9]

1.2

The Reasons for this Choice

The learning process is usually made up of theoretical introduction and practice. Students often gain more understanding when they practice on a model of the area or subject that they are introduced to. Such practice can provide a relaxed atmosphere where they can have a hands on experience of a model of the subject under review, and they can see these exercises as a source of fun. Sometimes, it is not possible for teachers to provide a model in a subject to practice with the students. Subject areas such as the operations of the central processing unit (CPU) of a computer or experiments in particle physics are often difficult if not impossible to model. The use of computer simulation as an alternative modelling tool provides a better means of modelling almost all subject areas. Blake & Scanlon (2007) points that: .they (simulations) free up teacher time so that they can interact with students instead of dealing with the management of the experimental set-up/apparatus and supervision.[11] In teaching the dynamics and complexities of Concurrent Programming, students will be able to easily and better understand the various concepts in this subject when simulations are used. Also students will have more face-to-face time with the teacher and teaching assistants during practical sessions. The amount of resources such as time used in developing these simulators will be far less compared to the resources saved over a period of time as a result of using simulators in teaching.

1.3

Aims

The aim of this MSc Dissertation project is to develop a tool that would be to provide animations of the solutions of the well-known synchronisation problems in Concurrent Programming; Producer/Consumer problem and Readers/Writers. This tool will focus on presenting both the synchronised and unsynchronised implementations of the above mentioned problems.

1.4

Objectives

To achieve this aim, some objectives are set: i. Research selected existing systems, which provide visualisation of the mentioned synchronisation problems. Study animation and visualisation techniques. Research technologies that might be employed to build a teaching tool. Design and implement a tool that visualises/animates the solutions to the chosen synchronisation problems. Evaluate the usability and usefulness of the system.

ii. iii. iv.

v.

1.5

Expected Achievements

One of the primary goals of this project is to produce a teaching tool that demonstrates the synchronisation problems. The tool provides an avenue to compare both synchronised and unsynchronised versions of solutions to some well-known concurrency problems. The software application is a teaching tool which animates the solutions to the Producer/Consumer problem and the Reader/Writer problem. The tool further provides detailed explanation of the complex anatomy of this kind of programming. The tool will also provide a relatively relaxing experience in learning and understanding this field, as against the usual text-book description of this concept of programming. The concept of interactivity is greatly explored to further whip up interest in users as a two-way means of communication is established. Interactivity encourages the processing of new information by engaging students in an active search for meaning that is required to interpret, understand, and connect ideas being represented[9]. The teaching tool is expected to be distinctively informative and understandable both to the instructors and students. Distinctive colours (Green, Yellow and Red) will be used to represent the three major states of a thread: Running, Waiting and Terminated respectively. These states will also be shown on the simulator as text. Also, this application can be downloaded from the internet and run as a standalone application. The application is expected to be executable on all Windows machines, irrespective of whether it supports the Java Virtual Machine or not. This ensures that users are able to use the application on many computers. That apart, both electronic and printed user manuals will be developed for both instructors and students using the simulator.

1.6

Approach to the problem

A major challenge that was encountered in the system design for this project was that the developer (author of this thesis) was not familiar with the technologies for animation. The process of establishing a relationship between the individual threads and their respective animations was also a challenge. A great amount of research was conducted to ascertain the appropriate and most convenient means of solving the above mentioned animation challenge. NetBeans IDE 7.1.2 was used to implement my project because it provided appropriate Java libraries and platforms for concurrency, graphical user interface and event handlers. The waterfall software process model was initially considered as it has a sequential nature that enables easy refactoring ("The process of changing a software system in such a way that it does not alter the external behaviour of the code, yet improves its internal structure" [12]) and documentation of the various stages of the process. Unfortunately, this model required that the software requirements and specifications are to be clearly defined and the developer should have a high level of experience in using this model. Also, when there is a problem in the development process, a total overhaul of the system is recommended. Therefore, an evolutionary prototyping model was chosen as a suitable option. The evolutionary prototyping model provides a high level of flexibility to the developer as software requirements are not expected to be clearly defined at the beginning of the development process, and various small solution ideas can be tested as prototypes and evolved into a more complex and reliable application(s) in the project.

1.7

Initial Areas of Research

I hope to undertake an initial research (literature review) covering the following areas (apart from the ones already mentioned in the objectives): A. Concurrent Programming and its current trends, B. Relevance of concurrent programming in the IT industry, C. Visualisation and animation technologies, D. Technologies for developing the teaching tool, and E. Human computer interaction (HCI) issues.

1.8

Work Plan

This subsection identifies the anticipated workflow of the project along with expected completion dates. Each phase will have some overlap from other phases. For example, writing will take place during all phases although for illustrative purposes they are each listed as disjoint. I have given extensive consideration to the amount of work required to complete this project and have determined that although difficult this project can be completed in the allotted time of eleven weeks. This can be seen in the summary table ( Table 1) directly below or in the more comprehensive Gantt Project figure (Figure 3) below the table.

Milestone Analyse the project and do literary review Define the problem and write research proposal Gather data sources Design schema/structure Implementation of simulator Test application/ simulator & Gather results Write Dissertation based on Implementation Review of dissertation Present to Markers Submit dissertation paper

Estimated Time of Completion June 9 June 25 June 29 June 30 July 28 July 31 August 20 August 22 August 24 August 27

Table 1: Milestones and Time Estimation of Dissertation

Figure 3: Time Estimation of Dissertation (Designed Using Gantt Project 2012)

1.9

Outline of the Thesis

There are six (6) chapters covered in this dissertation. Chapter 1.0 introduces the major areas that this dissertation will be covering. Chapter 1.0 explains What the project is about, The reasons for this project, Aims, Objectives, Expected Achievements, Approach to the problem, and Initial Areas of Research in its subsections. This chapter provides a description of the Work Plan adopted by the author of this dissertation and finally introduces the Outline of the Thesis. Chapter 2.0 presents all the background research that the author of this dissertation has conducted as part of this dissertation. This chapter covers all the possible thematic areas in this academic exercise. These thematic areas are Concurrent Programming and Its Trends, Relevance of Concurrent Programming in the Information Technology Industry, Visualisation and Animation Technologies, Technologies for Developing the Teaching Tool and Human Computer Interaction (HCI) Issues. Chapter 3.0 contains the various activities that were undertaken to build the teaching tool. These are classified into the following sections: Approach Taken; which explains the projects requirements and specifications, design and the prototypes involved in the development, High-Level Explanation of the project, Testing process and the User Manual. Chapter 4.0 seeks to access the results of the project and evaluate their strengths and weaknesses. The author concludes the dissertation by providing a summary of the essential areas covered in the development of the project and during the writing of the dissertation in Chapter 5.0. Here, the author provides a brief description of how the original objectives are met. Some
6

recommendations are also made with regards to future developments of this or similar projects. All the academic resources that the author referred to during the development of the project, and writing this dissertation are all provided in Chapter 6.0. Chapter 7.0 shows the appendices.

2.0BACKGROUND RESEARCH
2.1 Literature Review

Thematic areas covered in this project are researched to ascertain all the available information that is relevant in this academic exercise. A background research has been undertaken in some areas that is considered thematic and hence, requires a thorough and detailed description to facilitate the distinct definition of the projects domain. These thematic areas are described below;

2.1.1

Concurrent Programming and Its Trends

The concept of concurrency has been a part of our lives in the things we do and observe in our environments. Snow (1992) reflects that the idea of different tasks being carried out at the same time, in order to achieve a particular end result more quickly, has been with us from time immemorial. Sometimes the tasks may be regarded as independent of one another. He provides an analogy of two gardeners; one planting potatoes and the other cutting lawn (provided the potatoes are not to be planted on the lawn!), will complete the two tasks in the time it takes to do just one of them. Sometimes the tasks are dependent upon each other, as in a team activity such as is found in a well-run hospital operating theatre. Here, each member of the team has to co-operate fully with the other members, but each member has his/her own well-defined task to carry out. [13] Computers also at various points in their operations execute tasks concurrently. The activity described by a computer program can also be sub divided into simpler activities, each described by a subprogram. In traditional sequential programs, these subprograms or procedures are executed one after the other in a fixed order determined by the program and its input. The execution of one procedure does not overlap in time with another. With concurrent programs, computational activities are permitted to overlap in time and the subprogram executions describing these activities proceed concurrently.[14] Concurrent program execution is usually made up of many programs or subprograms execution by one or more processors. A processor is capable of executing concurrent programs as it can interleave the instructions from multiple program executions[14] to simulate concurrency and hence, it creates an illusion of parallel execution. Concurrent programs can be executed on a single processor by interleaving the execution steps of each process in a time-slicing way, or can be executed in parallel by assigning each computational process to one of a set of processors that may be close or distributed across a network, as shown in Figure 4 below. The main challenges in designing concurrent programs are ensuring the correct sequencing of the interactions or communications between different computational executions, and coordinating access to resources that are shared among executions.[15] The execution of a program or a subprogram is referred to as a Process.

(From Hughes T. and Hughes C., 2003)[16]

Figure 4: Typical architecture for a parallel and distributed program.

Pure concurrency or parallel execution is achieved when multiple processors are used to execute instructions of concurrent processes at the same time. Such an activity is depicted as DISTRIBUTED APPLICATION in Figure 4 above. This project focuses on executions conducted by either one processor or dual cores (i.e. two processors). This is as a result of the fact that most computers available for teaching and learning concurrency programming in higher institutions mainly have a processor or dual cores. In a white paper published by Microsoft Corporation in 2007 which was titled THE MANYCORE SHIFT: Microsoft Parallel Computing Initiative Ushers Computing into the Next Era, provides a flashback on the advances made over the years with regards to concurrent or parallel computing. It said that the interest in parallel computing dates back to the late 1950s, with advancements surfacing in the form of supercomputers throughout the 60s and 70s. These were shared memory multiprocessors, with multiple processors working side-by-side on shared data. In the mid 1980s, a new kind of parallel computing was launched when the Caltech Concurrent Computation project built a supercomputer for scientific applications from 64 Intel 8086/8087 processors. This system showed that extreme performance could be achieved with mass market, off the shelf microprocessors. These massively parallel processors (MPPs) came to dominate the top end of computing, with the ASCI Red supercomputer computer in 1997 breaking the barrier of one trillion floating point
9

operations per second. Since then, MPPs have continued to grow in size and power. Today, parallel computing is becoming mainstream based on multi-core processors. Fortunately, the continued transistor scaling predicted by Moores Law will allow for a transition from a few cores to many [17]. Figure 5 below shows a summary of the generations of computing systems with their accompanying experiences and benefits to users.

(From Microsoft, 2007)[17]

Figure 5: Parallel computing and the next generation of user experiences.

2.1.2

Relevance of Concurrent Programming in the Information Technology Industry

Information Technology is currently indispensable in all facets of life, and every sector of the global economy is heavily dependent on it. The Global Information Technology Report states in its 2012 edition that in 2001, when the World Economic Forum first published The Global Information and Technology Report (GITR), the dot-com bubble had just burst; there were fewer than 20 million mobile phone users in all of Africa; and Apple Inc.s product line was confined to Macintosh computers. That Report presented an optimistic view of the future, highlighting the transformational potential of information and communication technologies (ICT) in advancing the progress of global society and business. Today there are more than 500 million mobile phone subscribers in Africa, and Apple is the worlds largest company in market capitalization, producing iPhones, iPods, and iPads along with Mac computers. Despite the strides the sector has made since the technology bust in 2001, however, we believe we are only just beginning to feel the impact of digitizationthe mass adoption by consumers, businesses, and governments of smart and connected information communication technology (ICT).[18]
This report is a good reflection of how the applications of Information Technology are quickly spreading all over the world. The Information Technology (IT) sector has been a leading driver

of economic growth in the modern world. As recent downturns have shown, a significant drop in the IT sector has widespread ramifications for all areas of our economy [19] . There
10

has been an increase of 25% in mobile phone subscribers in Africa in a period of eleven (11) years, and it is reported as only a beginning of the impact of digitization on consumers, businesses and governments. In the core of such fast paced development is the concept of concurrency or parallel computing. The

fate of much of the IT industry rests on the success of main-streaming parallel (or concurrent) computing [19]. Cameron Hughes and Tracey Hughes explain below the pivotal role of parallel computing in their book titled Parallel and Distributed Programming Using C++, and it is supported by Figure 1. Hughes (2003) says that programs that are properly designed to take advantage of parallelism can execute faster than their sequential counterparts, which is a market advantage. In other cases the speed is used to save lives. In such situations, faster means better. The solutions to certain problems are represented more naturally as a collection of simultaneously executing tasks. This is especially the case in many areas of scientific, mathematical, and artificial intelligence programming. This means that parallel programming techniques can save the software developer work in some situations by allowing the developer to directly implement data structures, algorithms, and heuristics developed by researchers. Specialized hardware can be exploited. For instance, in high-end multimedia programs the logic can be distributed to specialized processors for increased performance, such as specialized graphics chips, digital sound processors, and specialized math processors. These processors can usually be accessed simultaneously. Computers with MPP (Massively Parallel Processors) have hundreds, sometimes thousands of processors and can be used to solve problems that simply cannot realistically be solved using sequential methods. With MPP computers, its the combination of fast with pure brute force that makes the impossible possible. In this category would fall environmental modeling, space exploration, and several areas in biological research such as the Human Genome Project. Further parallel programming techniques open the door to certain software architectures that are specifically designed for parallel environments. For example, there are certain multiagent and blackboard architectures designed specifically for a parallel processor environment.[16]

2.1.3

Visualisation and Animation Technologies

Data has been represented in various forms either raw or processed as information to convey an idea or message. Information visualization takes us back to the earliest scratches of forms on rocks, to the development of pictoria as mnemonic devices in illuminated manuscripts, and to the earliest use of diagrams in the history of science and mathematics[20]. Visualisation is a process of utilising various techniques for creating images, diagrams, or animations to communicate a message. Visualisation made through visual imagery has been an effective way to communicate both abstract and concrete ideas since the beginning of human communication and representation. A good visualization clearly reveals structure within the data and thus can help the viewer to better identify patterns and detect outliers [21]. Historical examples include cave paintings, Egyptian hieroglyphs, Greek geometry, and Leonardo da Vinci's revolutionary methods of technical drawing for engineering and scientific purposes. The development of animation also helped advance visualisation. But, as used today, the term information visualization is generally applied to the visual representation of large-scale collections of non-numerical information, such as files and lines of code in software systems [22]. In software development, various visualisation and animation
11

technologies have been engineered and used to model simple but mostly complex processes. The current techniques used in visualisation are the multivariate visualisation techniques. In many multivariate visualization techniques, such as parallel coordinates [23, 24], glyphs [25], scatterplot matrices and pixel-oriented methods, dimensions are positioned in some one or two-dimensional (1-D or 2-D) arrangement on the screen. The introduction of 3Dimensional (3D) arrangement is largely a technical advance driven by whats possible, in advance of a full understanding of whats useful or appropriate. The hope is that 3D will overcome some of the limitations of 2D in terms of the number of attributes and types of relationships that can be visualized. It is an aspiration to find new metaphors to exploit the additional representational richness [26]. The three-dimensional (3-D) arrangement on the screen makes visualisation even better and very easy to identify the patterns in the visual representation. The organization of the dimensions can have a major impact on the expressiveness of the visualization. Different orderings of dimensions can reveal different aspects of the data and affect the perceived clutter and structure in the display. Thus completely different conclusions may be drawn based on each display [21]. The dimension used in this project is a simple one-dimensional (1-D) and pixel-oriented method or technique of visualisation.

2.1.4

Technologies for Developing the Teaching Tool

The technologies to be used to develop the teaching tool described in this dissertation involve Concurrency Programming, Java Programming Language and Libraries, Graphical User Interface design using Abstraction Windowing Toolkit (AWT) and Swing, and Event-Driven Programming. A. Concurrency Programming: Most software developers and programmers seem to endorse and embrace the concept of concurrency programming. Jason Zander, General Manager for Visual Studio, Microsoft talks of how critical concurrency programming is to writing successful software. He says that as chip designers run out of ways to make the individual chip faster, they have moved towards adding parallel compute capacity instead. Consumer personal computers (PCs) with multiple cores are now commonplace. We are at an inflection point where improved performance will no longer come from faster chips but rather from our ability as software developers to exploit concurrency. Understanding the concepts of concurrent programming and how to write concurrent code has therefore become a crucial part of writing successful software [27]. Concurrency is everywhere. No matter whether you are doing server-side programming for the web or cloud computing, building a responsive graphical user interface, or creating a new interactive client application that uses parallelism to attain better performance, concurrency is ever present [27]. Nonetheless, there are some challenges that this kind of programming faces. These are the increased complexity of concurrent programs and the well-known synchronisation problems of race conditions, deadlock and/or livelock. Threads within a concurrent program need to communicate with each other. Communication can be programmed primarily using either shared variables or by message passing. These activities results in two types of concurrency programming. With shared variables, each process can read or write values into variables that are also visible to the other processes. Also with message passing, processes communicate by sending messages to each other. These forms of
12

communication are extremely efficient, but make two kinds of errors possible: thread interference and memory consistency errors. The tool needed to prevent these errors is synchronization. Synchronization is a major foundation of concurrency programming. Synchronisation is used to restrict the possible interleaving of process executions. There are two kinds of synchronisation: i. Mutual Exclusion (Mutex) prevents certain statements in different processes from executing at the same time. The shared resource is accessed by at most one thread at any given time. The part(s) of the program in which the shared object is accessed is called critical section. Condition Synchronisation enables processes to delay their execution until a particular condition is true.

ii.

Appropriate use of synchronisation makes it possible to prevent interference by avoiding race conditions, deadlock and/or livelock. a. Race Condition is an incorrect behaviour of a concurrent program that arises as a result of a particular interleaving of its processes. Since the interleaving is arbitrary, the race condition does not occur on every execution. This makes concurrent programs difficult to debug. Concurrency programs should be designed to avoid any possibilities of race conditions. This requires some form of synchronisation between processes so they will not try to read-update-write a shared variable or data structure simultaneously. Find below a scenario illustrating an example of the effect of race condition. Scenario: George and Martha have a joint account containing $100 at Maxwell Bank. They each have an ATM (Automatic Teller Machine) card that allows them to check their account balance and to withdraw funds. One day, both George and Martha each decided that they needed $75. George conducted the following ATM transactions at 1:35PM:

At 1:48PM, Martha, at a different location, conducted this ATM transaction:

Martha then assumes that George withdrew money from the account. However, suppose George and Martha both arrive at two different ATMs at 1:35PM. They start their transactions:

13

At this point, Martha is puzzled because the ATM told her there was $100 in the account and she only asked for $75! This resulted from a race condition, where the transaction component that executed first did not block other transactions until the first set completed. Even worse, if the ATM software does not prevent certain race conditions, both George and Martha could each walk away with $75! Good for them, bad for the bank. b. Deadlocks occur in scenarios such as what is described below: Suppose there are two processes running on the same machine. The machine has 64 MB of memory and the following events occur: Process A allocates 30 MB. Process B allocates 30 MB. Process A tries to allocate another 8 MB and gets blocked by the kernel because the 8 MB are currently not available. Process B tries to allocate another 5 MB and gets blocked by the kernel because the 5 MB are currently not available. The two processes are deadlocked neither process can make any progress because it is waiting for the other process to release some resources. The processes are permanently idle. Deadlocks are caused by cyclic dependencies. They can be avoided by imposing the following rules on any resource allocation: i. No hold and wait: A thread may never wait for a resource while it is holding another resource. It may hold several resources, but it must request them all in a single operation. Pre-emption: In order to wait for a resource, a thread must first release all its resources and then re-acquire them. Resource ordering: Each resource type is assigned a number.

ii. iii.

The system can maintain a resource allocation graph and use it to detect when deadlocks occur. Deadlock recovery can be accomplished by terminating one or more threads involved in a deadlock. This is usually not done in the kernel, because the kernel has no idea what it is doing. Deadlock recovery is only implemented in critical applications such as real-time systems that need to keep working under all circumstances. In most applications, a deadlock indicates a design flaw and should be dealt with by fixing the code and recompiling.

14

The measures below will be employed by the author of this dissertation in the teaching tool to prevent such challenges and other possible challenges that may arise.

1. Bounded Buffers with Monitor Monitors are language features for concurrent programming. A monitor encapsulates data, which can only be observed and modified by monitor access procedures. Only a single access procedure may be active at a time. Monitors operate similarly as a class since they enclose a data structure that can only be accessed through a set of public operations or methods. Also, they guard against interference from concurrent threads by ensuring that each operation runs in a critical section, and allow threads to synchronise with each other using condition variables. [14] In the nutshell, Monitors implement data encapsulation, mutual exclusion and condition synchronisation. Monitors consist of a lock and one or more condition variables. If two threads attempt to execute methods of the object at the same time, one will be blocked until the other one is finished. Java example: class C { public synchronized foo() { // do something } } The synchronized Java keyword ensures the atomicity of the method; foos implementation. Inside a monitor, condition variables may be declared and used. A condition variable is an object with support for two operations: wait the calling thread blocks and releases the monitor; signal if there are any blocked threads (waiting), then unblock one of them; otherwise, do nothing. A thread being signalled does not automatically give back the monitor. The signalling thread first has to wait till the thread that currently has the monitor releases it. Bounded Buffer primarily is a set of a known number of memory locations declared to handle or contain data items without altering them. Bounded Buffer Monitors ensure that data items that are shared by multiple threads are guarded against any unauthorised alterations, allow changes from one thread at a given time, and block threads until a particular condition holds, such as a count becomes zero, a buffer becomes empty or a new input becomes available. A pseudo code of the implementation of a bounded buffer with Monitor is shown below: Item buffer[N]; int count;
15

Condition notfull, notempty; void produce(Item item) {// monitor method while (count == N) { wait(notfull); } buffer[count++] = item; signal(notempty); } Item consume() {// monitor method while (count == 0) {wait(notempty); } Item result = buffer[--count]; signal(notfull); return item; } The activities of the Bounded Buffer with Monitor check that the Ground Rules of Concurrency (Critical Section) are obeyed: c. Mutual Exclusion: At most one thread or process is at a time executing its critical section. d. Absence of Deadlock (Livelock): At least one of two or more threads competing to enter their critical sections succeeds. e. Absence of Unnecessary Delay: If a thread is trying to enter its critical section and other threads are executing their noncritical sections or have terminated, the first thread is not prevented from entering its critical section. f. Eventual Entry: A thread that is attempting to enter its critical section will eventually succeed. In other words, starvation is prevented. Synchronisation is ensured by the operations of Bounded Buffer with Monitors.

2.

Runnable Interface

Threads are created by the Thread class in most programming languages. In Java, the java.lang.Thread class is used to implement threads. New threads are created in Java by instantiating the Thread class and invoking its start method: Thread t = new Thread (...) t.start (); The run method determines the code that Thread t will run, and there are two ways of providing the run method. The first is to define a subclass of the Thread class and override the run method with the code for the new thread (Thread t): class Athread extends Thread { public void run () { //Put new threads code here }

16

} Thread t = new AThread (...) t.start (); The second is to pass an instance of a class that implements the Runnable interface to the Thread constructor: class Aclass implements Runnable { Public void run () { } } Aclass r = new Aclass (); Thread t = new Thread (r); t.start (); The option to execute threads using the Runnable interface affords processes or threads of being simpler and flexible. Threads that only override the run () method of the Thread class do not have to extend the entire class. Such processes can implement the Runnable interface. This means that all the other methods of the Thread class will not be added to the program. Also, processes that extend the Runnable interface can extend another class, whilst the processes extending the Thread class do not have the flexibility of extending another class. //Put new threads code here

B. Java Programming Language and Libraries: Programming is the process of designing and expressing in an appropriate language, a set of instructions to solve a particular task, that a machine will obey somtime later, whenever that task is needed to be done [28]. A programming language is an artificial language designed to communicate instructions to a machine, particularly a computer. Programming languages can be used to create programs that control the behavior of a machine and/or to express algorithms precisely. They are usually classified as Logical, Functional, Imperative, Concurrent and Object-Oriented. Some examples of programming languages are COBOL, FORTRAN, C, C++, Java, C#, Python, Lisp, etc. Most programming languages perform best in certain environments and in some conditions. There are some that perform well in almost all situations. In languages such as C and C++, the compiler directly translates the source code into the machine language of your computers central processing unit (CPU). For such languages, a different compiler is needed for each type of CPU. Therefore, programs in these languages are not easily portable from one type of machine to another type of machine. The source code must be recompiled for each type of CPU. To make Java programs machine independent and easily portable, as well as run on a web browser, the designers of the Java language introduced the Java Virtual Machine (JVM) and bytecode as the (machine)
17

language of this machine. It is easier to translate a bytecode into a particular type of CPU [29]. Java is an object-oriented language that is receiving wide attention from both industry and academia. Java was developed by James Goosling and his team at Sun Microsystems in California. The language was based on C and C++ and was originally intended for writing programs that control consumer appliances such as toasters, microwave ovens, and others. The language was first called Oak, named after the oak tree outside of Gooslings office, but the name was already taken, so the team renamed it Java. Java is chosen for this project because of its porpularity as shown in Table 2 below, and its clean design. The language designers of Java took a minimalist approach; they included only features that are indispensable and eliminated features that they considered excessive or redundant. This minimalist approach makes Java a much easier language to learn than other object-oriented programming languages. Java is an ideal vehicle for teaching the fundamentals of objectoriented programming. [30]

(Adapted from TIOBE Software Company, 2012)[31]

Table 2: TIOBE Programming Community Index for July 2012 (Programming Languages Popularity)

C. Graphical User Interface design using Abstraction Windowing Toolkit (AWT) and Swing: Earlier, computers were controlled by commands. The interaction paradigm was based on a control language; users entered commands and respective arguments on the line following the (invariably) blinking cursor [32]. Some current applications such as the Microsoft Windows Command Prompt, the UNIX and Linux shells are instructed by the user through the command line interface (CLI). The major challenge faced by the CLI is the fact that it
18

required a high level of memorization and familiarity needed to operate it; new users have a difficult time navigating and operating a command line interface. Also, although many command line environments are capable of multitasking, they do not offer an appreciable amount of ease and ability to view multiple things at once on one screen. Then graphical user interfaces (GUI) appeared, replacing arbitrary memorized commands with direct manipulation, where actions are performed by moving objects on the screen and selecting from menu displays. GUI has served us well, replacing the need to memorize complex instructions with the ease of selecting from the visible items on the screen [32]. Java provides extensive support for GUI programming. A significant number of classes, from the Java application program interface (API), are dedicated to providing parts of GUIs or supporting them. Programs with a graphical user interface in Java use the Java Swing system, which is built on top of the older Abstract Windowing Toolkit (AWT). These consist of a number of standard classes offering GUI features, from which we make instances and plug them together to make GUIs for our programs. These standard classes are grouped into packages; the java.awt and javax.swing. Java programs that provide a GUI typically need to use classes from both of these packages.[28]

(Adapted from Reddy 2008)[33]

Figure 6: Java AWT, Swing and Applet Components Hierarchy

Figure 6 above provides an overview of the hierarchy and structure of the components of Java Lang, AWT, Swing and Applet.
19

D. Event-Driven Programming: The flow of control in a sequential program is the order in which statements are executed. In traditional sequential programming, the programmer determines the flow of control. On the other hand, the flow of control in event driven programming is determined by external events. The program responds to each event in a predictable manner, but has no control over the order in which events occur. This event-driven style of programming is very commonly used in constructing graphical user interfaces (GUIs). This is largely to facilitate interactivity. In Java, the AWT's paint methods are an example of this kind of event-driven programming. The execution of an event driven program is controlled by some external software, which is responsible for detecting events and reporting them to the event driven program. Usually, events are generated by sources such as mouse, keyboard, etc. that are external to the event driven program, and are monitored by the external software. The process of reporting an event to an event driven program is called event dispatching. An event handler is the code that an event driven program executes when it receives an event. The relationship that exits between events, event dispatcher and event handlers are depicted in Figure 7 below.

Figure 7: An Overview of the Relationship between Events, Event Dispatcher and Event Handlers

2.1.5

Human Computer Interaction (HCI) Issues

The software to be developed is expected to provide an avenue for interactivity with users. It is then expected to have some features and characteristics that will facilitate a two-way communication with its human users. Computers with their various types of software (system or application) do exactly what they are told, provided their optimal or basic requirements are met. The only challenge is that, the instructor (external) will use an appropriate channel to submit the right instructions. This situation has led to the creation of the concept of Human Computer Interaction (HCI). HCI Human Computer Interaction is a science which study on the design, evaluation and implementation for the use of interactive computing systems [34]. The research of HCI includes human-computer interface design, but not limited to interface design. Human-computer interface design is not a simple art design, which is designed not only to use beautiful view, bright in color, more important to adapt to people's cognitive psychology, and with good human-computer interaction function. The research of cognitive psychology is an important embodiment of people-oriented design strategy. The past design
20

emphasis on "what technology to solve problems," however, the people-oriented design emphasis on "what are the user needs".[34] The design of human-computer interface can be approximately divided into three parts: structure design, interactive design and visual design, which cross and interact through each other and cannot be lost. These parts can be evaluated using Dixons W6 Evaluation System for website interfaces. This system seeks to obtain answers to the following questions: i. ii. iii. iv. v. vi. Why do we need the system? Who will access the system? Where will it be executed? When will users use the system? What are the users looking for? How can they access the system?

Also, the ten usability heuristics for user interface design proposed by Nielsen (1994) can be used to evaluate the applications user interface [35]. They are called heuristics because they are more in the nature of rules of thumb than specific usability guidelines. The heuristics are listed below: i. ii. iii. iv. v. vi. vii. viii. ix. x. Visibility of system status. Match between system and the real world. User control and freedom. Consistency and standards. Error prevention. Recognition rather than recall. Flexibility and efficiency of use. Aesthetic and minimalist design. Help users recognise, diagnose, and recover from errors. Help and documentation.

2.2

Earlier Work Done In This Area

Animation of synchronisation problems in concurrency programming has been attempted at various points in time. In Hughes and Buckleys description of Algorithm Animation Tools, they agree with Kreamer that most tools that have been created as concurrent program comprehension tools are algorithm animators [36, 37]. Algorithm Animation systems provide highly application-specific views of a programs data structures, the operations which update these data structures, abstract representation of the computation and its progress [37]. Alternatively, Stasko defines algorithm animation as the process of abstracting a programs data, operations, and semantics, and creating dynamic graphical views of those abstractions [38]. Algorithm animation systems provide facilities for users to view and interact with an animated display of an algorithm [39]. The main use and reason for the development of algorithm animations was to be used as teaching aids to help explain how specific algorithms work [40]. The best-known algorithm animation system and the pioneer for algorithm animation is Balsa [41], and its descendant Balsa-II [42]. Balsas approach to animating algorithms is for a programmer to annotate the algorithm with markers that identify the fundamental operations to be displayed.[36]

21

This projects attention is mostly drawn towards current animations and simulations such as the works of Magee and Kramer [43] and Stallings [44]. These mentioned works are serving as major reference points for concurrency problems animation by academia. This is evident in the Best Computer Science and Engineering textbook awards given to three editions (sixth edition, 2009; fourth edition, 2002; third edition, 1998) of Stallings books awarded by the Text and Academic Authors Association [45, 46]. Also, Magee and Kramer were jointly awarded the ACM SIGSOFT Outstanding Research Award for the year 2005. This award is presented to an individual or individuals who have made significant and lasting research contributions to the theory or practice of software engineering [47]. The author will assess Magee and Kramers work in relation to this project since it greatly influences the development of the authors project. This choice is largely dependent on the fact that Magee and Kramers work is much simpler to understand the implementations, and it also has a simpler user interface. Magee and Kramer; like many developers of algorithm animation tools for teaching have all used Java Applets instead of creating stand-alone applications. Java Applets provide convenient libraries such as Graphics, Graphics2D, etc. to develop rich animations. They also made good use of easily identifiable colours to represent the states of their threads; red to represent termination and green to represent running. The buffer representations were quite understandable as the contents (alphabets) of the individual buffers were displayed, and coloured circles are assigned to buffers that were being operated on. The author will develop the project in a similar manner as that of Magee and Kramers works on the Producer/Consumer and Reader/Writer problems. The main difference is that the author prefers to develop a stand-alone application as to the applets developed by Magee and Kramer. Current applets are heavily dependent on the installation of Java 2 Platform Standard Edition (version 1.5.0 or later) on their target machines to be able to execute. This situation limits the number of computers that can be used to execute the applets. Even though most of the web browsers (Internet Explorer, Netscape, HotJava, Firefox 1.0.4, Mozilla 1.6, etc.) are Java compatible, there are still versions of browsers such as Internet Explorer versions 1.0, 2.0 and 3.0 that are not Java-enabled. Some browsers also require Java plugins to be able to render some web pages. On the other hand, Java applications are built to be independent of such restrictions. Java applications can run on Windows operating systems such as Windows XP, Windows Vista and Windows 7, and Mac OS. Also, the author will use appropriate text to support the colours that indicate the states of the threads. This addition enhances the understanding of the implementations. Again, the user interface will be made bigger than that of Magee and Kramer to afford users clarity and easy access to the information the application provides. Lastly, a user manual will be provided in the application. This is to provide more information to the user in the use of the application. It will be convenient to use as it is readily available.

22

3.0BUILDING THE TEACHING TOOL

The various activities that occurred in the development of this project are described in the subsections below. 3.1 Approach Taken In Chapter 1, the evolutionary prototyping model was decided upon as a method of developing a solution to the synchronisation problems and as a means of making progress with the unfamiliar concept of animation, and connection of the solutions to the animations to be developed. Such a situation requires that some of the steps taken in the evolution from simple working programs into a more complex final solution need to be explained. That is the purpose of this section, which leads to the high-level explanation of the final solution in section 3.2. Figure 8 presents an overview of an evolutionary prototyping technique.

Figure 8: Overview of Evolutionary Prototyping Technique

A prototype is a working model of a part or all of the final system. It may not be dependable (inefficient and not secure), or may have less functionalities. There are two types of prototyping process models: A. Throw-away prototyping: This is used to elicit and clarify the system requirements, and starts with poorly understood requirements. B. Evolutionary prototyping: This involves working with customers and evolving a final system from an initial outline specification. It may start with well understood requirements.

23

The evolutionary prototyping model best suits the development of this project as the model is flexible to accept various changes at various times in the development process, as required by the customer (Supervisor). The projects prototyping overview depicted by Figure 8 shows the interleaving of the specification and development, and the evolution of the three prototypes of this project. This situation sets a stage for incremental delivery of prototype according to the customers requirements or specifications.

3.1.1

Project Design

The choice of an evolutionary prototyping development model made it quite challenging to produce a comprehensive design at the beginning of the project as the entire picture of the project was not fully known. The uncertainties about the technology to be used to develop the animation, and the appropriate processes to be used for the development played major roles in fully ascertaining the structure of the design of the system to be developed. As a result of the uncertainties surrounding the development of the animation of this project, an initial research was conducted into relevant and existing teaching simulations. This exercise resulted in the discovery of some work by Magee and Kramer[14] on the simulation of the Producer/Consumer problem. The simulator combined easily understandable colours and appropriate animation for the buffer representation. The Producer/Consumer problem animation on the other hand, was not easily understandable even though there were movements to indicate that a thread was running. The simulator gave an idea of how the user interface for such a simulator may look like. Magee and Kramers work largely influenced the design of this project. The interface of Magee and Kramers work is shown in Figure 9 below.

Figure 9: Bounded Buffer Demonstration of the Producer/Consumer Solution by Magee and Kramer (2006) [14]

The design requirements (functional and non-functional) that were considered before the software was developed further are as listed below in Table 3.
24

DESIGN REQUIREMENTS The software should be written in Java so that it is downloadable and executable on a range of platforms including Windows operating systems such as Windows 7, Windows Vista and Windows XP, and Mac OS X. The Graphical User Interface (GUI) should be usable on a range of different screen resolutions ranging from 800 x 600 pixels and 1200 x 800 pixels. To improve efficiency and enhance convenience of project development, an editor which has a Java editing tool as well as an up to date tool for developing animations should be used. The application should take the form of a teaching tool. The teaching tool should simplify the demonstration of some synchronisation problems in concurrency programming. User guide should be readily available to the user on the various interfaces of the application. Commanding tools such as command buttons and option buttons should be easily identifiable by the users. The application should be able to accept user commands as key-press inputs. Distinctive colours should be used to represent the states of the threads in the application. The application should be able to accurately represent the solutions of the synchronisation problems under review. There should be an option to exit the application.

R1

R2

R3 R4 R5 R6 R7 R8 R9 R10 R11

Table 3: Design Requirements of Project

The software design stage is expected to translate specifications and requirements into solutions. It is the first breakdown of specifications and requirements moving towards implementable pieces.

3.1.2

Synchronisation Problems (Prototype 1)

An initial prototype was developed to solve the well-known synchronisation problems of Producer/Consumer and Reader/Writer. The two programs were written earlier on in the development of the project and were successful in demonstrating both synchronised and
25

unsynchronised implementation of the two problems named above. The programs generate random integers in the range of 0 to 99 that are then saved in Number objects. This is shown in Figure 10 below.

//Generate RANDOM number Number num = (int) (Math.random ()*100); //Put RANDOM number into the SHARED BUFFER buffer.put (num);

Figure 10: Code Snippet of Random Integer Generation and Storage in Buffer of Numbers The Number objects are shared by all the participating threads in the respective programs and the objects are grouped as a collection in Bounded Buffer Monitors.Figure 11 below shows the declaration of a buffer monitor with some selected sections of a class in one of the programs.
protected E[] buffer; //Constructor public BufferImplementation (int size) { buffer = (E[]) new Object [size]; { @Override public void put (E o) throws InterruptedException { //Critical Section pcLock.lock (); try { while (count == buffer.length) pcNotFull.await (); buffer [in] = o; ++count; in = (in+1) % size; } finally { pcLock.unlock(); } }

Figure 11: Code Snippet of Bounded Buffer Monitor (buffer) in the BufferImplementation Method

26

A. Producer/Consumer Implementation When two threads (Producer and Consumer) need to communicate through a shared message object and the Producer thread repeatedly generates new messages that are consumed by the Consumer thread. However, the Producer thread cannot produce the next message until the previous message has been consumed by the Consumer thread. In this case, the Producer and Consumer threads have exclusive access to the bounded buffers and can update the Numbers in the bounded buffers. The two types of threads are required to synchronise or interleave by signaling each other at appropriate point during their execution. The author of this dissertation will attempt to solve the Producer/Consumer problem described above. i. Version 1 of Solution

A challenge that was first faced during the implementation of the synchronised version of the Producer/Consumer problem was that the output of a Consumer threads consumption of a Number in the buffer sometimes precedes the production of that same Number in the buffer by a Producer thread. Such occurrence is shown in Figure 12 below with the problem areas marked with red.
run:

0 milliseconds - Main starts: **************************************************************** (Num) AGE of THREAD | PRODUCER | CONSUMER

**************************************************************** (1) 3 milliseconds | P1(15) | C1(15) Consumer @ 1 consumed: 15 Producer @ 1 produced: 15 C2(47) (2) 3 milliseconds | P2(47) |

Consumer @ 2 consumed: 47 Producer @ 2 produced: 47 (3) 4 milliseconds | P3(23) | C3(23) Producer @ 3 produced: 23 Consumer @ 3 consumed: 23 BUILD SUCCESSFUL (total time: 0 seconds)

Figure 12: Output of Synchronised Producer/Consumer Solution with Printing Anomaly

27

The Consumer thread; C2 is seen at step (2) to consume the Number (47) in the buffer before the Producer thread; P2 produces the random Number (47) into the buffer. At this stage, one Producer thread and one Consumer thread were declared to start in the main() method. Such outputs may raise lots of questions in the mind of students. The problem mentioned above is as a result of the arbitrary interleaving of Producer and Consumer threads with more emphasis on the message output code that contains System.out.print (); and System.out.println ();statements and the atomic execution of the put () and get () methods in the BufferImplementation<E> class.

//Critical Section synchronized(this) { while (available == true) wait();

Number num = (int)(Math.random()*100);

//Put RANDOM number into the SHARED BUFFER buffer.put(num); System.out.println("");

//Display RANDOM number generated by the PRODUCER System.out.println("("+ loop+") "+BufferImplementation.age() milliseconds"+ c + a+"P"+loop+"(" + num + ")" + b); + "

System.out.println(" produced: "+ num); available = true; notifyAll(); }

Producer @ " + loop + "

Figure 13: Code Snippet of the Run () Method in the Producer Class with Printing Statements

28

//Critical Section synchronized(this) { while (available == false) wait();

//Get RANDOM number from the SHARED BUFFER buffer.get(num); System.out.println("");

//Display RANDOM number generated by the CONSUMER System.out.println("("+ loop+") "+BufferImplementation.age() milliseconds"+ d+"P"+loop+"(" + num + ")" + b); + "

System.out.println(" available = true; notifyAll(); }

Consumer @ " + loop + " consumed: "+ num);

Figure 14: Code Snippet of the run () Method in the Consumer Class with Printing Statements

Printing (System.out.print (); or System.out.println ();) is a different action or operation performed on a threads message, which can be arbitrary. In such a case shown in Figure 13 and Figure 14, the Producer thread can produce a random Number before a Consumer thread consumes that Number but during execution of the printing statement(s), the consumption of the Number can be printed first before the production of that same Number. Irrespective of the occurrence of this situation, the atomicity and synchronisation of the Producer and Consumer threads with their corresponding put() and get() methods are still operating efficiently but the problem is as a result of the arbitrary interleaving of the threads and the output statements. The solution applied to correcting the anomaly in the printing of the results was to: a. Remove the printing statements form the run methods of the Producer and Consumer classes and add them to the put() and get() methods respectively in the BufferImplementation<E> class. The reason is to make the respective printing statements available to the Producer and Consumer threads whenever they enter their critical sections which are atomic. b. Remove the synchronized keywords bordering the codes in Figure 13 of the Producer class and Figure 14 of the Consumer class above. The keywords were no relevant as the put() and get() methods were atomic.

29

The figures (Figure 15 and Figure 16) below shows the printing statements in the put() and get() methods in the BufferImplementation<E> class.

//Critical Section synchronized(this) { while (available == true) wait(); buffer[in] = o; ++count; in=(in+1)%size; System.out.println("");

//Display RANDOM number generated by the PRODUCER System.out.println("("+Producer.loop+")" BufferImplementation.age() + " milliseconds"+"(" + o + ")" ); +

System.out.print(b+"| P"+Thread.currentThread().getId()+"(" + o + ")" +c+" \n"); System.out.println(b+ "Producer"+Thread.currentThread().getId() produced: "+ o); +" @ " + Producer.loop +"

available = true; notifyAll(); }

Figure 15: Code Snippet of the put () Method in BufferImplementation<E> Class with Printing Statements

30

//Critical Section synchronized(this) { while (available == false) wait(); E o = buffer[out]; buffer[out] = null; --count; out = (out + 1) % size; System.out.println("");

//Display RANDOM number generated by the CONSUMER System.out.println("("+Consumer.loop+")" BufferImplementation.age() + " milliseconds"+"(" + o + ")" ); System.out.print(a+"| ")" +c+" \n"); C"+Thread.currentThread().getId()+"(" + o + +

System.out.println(a+ "Consumer"+Thread.currentThread().getId() +" @ " + Consumer.loop +" consumed: "+ o);

available = false; notifyAll(); return (o); }

Figure 16: Code Snippet of the get () Method in BufferImplementation<E> Class with Printing Statements

The output obtained as a result of implementing the above mentioned solutions to the printing problem is shown in Figure 17 below.

31

run:

0 milliseconds - Main starts:

**************************************************************** (Num) AGE of THREAD | PRODUCER | CONSUMER

****************************************************************

(1)3 milliseconds(91) | P9(91) |

Producer9 @ 1 produced: 91 | Consumer12 @ 1 consumed: 91 C12(91)

(2)3 milliseconds(66) | P10(66) |

Producer10 @ 2 produced: 66 | Consumer12 @ 2 consumed: 66 C12(66)

(3)3 milliseconds(0) | P9(0) |

Producer9 @ 3 produced: 0 | Consumer11 @ 3 consumed: 0 C11(0)

BUILD SUCCESSFUL (total time: 0 seconds)

Figure 17: Output of Resolved Printing Anomaly

32

ii.

Version 2 of Solution

The two programs developed in this version of the first prototype are able to demonstrate synchronised and unsynchronised behaviours of threads in a textual format. Users have an option of choosing to run a synchronised implementation by typing 1, 2 to run an unsynchronised implementation or Q to exit the program. Also, locks (java.util.concurrent.locks.Condition, java.util.concurrent.locks.Lock and java.util.concurrent.locks.ReentrantLock) and signals (await(), signal() and signalAll()) were used in this solution to ensure synchronisation. Figure 18 below shows the textual interface of Prototype 1 where users are expected to enter an option to run their desired implementation of the two programs.

Figure 18: User Implementation Options in Version 2 of Prototype 1

I. Synchronised Solution In this solution, Producer and Consumer threads are expected to interleave during their executions. The Consumer thread is expected to consume a previous Number object in the buffer produced by a Producer thread, before another Number object is produced to replace the previous object in the buffer [48]. In this activity, three buffers with monitor are created to contain the Number objects. Also, two instances for each of the Producer and Consumer classes were created. A synchronised implementation of the Producer/Consumer problem is shown in a textual format in Figure 19 below.

33

Figure 19: Textual Output of Synchronised Implementation of the Producer/Consumer Problem

In the output above, synchronisation is ensured, as Producer 1; P1 produces Number 92 and the object is then consumed by Consumer 2; C2. Also, Producer 2; P2 produces Number 69 and the object is then consumed by Consumer 1; C1. All these threads interleave with one another. II. Unsynchronised Solution

In this solution, Producer and Consumer threads are expected not to interleave at some sections during their executions. Also, the Consumer thread may re-consume a previous Number object in the buffer produced by a Producer thread that has already been consumed by a Consumer thread as shown in Figure 20 below. Again, the Consumer thread may not consume a previous Number object in the buffer produced by a Producer thread, before another Number object is produced to replace the previous object in the buffer.

34

Figure 20: Textual Output Producer/Consumer Problem

of

Unsynchronised

Implementation

of

the

In Figure 20 above, Producer (P2) produces Number (82) and it is comsumed by Consumer (C2). At step (4), Consumer (C1) consumes Number (82) again. Such an action is exhibited by an unsynchronised operations of competing threads over a shared buffer.

B. Reader/Writer Implementation Mutex objects such as monitors provide mutually exclusive access to a shared resource. But sometimes complete mutual exclusion is unnecessarily restrictive. If two threads are only interested in reading a shared resource, it should be possible to allow both to access the resource at the same time. If neither thread tries to modify the resource, the resource will never be in an inconsistent state and simultaneous access is safe. Indeed, it is common for there to be multiple threads trying to read a shared resource where updates to that resource are uncommon. To support this usage, bounded buffer with Monitor and locks are used. Multiple Readers can lock such an object without blocking each other, but when a single Writer acquires the lock it has exclusive access to the resource. All the following Readers or Writers will block as long as a Writer holds the lock.

35

I.

Synchronised Solution

********************************************************************************** AGE of THREAD | WRITER (1) | WRITER (2) | READER (1) | READER (2)

**********************************************************************************

14019 milliseconds(88) | W2(88) |

Writer2 @ 1 wrote: 88

14020 milliseconds(81) | W2(81) |

Writer2 @ 1 wrote: 81

| 14021 milliseconds(88)

| 14022 milliseconds(81)

R2(88)

Reader2 @ 1 read: 88

| | R2(81) |

Reader2 @ 2 read: 81

| 14022 milliseconds(null)

R2(null)

Reader2 @ 3 read: null

| 14022 milliseconds(81)

R2(81)

Reader2 @ 4 read: 81

Figure 21: Textual Output of Synchronised Implementation of the Reader/Writer Problem (A)
36

Synchronised implementation of the Reader/Writer Solution is demonstrated in Figure 21 above. Here, when Writer (W2) acquired the lock at 14020 milliseconds, it had an exclusive access to the database and was able to write into it. During this period, all other Writer threads and Reader threads especially Reader (R2) threads were blocked. Also, it is observed in Figure 21 that the last Reader (R2) at 14022 milliseconds read the Number (81) that was earlier read by the second Reader (R2) at 14022 milliseconds. This shows that the Reader threads only read the Numbers in the buffers and not update them.

Figure 22: Textual Output of Synchronised Implementation of the Reader/Writer Problem (B)

Figure 22 above also represents a textual output of a synchronised implementation of the Reader/Writer Problem.

37

II.

Unsynchronised Solution

Depending on the implementation, a steady stream of Readers might permanently lock out a Writer. This situation is called Writer starvation. On the other hand if the implementation favours Writers in the sense of letting waiting Writers obtain the lock as soon as possible, Reader starvation may occur. Unsynchronised implementation of the Reader/Writer can occur when two or more Writers write at the same time or a Reader reading while a Writer is writing. Figure 23 below shows two Writers writing at the same time (188451 milliseconds) and two Readers reading at the same time (188452 milliseconds).

Figure 23: Textual Output of Unsynchronised Implementation of the Reader/Writer Problem

3.1.3

Graphical User Interface Attempt (Prototype 2)

Prototype 2 attempts to design a graphical user interface (GUI) to represent and animate the Producer/Consumer and Reader/Writer solutions achieved in Prototype 1 above. The major technologies employed here are the java.awt (Abstraction Windowing Toolkit - AWT) and the javax.swing (Swing) packages in the Java library described earlier in Chapter 2.0 subsection 2.1.4. Other specific Java events packages such as java.awt.event.ActionEvent (Action Event) and
38

java.awt.event.ActionListener (Action Listener) were also employed. The Event library was involved because of the critical role it plays in facilitating interactivity with users. The Figure 24 below shows the packages imported in this prototype.

Figure 24: Imported Packages used in Prototype 2

Since all the codes are provided in the Appendices in Chapter 7.0, references will mostly be made to appropriate codes when they are required in the dissertation. The author identified that the GUI should have three major sections; a section for notes about the problems, a section for the animation, and a section for the user interaction tools. Below is Figure 25 showing the interface created in prototype 2.

Figure 25: Prototype 2 Graphic User Interface

39

3.1.4

Final Project (Prototype 3)

The final prototype combines the information gathered about the solutions for the Producer/Consumer and Reader/Writer problems from the initial prototypes. All the technologies used in prototype 1 and prototype 2 are employed in the development of this prototype. The additions are the use of the NetBeans IDE 7.1.2 Java GUI Builder, the introduction of JDialog, JMenuBar, JMenu, JPanels, JTextArea, JTextFields, JButtons, and JRadioButton from the Swing package, introduction of colours and texts to represent the states of the threads, and the representation of the three bounded buffers. Also the javax.swing.Timer (Timer) package is used to set appropriate colours for the threads after every 100 milliseconds. Figure 26, Figure 27, Figure 28, and Figure 29 below represent the Graphic User Interfaces (GUIs) for Synchronised Producer/Consumer Implementation, Unsynchronised Producer/Consumer Implementation, Synchronised Reader/Writer Implementation and Unsynchronised Reader/Writer Implementation respectively. Also, colours used are described below: Green represents a running thread. Yellow represents a waiting thread. Red represents a terminated or stopped thread.

40

Figure 26: Prototype 3 Graphic User Interface for Synchronised Producer/Consumer Implementation

41

Figure 27: Prototype 3 Graphic User Interface for Unsynchronised Producer/Consumer Implementation

42

Figure 28: Prototype 3 Graphic User Interface for Synchronised Reader/Writer Implementation

43

Figure 29: Prototype 3 Graphic User Interface for Unsynchronised Reader/Writer Implementation

3.2

High-Level Explanation

High level software design, also called software architecture is the first step to analyse and consider all requirements for a software and attempt to define a structure which is able to fulfil them. Design and specification languages such as unified modelling languages (UML) are higher level languages than the traditional high level (HL) programming languages. They allow software engineers to produce and analyse system models at early development stages, before the commitment is made to code. Some UMLs (Class Diagrams) are used to provide an overview of the groups of classes considered by the author in the project development.

44

3.2.1

Java Classes Overview

Detailed Java Docummentation (Javadocs) outlining the purpose, constructor details and the methods of all of the Java classes used in this project have been included, together with commented Java code listings in the appendix. It is not necessary therefore; to give detailed explanation of the structure and operations of all these classes here; however, an overview of the system and some reasons explaining why they were constructed in this manner will be given. The Java classes are essentially facilitating synchronised or unsynchronised communication between various Java objects. A. Producer/Consumer Solution Class Diagram

Figure 30: Producer/Consumer Solution Class Diagram

In Figure 30, a conceptual class diagram showing all the classes (Producer, Consumer, Project, Buffer, BufferImplementation, UnsyncBufferImplementation) that were developed to solve the Producer/Consumer problem in Prototype 1 is depicted. i. Producer and Consumer classes define the central threads of the program. The two classes Override the run () method as they implement the Runnable class, and they perform the Number production and consumption processes as appropriate. The BufferImplementation and UnsyncBufferImplementation classes define behaviours such as put() and get() that determine the

ii.

45

iii.

iv.

synchronised or unsynchronised nature of the Producer and Consumer threads. An interface class named Buffer is created to provide access to external classes or objects through the public methods of the BufferImplementation and UncyncBufferImplementation classes. The Project class executes the implementations of the composing classes in the above mentioned solution. This is as a result of the fact that, it contains the main () method and the java.util.Scanner (Scanner) library which facilitates user interraction by alerting users to choose either to implement a synchronised or unsynchronised solution of the Producer/Consumer problem.

B. Reader/Writer Solution Class Diagram

Figure 31: Reader/Writer Solution Class Diagram

Above in Figure 31, is a conceptual class diagram showing all the classes (Writer, Reader, ProjectRW, ReadWrite, ReadWriteImplementation, UnsyncReadWriteImplementation) that were developed to solve the Reader/Writer problem in Prototype 1. i. Writer and Reader classes here also define the central threads of the program mentioned above. The two classes Override the run () method as they implement the Runnable class, and they perform the Number writing and reading processes as appropriate. Unlike the Producer and
46

ii.

iii.

iv.

Consumer threads which both update the Numbers in the buffer, the Writer thread is the only thread that can update Numbers in the buffer. The ReadWriteImplementation and UnsyncReadWriteImplementation classes define behaviours such as write(), request_write(), release_write(), read(), request_read(), and release_read() that determine the synchronised or unsynchronised nature of the Writer and Reader threads. An interface class named ReadWrite is created to provide access to external classes or objects through the public methods of the ReadWriteImplementation and UnsyncReadWriteImplementation classes. The ProjectRW class executes the implementations of the composing classes in the Reader/Writer solution. This is as a result of the fact that, it contains the main () method and the java.util.Scanner (Scanner) library which facilitates user interraction by alerting users to choose either to implement a synchronised or unsynchronised solution of the Reader/Writer problem.

3.2.2

System Overview

The final system in developed in Prototype 3 combines the solutions obtained in Prototype 1 and the ideas gathered from the design of the graphical user interface during the development of Prototype 2. Below are the classes that made up the final system shown in Figure 32 and Figure 33: i. ii. iii. iv. v. vi. vii. viii. ix. x. xi. ProducerConsumer_Dialog Buffer ReadWrite BufferImplementation UnsyncBufferImplemantation ReadWriteImplementation UnsyncReadWriteImplementation Producer Consumer Writer Reader

47

Figure 32: Conceptual Class Diagram showing an Overview of the System in Prototype 3 (A)

48

Figure 33: Conceptual Class Diagram showing an Overview of the System in Prototype 3 (B)

49

As part of the system, the ProducerConsumer_Dialog class makes use of other important libraries; the class implements the ActionListener class and also extends the javax.swing.JDialog (JDialog). This is shown in Figure 34 below.

Figure 34: Conceptual Class Diagram showing an Overview of the Relationship between the ProducerConsumer_Dialog Class, the ActionListener and the JDialog Libraries 3.3 Testing

Pressman (2010) defines software testing as the process of exercising a program with the specific intent of finding errors prior to delivery to the end user [49]. Evolutionary prototyping software development model requires that a lot of effort is put in testing the project at every stage in all prototypes. All iterations in the development cycle required testing. Although the author was not able to produce a formal testing plan at the beginning of the project as a result of its complexity, appropriate unit tests were conducted at various stages to ensure that the program was behaving as expected at each stage before other functionalities are added.[50] The two major challenges that were faced during testing was the complexity of concurrency that required a high level of attention and accuracy, and the fact that the author was new to animation. The system was modularised into subprograms where every step added was tested and the author read and practiced further on animation during the period of the project. These steps taken by the author of this dissertation ensured that the above mentioned challenges
50

were minimised. Even though the breaking down of the system into smaller modules took a lot of time and effort, the project was realised to have no apparent faults.

Figure 35: Use Case Diagram of Project

The use case above represented in Figure 35 can be summarised as shown below: A. Systems: i. User ii. Producer/Consumer Solution iii. Reader/Writer Solution B. Activities: i. Read User Manual ii. Run Synchronised Implementation iii. Run Unsynchronised Implementation iv. Pause Implementation v. Exit Application A use case is a description of typical interaction between the system and entities external to it. The use case diagram provided above in Figure 35 is used to complement the testing
51

process with regards to user interaction with the application. Table 4 below shows an overview of the activities undertaking when conducting the unit, integration and system tests of this project. The above mentioned tests were mainly conducted by inspection and by the compiling and interpreting processes of the Java editor (NetBeans IDE 7.1.2).

CHECKS CONDUCTED DURING TESTING 1 That Prototype 1 would implement both synchronised and unsynchronised solutions to the Producer/Consumer and Reader/Writer problems. That Prototype 2 would show the three important sections (a section for notes about the problems, a section for the animation, a section for the user interaction tools) of the graphic user interface (GUI). That Prototype 3 would present a simple and informative GUI to the user. That the graphical user interface (GUI) for Prototype 3 would display correctly at different screen resolutions ranging from 800 x 600 pixels to 1200 x 800 pixels. That the RUN command button works as required. That the PAUSE command button works as required. That the Unsynchronize option button works as required. That the EXIT command button works as required. That the User Manual provided enough information to the user.

3 4

5 6 7 8 9

Table 4: Checks Conducted during System Testing

The testing process was critically conducted to ensure that the final system meets the system design requirements specified in Table 3 .

3.4 User Manual The final application developed in Prototype 3 is expected to be packaged and uploaded to an institutions website. Users can then download the package as a zip file, which contains among other files; one that informs users as to how to execute the application. This file is called User Manual. The labeled user interface is shown as Figure 36 below.

52

Figure 36: Labelled User Interface to show Steps in User Manual

The User Manual instructions are shown below as an example.

SYNCHRONISATION TEACHING TOOL A teaching tool, which animates the synchronised and unsynchronised behaviours of threads in concurrency programming, is developed in this project.

David Ebo Adjepon-Yamoah July 2012 Newcastle University, MSc. Computing Science Project (27 August 2012)

53

Instructions STEP 1 Double click the executable file called Project.jar. OR Run java jar Address of the Projects executable file\Project\dist\Project.jar in the terminal, after accessing the dist projects folder. Users can access the USER MANUAL tab in the application. This tab provides all the instructions of the applications user manual. It is convenient for the user as opposed to joggling between the application and the user manual file in the applications folder.

Figure 37: Snapshot of User Manual in the Final Application

54

STEP 2 Choose either PRODUCER/CONSUMER SOLUTION or the READER/WRITER SOLUTION tab to run the animation for the Producer/Consumer problem or the Reader/Writer problem respectively.

STEP 3 (User Options) i. ii. iii. Click on the RUN command button to execute the synchronised version of the problem chosen in STEP 2 above. Or click on the Unsynchronized option button to execute the unsynchronised version of the problem chosen in STEP 2 above. Or click on PAUSE to halt the execution of the version already chosen after either clicking on the RUN command button or the Unsynchronized option button. This option can be used to switch between a synchronised implementation and an unsynchronised implementation of the problem chosen in STEP 2.

STEP 4 Click on the EXIT command button to end the application.

Good Luck Studying Concurrency Programming! David Ebo Adjepon-Yamoah

55

4.0 RESULTS AND EVALUATION

This chapter discusses the results of this dissertation with particular regards to the related project developed by the author.

4.1

Presenting the Results A. Time Plan of Thesis

The work done on the proposal, project implementation and dissertation writing spans a period of eleven (11) weeks. The first four (4) weeks were used to analyse the project, do a literature review and write research proposal. During this period, the author assessed the domain of the problem and then defined the aims and objectives of the dissertation. The next four (4) weeks was dedicated to the implementation of the project. Three (3) weeks were assigned to the writing of the dissertation, but some documentation that was made in the preceding stages was added to the dissertation. This meant that the writing of the dissertation overlapped with some other stages. A detailed description of the work plan of this project is shown in Table 1 and Figure 3.

B. Graphical User Interface (GUI) Design The graphical user interface (GUI) design was basically made using the java.awt (Abstraction Windowing Toolkit - AWT) and the javax.swing (Swing) packages in the Java library. These packages are the main tools for designing GUIs in Java. The NetBeans IDE provides a Swing GUI builder which made the designing of the final prototype much easier. A GUI of the final application can be seen in Figure 26.

C. Implementation The solutions to the Producer/Consumer and Reader/Writer synchronisation problems were mainly implemented using the Runnable interface to enable the threads to inherit from other classes including the Thread class. This option helps to facilitate the program to be expanded to provide other features in the future. Also, locks (java.util.concurrent.locks.Condition, java.util.concurrent.locks.Lock and java.util.concurrent.locks.ReentrantLock) and signals (await(), signal() and signalAll()) were used to ensure synchronisation and interleaving of threads in the solution.

D. Products The project produced two important results relative to this dissertation; the development of a teaching tool using Java programming language and the evolutionary prototyping model; the user manual for the developed application. Also, the author gained a considerable amount of
56

knowledge in animation development in the NetBeans IDE. Further knowledge and experience was gained in the areas of concurrency programming and the application of evolutionary prototyping model in the course of the project. The major deliverables of the project are further explained below: i. Teaching Tool:

Two teaching tools were developed as part of this project. The author developed a teaching tool that produced textual results for both synchronised and unsynchronised implementations of the Producer/Consumer and Reader/Writer problems. Users are able to interact with the tool in choosing whether they wanted to execute either the synchronised or unsynchronised versions of the problems. This tool was developed as the first prototype of this project. Figure 19 is an example of the output textual interface of this prototype. Also, a teaching tool was developed based on the foundation laid by the first two prototypes. Prototype 1 provided implementations for synchronised and unsynchronised versions of the above mentioned synchronisation problems. Prototype 2 provided some ideas and insights into the development of graphical user interfaces (GUIs). Prototype 3 developed a functioning teaching tool which has an interactive graphical user interface (GUI). A GUI of this prototype can be seen in Figure 26. ii. User Manual:

There are two types of user manuals created for the users of this application. The first user manual is a text file named User Manual and saved in the applications folder. A copy of this file can be found in Chapter 3 subsection 3.4, and it is also attached to this dissertation as an appendix. Figure 37 shows a snapshot of the second type of user manual created for the application. A tab is created with caption USER MANUAL in the application. The user information provided in the file and the application is the same.

4.2

Discussion

The author preferred that the application is tested by some undergraduates and postgraduates of the School of Computing Science to be able to have their opinion. A qualitative method of data collection such as a questionnaire was going to be developed to seek empirical support of the aims and objectives of this academic exercise. The author would have wanted to know the usefulness, future improvements and ease of use of the teaching tool. As a result of time constraint for the project and the unavailability of most undergraduate and postgraduate students, the author was not able to collect data to this effect. To further make the teaching tool very informative, the author provided a textual output of the implementations in a command line interface (CLI) or a terminal. This is necessary as the animation does not inform users when an unsynchronised behaviour of threads occur in the unsynchronised implementation of the Producer/Consumer and Reader/Writer solutions. In the Producer/Consumer implementation, the Number consumed by a Consumer thread is not shown. Similarly, the Numbers written by Writers and read by Readers are not shown. A substring of the dictionarys object name is shown when a Writer writes a Number. The terminal provides a perfect complement to the graphical user interface since all the Numbers produced and consumed, and written and read are all shown in a tabular structure. Users can assess the textual output to further gain information to the
57

implementation of the solutions. The terminal is shown below in Figure 38. It provides a solution to an initial challenge faced by the author with regards to alerting users when an unsynchronised implementation of the solutions occurred. Through the terminal, users can be able to assess the behaviour of the threads through the Numbers they operate on, and the timeline provided. Users can halt an implementation by dragging the vertical scroll bar up to inspect the output in the terminal.

Figure 38: Terminal to Provide Further Information to Users

4.3

Evaluation of the Approach

A. Software Development Model The software development model used for this project is the evolutionary prototyping model. The waterfall model was initially considered due to its well defined order, feedback system, adherence to documentation, ease of understanding its processes, and the ease in planning and tracking the various processes. The author was informed through the literature review conducted in Chapter 2.0 that inexperienced users may not be able to deliver their projects on
58

time as a result of its strict structure. The model does not cope well with changes, and problems might be expensive to fix. The agile process model was also assessed since it copes well with changes and feedback, and can handle poorly understood requirements. The agile process model gets more time consuming for refactoring as the project grows. This project requires complex concurrency programming that will use even more time for refactoring. Since the authors dissertation is strictly bound by time, the choice of the evolutionary prototyping model appears to be the best option. The evolutionary prototyping model works well with customers and evolve a final system from an initial outline specification and requirements. In this model, specification and development are interleaved which provides a high level of malleability. Even though this model starts with well understood requirements and this projects requirements have changed in the final application, the author ensured that all the requirements needed for every prototype were well understood before they were implemented. The re-engineering of the systems requirements used a considerable amount of time as the author wanted to ensure that the necessary and most practicable requirements were considered.

B. System And Graphical User Interface (GUI) Also, the author will use the ten usability heuristics for user interface design proposed by Nielsen (1994) to evaluate the applications user interface [35]. These heuristics are: i. Visibility of system status:

The application always keeps users informed about what is going on, through appropriate feedback within reasonable time. These feedbacks provided are evident in the colours and text used to indicate the state of the threads. Also, some behaviours of the thread such as the Number produced by the Producer thread and the consumption or reading of that Number. The animation and the terminal (Figure 38) will inform the user by implementing the commands made by the user, and responding appropriately by providing output. ii. Match between system and the real world:

The system speaks the users language, with words, phrases and concepts familiar to the user, rather than relying solely on system-oriented terms. Real-world conventions such as window structure, familiar colour codes, use of command buttons and option buttons to accept user instructions, and making information appear in a natural and logical order. Tables were used to provide a structure to the output in the terminal and the layout followed the Microsoft and Apple user interface conventions. iii. User control and freedom:

Users are provided command buttons (captioned RUN, PAUSE and EXIT) and option buttons (captioned Unsynchronize) to send instructions to the application. Through such media, users can control the behaviour of the application to suit their wants. The users are free to execute the solutions at any time that they desire. iv. Consistency and standards:

Users do not have to wonder whether different words, situations, or actions mean the same thing. The project is consistent with the Microsoft and Apple platform standards which are

59

familiar to a majority of computer users. The mentioned platforms are also very similar to the UNIX and Linux platforms. v. Error prevention:

It is realised that even better than good error messages is a careful design which prevents a problem from occurring in the first place. This project attempts to eliminate error-prone conditions and checks all other errors that may arise in the implementation of the application. It uses mechanisms such as exception handling with examples including throws keyword, try..catch and try.finally blocks. vi. Recognition rather than recall:

Objects, actions, and options are made visible to minimize the users memory load. The designing of the application takes into consideration that the user should not have to remember information from one part of the dialogue to another. Instructions and user manual for use of the system are visible on the main interface of the application, and are easily retrievable whenever appropriate. vii. Flexibility and efficiency of use:

Expertise level of the user in the area of concurrency programming is taken into consideration. Lecturers or experienced users can use the animation and be able to understand the behaviours of the threads. Provision such as the terminal shown in Figure 38 is made for the student users to gain more understanding of the type of programming under review. Timers (javax.swing.Timer) have been used to slow down the implementations in the animation to enable users to follow the various actions. viii. Aesthetic and minimalist design:

Dialogues were made to contain only relevant information. The design considered the fact that every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. ix. Help users recognise, diagnose, and recover from errors:

All forms of information including any possible error messages are expressed in plain language and not even technical terms. The user manual provides all the necessary information that the user will need to successfully run this application. x. Help and documentation:

Help and documentation are necessary even for smaller applications like the one developed in this project. The copy of the user manual in the application is easy to search for and locate on the applications interface. The user manual is focused on the users task; it lists the concrete steps to be carried out, and it is not large.

60

5.0 CONCLUSIONS
5.1 Meeting the Original Objectives

The aims and objectives of this MSc Dissertation project that are presented in Chapter 1.0 subsections 1.3 and 1.4, and in the project proposal were all implemented at the conclusion of this dissertation. A teaching tool that provides animations of the solutions of the well-known synchronisation problems in concurrent programming; Producer/Consumer problem and Readers/Writers has been developed. The tool presents both the synchronised and unsynchronised implementations of the above mentioned problems. The above mentioned aim of the dissertation was achieved by implementing some objectives. These objectives are briefly discussed below.

A.

Research selected existing systems, which provide visualisation of the mentioned synchronisation problems:

Many existing systems were profiled to ascertain their shared characteristics with the specification and requirements of the proposed system to be developed as part of this dissertation. Two major existing systems stood out and were researched further with regards to this dissertation. The research conducted on these two systems is provided in subsection 2.2 of Chapter 2.0. The author realised that the works of Magee and Kramer [43] and Stallings [44] are very effective tools for teaching concurrency programming. That notwithstanding, particular attention was paid to the work of Magee and Kramer [43] since their work is much simpler to understand the implementations and it also has a simpler user interface. Magee and Kramers work used Java Applets instead of creating stand-alone applications. This is largely because of the availability of some convenient libraries such as Graphics, Graphics2D, etc. to develop rich animations in Java Applets. They also made good use of easily identifiable colours to represent the states of their threads; red to represent termination and green to represent running. The buffer representations were quite understandable as the contents (alphabets) of the individual buffers were displayed, and coloured circles are assigned to buffers that were being operated on. The application developed by the author of this dissertation is largely influenced by Magee and Kramers work. The main differences are that: i. The author developed a stand-alone application as opposed to Magee and Kramers applets. The reason is that current applets are heavily dependent on the installation of Java 2 Platform Standard Edition (version 1.5.0 or later) on their target machines to be able to execute. This situation limits the number of computers that can be used to execute the applets. Even though most of the web browsers (Internet Explorer, Netscape, HotJava, Firefox 1.0.4, Mozilla 1.6, etc.) are java compatible, there are still versions of browsers such as Internet Explorer versions 1.0, 2.0 and 3.0 that are not Java-enabled. Some browsers also require Java plugins to be able to render some web pages. On the other hand, Java applications are built to be independent of such restrictions. Java applications can
61

run on Windows operating systems such as Windows XP, Windows Vista and Windows 7, and Mac OS. ii. Appropriate text was used to support the colours that indicate the states of the threads. This addition enhances the understanding of the implementations. The user interface is made bigger than that of Magee and Kramer to afford users clarity and easy access to the information the application provides. A user manual is provided in the application. This is to provide more information to the user in the use of the application.

iii.

iv.

B.

Study animation and visualisation techniques:

A brief history of visualisation and animation were researched to get information about the origin of these concepts. Chapter 2.0 subsection 2.1.3 provides a summary of the history of visualisation and animation. Further narrower research was conducted in the area of software development which indicated that various visualisation and animation technologies have been engineered and used to model simple but mostly complex processes. The current techniques used in visualisation are the multivariate visualisation techniques. In many multivariate visualization techniques, such as parallel coordinates [23, 24], glyphs [25], scatterplot matrices and pixel-oriented methods, dimensions are positioned in some one- or twodimensional (1D or 2D) arrangement on the screen. The introduction of 3-Dimensional (3D) arrangement is largely a technical advance driven by whats possible, in advance of a full understanding of whats useful or appropriate. The hope is that 3D will overcome some of the limitations of 2D in terms of the number of attributes and types of relationships that can be visualized. It is an aspiration to find new metaphors to exploit the additional representational richness [26]. The three-dimensional (3D) arrangement on the screen makes visualisation even better and very easy to identify the patterns in the visual representation. The organization of the dimensions can have a major impact on the expressiveness of the visualization. Different orderings of dimensions can reveal different aspects of the data and affect the perceived clutter and structure in the display. Thus completely different conclusions may be drawn based on each display [21]. The dimension used in the development of this project is a simple one-dimensional (1D) and a pixel-oriented technique of visualisation was adopted. C. Research technologies that might be employed to build a teaching tool:

The technologies applied in the development of the teaching tool described in this dissertation involve Concurrency Programming, Java Programming Language and Libraries, Graphical User Interface design using Abstraction Windowing Toolkit (AWT) and Swing, and Event-Driven Programming. These technologies have been assessed by the author and realised they were important as far as meeting the specifications and requirements of this project. Detailed descriptions of the above mentioned technologies can be found in Chapter 2.0 subsection 2.1.4.

62

D.

Design and implement a tool that visualises/animates the solutions to the chosen synchronisation problems:

The evolutionary prototyping model was used to design the project in this dissertation. The author implemented three prototypes using the Java programming language (NetBeans IDE 7.1.2). Prototype 1 delivered solutions to the Producer/Consumer and Reader/Writer problems. The output of this prototype is in a textual and tabular format, and technologies such as locks (java.util.concurrent.locks.Condition, java.util.concurrent.locks.Lock and java.util.concurrent.locks.ReentrantLock) and signals (await() , signal() and signalAll()) were applied. A sample output from the application developed in Prototype 2 is shown in Figure 19. Prototype 2 was an attempt to apply the authors knowledge of graphical user interface (GUI) design. Also, an attempt was made to implement the Producer/Consumer solution developed in Prototype 2 through the GUI. The major technologies employed here are the java.awt (Abstraction Windowing Toolkit AWT) and the javax.swing (Swing) packages in the Java library described earlier in Chapter 2.0 subsection 2.1.4. Other Java events packages such as java.awt.event.ActionEvent (Action Event) and java.awt.event.ActionListener (Action Listener) were used. This attempt presented in Figure 25 challenged the author to identify other GUI designing tools such as the Java GUI Builder in NetBeans IDE 7.1.2. Prototype 3 used the NetBeans IDE 7.1.2 Java GUI Builder, JDialog, JMenuBar, JMenu, JPanels, JTextArea, JTextFields, JButtons, and JRadioButton from the Swing package, introduction of colours and texts to represent the states of the threads, and the representation of the three bounded buffers in the design of the final graphic user interface of the application. Also the javax.swing.Timer (Timer) package was used to set appropriate colours for the threads after every 100 milliseconds. The GUI developed in the Prototype 3 as shown in Figure 26, is able to animate the implementations of the synchronisation solutions. All or most of the ideas and results obtained from Prototypes 1 and 2 were evolved into inputs in the development of the final prototype.

E.

Evaluate the usability and usefulness of the system:

The final applications user interface was evaluated b y Nielsen (1994)s ten usability heuristics for user interface design [35]. The heuristics outlined by Nielsen are Visibility of system status, Match between system and the real world, User control and freedom, Consistency and standards, Error prevention, Recognition rather than recall, Flexibility and efficiency of use, Aesthetic and minimalist design, Help users recognise, diagnose, and recover from errors, and Help and documentation. The above mentioned heuristics are discussed in Chapter 4.0 subsection 4.3 with regards to the project of this dissertation.

5.2

Positive and Negative Aspects

The positive aspects of undertaking this project far outweigh the negative ones. The author had an opportunity to learn and implement a project using animation. It is even more rewarding to see that the implementation of the animated teaching tool meets all of the objectives of the project. Further experience in concurrency programming was gained
63

through practice and solving problems that arose in the course of the projects implementation. On the other hand, the application was not tested by many users such as undergraduate and postgraduate students Computing Science. The author preferred to conduct a survey which is a qualitative method of data collection using questionnaire to seek empirical support of the aims and objectives of this academic exercise. The author would have wanted to know the usefulness, future improvements and ease of use of the teaching tool. As a result of time constraint for the project and the unavailability of most undergraduate and postgraduate students, the author was not able to collect data to this effect. Also, the PAUSE feature of the application is not fully implemented and hence, users cannot use it. This means that users cannot swap between synchronised and unsynchronised implementations unless the application exited at the completion of one implementation and re-run for the other implementation. Such a situation will be inconvenient for users. Again, the author was unable to test the application on an Apple computer (Apple Mac). This was because the author could not have access to a computer running the Mac OS. Finally, the Numbers consumed by Consumers in the Producer/Consumer problem and those written by Writers and read by Readers in the Reader/Writer Problem were not displayed in the Buffer and the Database in the respective animations of the problems in the final prototype. Even though information was provided to the user on the occurrence of the above mentioned action, the author would have preferred that the Numbers that were operated on will be displayed to the users of the application. The author of this dissertation was constrained with time and was unable to further research on this problem.

5.3

Future Work

A major area in this dissertation is animation. Further research can be conducted into other advanced forms of visualisation and animation, and then applied to this project. The visualisation and animation dimensioning areas of 2-Dimension and even 3-Dimension can be explored to animate the classical synchronisation problems of concurrency programming. This can make the teaching tool much livelier and entertaining to minimise the amount of tension related to the studies of concurrent programming. With regards to making the application livelier and more educative, users can have an option of choosing from a range of 1-Dimensional, 2-Dimensional and 3-Dimensional animations that they are comfortable with and better clarifies the solutions to the synchronisation problems. These choices contribute additively to constructing a mental model. Also, provision can be made to incorporate the solutions to other synchronisation problems such as the Dining Philosophers problem and the Sleeping Barber problem. The teaching tool developed by this proposed project will be a one-stop shop for illustrating the synchronised and unsynchronised implementations of the classical synchronisation problems. That apart, the PAUSE feature can be implemented to facilitate convenience in switching between synchronised and unsynchronised implementations of the solutions to the synchronisation problems.

64

Again, a means of informing users of the Numbers operated on in the implementations can be researched into and adapted into this project. Since information provision is an important aspect of all teaching tools, this should be done with a high level of urgency. A comprehensive testing strategy could be developed for the project. This will ensure that most logical or syntax errors are handled. Also, the application can be tested on many platforms such as most current Windows operating systems, Mac OS, Android, BlackBerry, UNIX and Linux platforms, with varying screen resolutions. The author also proposes that a version or versions compatible to the above mentioned platforms can be developed to reach out to many users. Finally, all future work on this project or related ones should be evaluated by a sample of the target users. Such an action will ensure that a qualitative appraisal of the final product is done to inform the developer of the current state and the way forward for the teaching tool.

65

6.0 BIBLIOGRAPHY 1. Asanovic K. , B.R., Demmel J. ,Keaveny T. ,Keutzer K. ,Kubiatowicz J. ,Morgan N. ,Patterson D. , Sen K. ,Wawrzynek J. ,Wessel D. , Yelick K., A view of the parallel computing landscape. Communications of the ACM, 2009(52(10)): p. 56-67. Sutter, H., The free lunch is over: A fundamental turn toward concurrency in software. Dr. Dobbs Journal, 2005(30(3)): p. 16-20. Geer, D., Chip Makers Turn To Multicore Processors. IEEE Xplore, 2005. 38: p. 11 13. Bridges, M.J., Vachharajani, N. , Zhang, Y. ,Jablin, T. ,August, D. I. , Revisiting the Sequential Programming Model for Multi-Core, in 40th Annual IEEE/ACM International Symposium on Microarchitecture2007: Chicago, IL. p. 69 - 84. Sadowski C., B.T., Bishop J., Burckhardt S., Gopalakrishnan G., Mayo J., SIGCSE 11: PROCEEDINGS OF THE 42ND ACM TECHNICAL SYMPOSIUM ON COMPUTER SCIENCE EDUCATION. ACM 2011(978-1-4503-0500-6/11/03). Brown, G., Atkins, M. , Effective Teaching in Higher Education1988: Methuen & Co. Ltd. 97. Turney, C., Explaining, introductory procedures and closure, advanced questioning1983: Sydney University Press (Sydney and Beaverton, Or., U.S.A.). Kozma, R.B., Belle, L. W. , Williams, G. W. , Instructional Techniques in Higher Education1978, Englewood Cliffs, New Jersey 07632: Educational Technology Publications, Inc. 413. Robeck, E., Sharma, A. , Student-Generated Multimedia As A Means To Meaningful Science Education. Journal Of The International Society For Teacher Education, 2011. 15(1). Moreno, R., Learning with high tech and multimedia environments. Current Directions in Psychological Science, 2006. 15(Number 2): p. 63 - 67. Blake, C., Scanlon, E. , Reconsidering simulations in science education at a distance: features of effective use. Journal of Computer Assisted Learning, 2007: p. 491502. Fowler, M., Refactoring: Improving the design of existing programs 1999: AddisonWesley. Snow, C.R., Concurrent Programming1992, University of Cambridge: The Press Syndicate. Magee, J., Kramer, J. , Concurrency: State Models and Java Programs. Second Edition ed, ed. J.W.S. Ltd2006, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England: John Wiley & Sons Ltd. 407. Ben-Ari, M., Principles of Concurrent and Distributed Programming2006, Edinburgh Gate, Harlow, Essex CM20 2JE, England: Pearson Education Limited. Hughes, C., Hughes, T., Parallel and Distributed Programming Using C++2003: Addison-Wesley Professional. 720. Microsoft Corporation, THE MANYCORE SHIFT: Microsoft Parallel Computing Initiative Ushers Computing into the Next Era. The Manycore Shift White Paper, 2007. The Global Information Technology Report, Living in a Hyperconnected World, B.B.O. Soumitra Dutta, Editor 2012, World Economic Forum and INSEAD. Torrellas, J., Oskin, M., Adve, S., Almasi, G., Ceze, L., Chtchelkanova, A., Das, C., Feiereisen, B., Harrod, W., Hill, M., Hiller, J., Kannan, S., Kant, K., Kozyrakis, C., Larus, J., Murphy, R., Mutlu, O., Narayanasamy, S., Olukotun, K., Patt, Y, Sivasubramaniam, A., Skadron, K., Strauss, K., Swanson, S., Tullsen, D., Failure is
66

2. 3. 4.

5.

6. 7. 8.

9.

10. 11. 12. 13. 14.

15. 16. 17.

18. 19.

20.

21.

22. 23. 24. 25. 26. 27.

28. 29.

30. 31.

32. 33.

34.

35. 36.

37. 38.

not an Option: Popular Parallel Programming, in Workshop on Advancing Computer Architecture Research (ACAR-1)2010: San Diego, California. p. 30. Friendly, M. Milestones in the history of thematic cartography, statistical graphics, and data visualization. 2009 [cited 2012 05/08/2012]; Available from: http://www.datavis.ca/milestones/index.php?page=varieties+of+data+visualization. Peng, W., Ward, M. O., Rundensteiner, E. A., Clutter Reduction in MultiDimensional Data Visualization Using Dimension Reordering, in IEEE Symposium on Information Visualization (INFOVIS 2004)2004, IEEE: Austin, Texas, USA. p. 89 - 96. Eick, S.G., Graphically displaying text. Journal of Computational and Graphical Statistics, 1994. 3: p. 127 - 142. Inselberg, A., The plane with parallel coordinates. Special Issue on Computational Geometry, The Visual Computer, 1985. 1: p. 69 - 97. Wegman, E.J., Hyperdimensional data analysis using parallel coordinates. Journal of the American Statistical Association, 1990. 411(85): p. 664 675. Littlefield, R.J. Using the glyph concept to create user-definable display formats. in National Computer Graphics Association. 1983. Marcus, A., Feng, L., Maletic, J.I., 3D representations for software visualization. ACM Symposium on Software Visualization, 2003: p. 207. Duffy, J., Concurrent Programming on Windows. Microsoft .NET Development Series, ed. D.B. John Montgomery, Brad Abrams2009, Boston, USA: Pearson Education, Inc. Latham, J., Java: Just in Time. Computing Series, ed. I. Mackie. Vol. 14. 2011, King's College London, Strand, London WC2R 2LS, UK: College Publications. 615. Malik, D.S., Java Programming: From Problem Analysis to Program Design. Second ed, ed. S.G. Mac Mendelsohn2006, Boston, Massachusetts, USA: Thompson Course Technology. 1087. Wu, C.T., An Introduction To Object-Oriented Programming with Java. Third ed, ed. K.H. Lowery2004, New York, NY 10020, USA: McGraw-Hill. 937. TIOBE Software Company. TIOBE Programming Community Index for July 2012 (July Headline: Objective-C overtakes C++). [Web Page] 2012 [cited 2012 07/08/2012]; Available from: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html. Norman, D., The next UI breakthrough: command lines. Association for Computing Machinery (ACM), 2007. 14(3): p. 44-45. Reddy, D. UI's and Java Swing. UI's and Java Swing [Web Page] 2008 06 February, 2008 [cited 2012 13/08/2012]; Available from: http://www.jroller.com/DhilshukReddy/category/JavaSwing. Zhang, S., Zhan, Q., Du, H., Research on the Human Computer Interaction of Elearning, in 2010 International Conference on Artificial Intelligence and Education (ICAIE)2010, IEEE Xplore: Hangzhou, China. p. 5. Nielson, J., Usability Inspection Methods, ed. J. Nielson, Mack R. L.1994, New York, USA: John Wiley & Sons. Hughes, C., Buckley, J., Evaluating Algorithm Animation for Concurrent Systems: A Comprehension-Based Approach, in 16th Workshop of the Psychology of Programming Interest Group2004. p. 193 - 205. Kraemer, E., Concurrency. Software Visualisation, 1998. Stasko, J.T., Tango: A framework and system for algorithm animation. Computer, 1990. 23: p. 27-39.

67

39.

40. 41. 42. 43. 44.

45. 46.

47.

48. 49. 50.

Brown, M.H. Zeus: a system for algorithm animation and multi-view editing. in 1991 IEEE Workshop on Visual Languages. 1992. Los Alamitos, California, USA: IEEE Press. Stasko, J.T., Badre, A., Lewis, C., Do animations assist learning? An empirical study and analysis, in INTERCHI 1993. p. 61- 66 Brown, M.H., Sedgewick, R. , Techniques for algorithm animation. IEEE Software, 1985. 2(1): p. 28-39. Brown, M.H., Exploring Algorithms using Balsa-II. Computer, 1988. 21(5): p. 14-36 Magee, J., Kramer, J. Concurrency: State Models & Java Programs. 2006 [cited 2012 30/06/2012]; Second:[Available from: http://www.doc.ic.ac.uk/~jnm/book/. Stallings, W. Animations for Operating Systems. [Web Page] 2009 [cited 2012 11/08/2012]; 6:[Animation of Synchronisation Problems]. Available from: http://williamstallings.com/OS/Animation/Animations.html. Stallings, W. Student and Instructor Resource Site. [Web Page] 2009 [cited 2012 11/08/2012]; Available from: http://williamstallings.com/OS/OS6e.html. Text and Academic Authors Association. TAA announces 2009 Texty, McGuffey Award winners. [Web Page] 2010 [cited 2012 11/08/2012]; Available from: http://www.taaonline.net/awards/2009winners.html. The ACM Special Interest Group on Software Engineering. ACM SIGSOFT Outstanding Research Award. [Web Page] 2005 [cited 2012 11/08/2012]; Available from: http://www.sigsoft.org/awards/outResAwd.htm. Foxwell, H.J. Introduction to Process Synchronization Using the Java Language. 1997. 11. Pressman, R.S., Software Engineering - A Practitioner's Approach. 6 ed, ed. M.-H.H. Education2005, USA: McGraw-Hill Higher Education. 928. Broad, R. Learning Through Performance Feedback from Computer Simulation. 2008 [cited 2012 30/07/2012]; Dissertation]. Available from: http://www.google.co.uk/search?sugexp=chrome,mod=16&sourceid=chrome&ie=UT F-8&q=newcastle+university+msc+computer+science+dissertaion+sample.

68

7.0 APPENDICES
7.1 Project Time Plan

Figure 3: Time Estimation of Dissertation (Designed Using Gantt Project 2012)

69

7.2 i.

User Manual Manual in the Application

Figure 39: Snapshot of User Manual in the Final Application

ii.

Textual Manual

SYNCHRONISATION TEACHING TOOL A teaching tool, which animates the synchronised and unsynchronised behaviour of threads in concurrency programming, is developed in this project.

David Ebo Adjepon-Yamoah July 2012 Newcastle University, MSc. Computing Science Project (27 August 2012)
70

Instructions STEP 1 Double click the executable file called Project.jar. OR Run java jar Address of the Projects executable file\Project\dist\Project.jar in the terminal, after accessing the dist projects folder. Users can access the USER MANUAL tab in the application. This tab provides all the instructions of the applications user manual. It is convenient for the user as opposed to joggling between the application and the user manual file in the applications folder.

STEP 2 Choose either PRODUCER/CONSUMER SOLUTION or the READER/WRITER SOLUTION tab to run the animation for the Producer/Consumer problem or the Reader/Writer problem respectively.

STEP 3 (User Options) i. ii. iii. Click on the RUN command button to execute the synchronised version of the problem chosen in STEP 2 above. Or click on the Unsynchronized option button to execute the unsynchronised version of the problem chosen in STEP 2 above. Or click on PAUSE to halt the execution of the version already chosen after either clicking on the RUN command button or the Unsynchronized option button. This option can be used to switch between a synchronised implementation and an unsynchronised implementation of the problem chosen in STEP 2.

STEP 4 Click on the EXIT command button to end the application.

Good Luck Studying Concurrency Programming! David Ebo Adjepon-Yamoah

71

7.3

Classes in Prototype 1 A. Producer/Consumer Classes i. Buffer Class ii. BufferImplementation Class iii. Consumer Class iv. Producer Class v. Project Class vi. UnsyncBufferImplementation Class B. Reader/Writer Classes i. ProjectRW Class ii. ReadWrite Class iii. ReadWriteImplementation Class iv. Reader Class v. UnsyncReadWriteImplementation Class vi. Writer Class

72

7.4

Classes in Prototype 2 (GUI_Prototype2 Package) i. ii. iii. iv. v. vi. Buffer Class BufferImplementation Class Consumer Class Producer Class ProducerConsumerUI Class UnsyncBufferImplementation Class

73

7.5

Classes in Prototype 3 (project Package) i. ii. iii. iv. v. vi. vii. viii. ix. x. xi. xii. xiii. Buffer Class BufferImplementation Class Consumer Class Producer Class ProducerConsumer_Dialog Class Project Class ReadWrite Class ReadWriteImplementation Class Reader Class UnsyncBufferImplementation Class UnsyncBufferImplementation Class UnsyncReadWriteImplementation Class Writer Class

7.6

Java Documentation (javadocs) for Final Application

74