The Design and Implementation of a Celtic Knot D rawing...

1

The Design and Implementation of a Celtic Knot Drawing Package with

Multimedia Help Guides

Michael B. Walmisley

BSc (Hons) Computer Science

University of Bath

May 2004 This dissertation may be made available for consultation within the University Library and may be photocopied or lent to other libraries for the purposes of consultation. Signed: . . . . . . . . . . . . . . . . . . . . .

2

Abstract

The process of drawing Celtic knots can become tiresome and although the art has existed in it paper drawn form, the new age of introducing the computer is already begun. Drawing Celtic Knots is a slow process, with its intricately drawn grids that define the shape of the knot to the long process of smoothly linking the knot to itself. The confusion of the Celtic knots cross over intersection points to its never ending cord length. This project looks at the various elements required to put together a Celtic Knot drawing package which someone can use quickly and easily to draw theses Knots.

3

The design and Implementation of a Celtic Knot Drawing package with Multimedia help guides

Submitted by Michael Brett Walmisley

Acknowledgements

Many thanks to my supervisor Claire Willis of the department of

computer science at Bath University and a thank you to my Parents

COPYRIGHT Attention is drawn to the fact that the copyright of this dissertation rests with its author. The Intellectual Property Rights of the products produced as part of the project belong to the University of Bath (see http://www.bath.ac.uk/ordinances/#intelprop). This copy of the dissertation has been supplied on condition that anyone who consults it is understood to recognise that its copyright rests with its author and that no quotation from the dissertation and no information derived from it may be published without the prior written consent of the author. Declaration This dissertation is submitted to the University of Bath in accordance with the requirements of the degree of Bachelor of Science in the Department of Computer Science. No portion of this work in this dissertation has been submitted in support of an application for any other degree or qualification of this or any other university or institution of learning. Except where specifically acknowledged, it is the work of the author. Signed: . . . . . . . . . . . . . . . . . . . .

4

Contents 1 Introduction ………………………………………………………………… 6 2 Literature Review …………………………………………………………10 2.1 What are knots …………………………………………………11 2.2 Current Paper based algorithms ……………………….. 12 2.3 Educational Multimedia ……………………………………. 15 2.4 Current Applications available …………………………… 20 2.5 Implementation Methodologies …………………………..21 3 Requirements ………………………………………………………………23 3.1 Requirements analysis ………………………………………23 3.2 Requirements Specification ………………………………..25 3.2.1 Definitions …………………………………………….25 3.2.2 Implementation Language choice …………….25 3.2.3 System perspective ………………………………..26 3.2.4 System Features …………………………………….26 3.2.5 User Attributes ………………………………………28 3.2.6 Operating environment …………………………..29 3.3 Multimedia Specification …………………………………….29 3.3.1 Information …………………………………………..29 4 Design ………………………………………………………………………..31 4.1 Methodology …………………………………………………….32 4.2 System Architecture ………………………………………….32 4.3 User Interface ………………………………………………….32 4.3.1 The Main Screen ……………………………………33 4.3.2 The Multimedia Screen …………………………..34 4.3.3 The Knot Screen …………………………………….34 4.3.4 The Generator Screen …………………………….35 4.3.5 Multimedia Help …………………………………….37 4.4 Class Design ……………………………………………………..37 4.4.1 Overview of Class design ………………………..37 4.4.2 The Tile Class ………………………………………..38 4.4.3 The Generator Class ……………………………….39 4.4.4 Editing Knots …………………………………………42 5 Implementation …………………………………………………………..43 5.1 Overview ………………………………………………………….43 5.2 Creating Celtic Knots …………………………………………44 5.2.1 The Knot Window …………………………………..44 5.2.2 The Generator Panel ……………………………….47 5.3 The Main Application Interface ……………………………51 5.3.1 The Help Guides …………………………………….52 6 System Testing ……………………………………………………………53 7 Conclusions …………………………………………………………………56 7.1 Proposed Further Work ……………………………………..56 7.2 Concluding Remarks ………………………………………….57

5

Appendix A – Use Case examples …………………………………….60 Appendix B – Code Listing ………………………………………………63

Chapter 1 Introduction

6

Chapter 1 Introduction “To search for a single meaning for any one Celtic symbol is nearly impossible. The meanings for each knot vary as much from country to country, from one person to another. When the knots were first drawn the Celts gave no particular meaning for any symbol. However, you should always realize that the Celts felt that all life was interconnected, and these knots represent that particular belief” (WWW: Celtic KnotWork 04/2004). The Field of Knot-work is primarily a paper based, hand drawn form of art which until recently, was only drawn on physical objects such as paper. There are a variety of paper based methods for creating the art work but the nature of the arts construction comes with a variety of tedious assembly routines. Allowing the user the ability to skip these tiresome steps will help them concentrate on the final look of the Knot before they consider implementing it. Although a number of different implementations exist, each pursues the same goal of automating the drawing process. Nevertheless, each provides certain benefits and restrictions. From simple 2D representations to fully viewable 3D knots which can be displayed from a variety of angles, however, some lack the ability to provide a direct reference to the Knots parameters and its resultant structure within the Knot.


7

Project A im The design, implementation and testing of a Celtic knot-drawing application that provides an automated knot drawing package system for demonstrating the Celtic knots structure. Secondary, to provide a multimedia enhanced system help guide to indicate the applications use. Primary Objectives

1. Defining the Applications running platform (the language and hardware platform)

2. The simple automated Knot-drawing package to be used as a demonstrative purpose and for use as a quick Celtic knot drawing tool

3. The construction of a system guide for the less experienced computer user using a multimedia representation

Secondary Objectives

1. The construction of a usable and interactive interface which demonstrates and explains simple knot-work construction to a non-Celtic artist.

The objectives of the dissertation are to implement software which allows a user to create and edit Celtic Knots, using a graphical user interface (GUI); to generate a graphical representation of the Knot work in order to demonstrate the relationships between the proposed Knot parameters and its resultant effect on the Knot. By providing this quick construction tool, it will allow the user a platform in which to experiment on. As-well as this, the Projects secondary goal will seek to provide a system which can supply this demonstrative resource to the uninitiated Celtic artist and to offer a user the ability to quickly learn the basic elements for assembling and drawing their own knot-work. The proposed objectives define a wide variety of written material in which a need to approach and utilise these sources will be vital to create and finish a product that is usable and has sufficient demonstrative abilities. If we look at these important areas in list form,

• Software Platform suitability (i.e. Implementation Language) - Which language can be used to implement the construction and representation of the knot work quickly? (e.g. Java Applets, Java applications, Visual Basic, Delphi Etc)


8

• User interface design - Bridging the gap between the user and the system

• Types of Software Engineering Process methodologies. • Educating a User with a demonstrative application tool. • Types of Knot-work and the different methods for drawing

knots, i.e. which construction algorithms will be more suitable to computerise.

• Existing Applications. The above list is composed mainly with material that is associated with the design and implementation of the proposed application. This obviously draws much sense in that this project is primarily based on a software development solution. The main interest will be the studies regarding interaction between user and application in conveying the basic elements of knot drawing and the use of the system tools. The concept of conveying information about an applications use is far from new. Many systems provide a help system which the user has access to in order to familiarise themselves with the systems functionality or the steps involved in drawing a Celtic Knot. Generally, the media used to communicate this information is limited only to text and pictorial examples, but is there a better way to express this information? Further discussion of this theory behind utilising types of multimedia is presented in the next chapter, Chapter 2. Chapter 2 also discusses the various elements of the Celtic Knot construction and includes examples of the current styles and available processes of building their structure. In Chapter 3 the process of requirements analysis is examined in relation to the problem at hand, followed by an overview of the software and design justifications in Chapter 4. Chapter 5 discusses in detail the implementation of the project and reflects on the specific algorithms used and the rational behind the overall structure. The process of testing the system, followed by the concluding remarks and suggestions for further work are presented in Chapters 6 and 7 respectively.


9

Chapter 2 Literature Survey

10

Chapter 2 Literature Survey 2.0 Introduction There is a wide selection of material which needs to be considered before one can elaborate on the full scope of the project. What are the primary areas of interest? Exploring the Design and construction of a Celtic knot is essential, as this will provide and facilitate the design of algorithms that can be used for the basis of the projects growth. A primary consideration of this project is governed by the construction of software aimed at non-celtic artists, and to some degree their counterparts who understand the construction of knots. It will be useful, and definitely necessary to explore current Knot-drawing applications that are available and to evaluate the functionality that they provide and the interface they present. The second part of the chapter will focus on aspects of educational Multimedia and educational guides, looking at how current systems are developed. I shall be looking at the main principles and features which need to be addressed. This will involve looking at the various aspects that govern how a user can learn from a system and how to couple this process with the Computer Multimedia and the user. The remainder of the focus will look at summarising and orientating the project to a set of conclusions and how they will subjectively provide the building stones for the Software outcome of the project.


11

2.1 What are knots? Celtic knots are an ancient form of art; it has been sketched for thousands of years and started around the time of when the group, known as the “Celts” emerged around about 3000 years ago (a text by Simon James (1993) gives a good introduction of their history). The English Dictionary defines a knot as

‘a fastening together of the pairs or ends of one or more threads, cords, ropes, etc., by any one of the various ways of tying or

entangling’ The Celtic knot is the basis for the Celtic designs; but there are a few definitions of the parts of the knot that we need to look at. Abbott (1999, 2002) describes the basic property of the knot as the intersections, where the cord crosses the same or a different cord within the same drawing. These crossing points for a general knot are given the name ‘Interlacings’ - a point which is depicted as a ‘tied’ knot but only has one crossing. Nevertheless, artists have used multiple cord crossings at a particular intersection, and have succeeded using some clever tricks, as Meehan (1991) describes. The Celtic knots themselves all exhibit different properties, and my search through the various material has led me to a set, that I feel is relevant to this project only; the other properties I have disregarded for the purpose of this assignment. Nonetheless, one should know that they do exist within other areas of Knot drawing. Drew (1998-1999) takes this wide area of knot work in terms of generality and he states the more important features:

• ‘Over-and-Under’ Construction – The point to which a cord crosses the same or different cord is depicted as either ‘going under’ or ‘going over’.

• Uniform Cord width – The thickness or a cord used in the knot work.

• Pointed Returns or Loop backs – The part of a knot which suddenly changes in direction.

• Repetition – Many knots contain repeated sections, usually with symmetrical properties.

• Single-Cord Construction – Although Celtic Knots can be created with single cords, the possibility of using multiple cords is not unheard of.

Many features of the more commonly regarded Celtic Knots can be split into the above categories. But what about the features of common patterns that one sees in the art? Allen (1993) suggests there are eight basic knot patterns from which most of all interleaved Celtic


12

art can be derived from. He does suggest that the knots he gives can be used to form other patterns but he states that these eight are the more frequently used and give better authenticity if used. The burning question now is ‘How does one assemble these knots?’ Let us now look at how they are assembled. However, if a need for a more mathematical definition of Knots, there is a subset of mathematics known as ‘Knot Theory’. Here the knots are defined mathematically, and there principles encapsulated in variables. See http://www.freelearning. com/knots for details on the subject. 2.2 Current Paper based algorithms There are a variety of techniques and methods for constructing Celtic knots, some more mainstream while others demonstrate the complexity of the Celtic Knot. Sifting through the variety of construction methods and techniques used to aid the design of Celtic knots, I discovered that there is one main and more popular style of construction. However, in contrast to this more popular method, I will be looking at another, more recently developed method, that is very different from the current procedures used; but is still based around the same consistent ideas. The first, and more popular approach, defines an initial formation of a grid. Although this grid may be our usual definition of a grid there are methods which are built from a ‘Grid of dots’ as Panfilov (2003) describes within his techniques. The idea of the grid is said to “Code the Knot” as Mercat (1997) presents in his approach of assembly and states that ‘Each graph on a plane codes a knot’. To note, this grid merely represents the knot, its initial construction is purely a beneficial one to the artists and provides a base for line directions only. One vital point that must be always adhered to when constructing the grid is that the spacing of lines or dots must be evenly distributed and symmetrical to produce a ‘neat’ looking knot as Wallace (1997) insists. The ranges of methods that include this primary system of the grid all provide successive steps that are very similar to one another which create there defined version. Mercat (1997) defines his grid as providing the “shape for the knot”. Once a grid has been marked out, his required grid is created by placing marker points (dots) at all the mid-points of each edge; the edge is the line between two grid intersections. A slighter altered algorithm that still arises at the same step is described by proscribe.co.uk (2003). This algorithm places the marker points (dots) at the intersections of the initial grid lines. The defined grid now resembles a single area divided into equally spaced squares and moves away from the described notion of the graph or grid defining the knot shape as Mercat uses. Bain (1993) uses this type of defined square grid to place his marker points at the


13

intersections of the grid lines also. Many of these Algorithms have very similar features of construction that are based on or around this initially defined grid. Let’s now look at some of these methods and see how a finished knot is constructed. Once the grid has been erected and a valid set of marker points have been laid down, the next phase is to begin forming the knot. The fundamental difference at this stage is only the shape of the initial grid that will define the completed knot. Two of Bain’s (1986) more popular construction methods involve placing marker points along a length of grid at equally spaced intervals; this defines the shape of the knot. He then uses 45 degree diagonal lines to connect the dots on opposite sides along the length of marker points. Although these lines characterise a portion of the knot, they in fact, act as the base for the knot itself. When this is done, the next procedure is simply to join these lines. The joining occurs every even numbered dot along the length of the defined marker points, so here we can see that the number of marker points inevitably must be an even number, as an end to the knot will be difficult to close. The use of arches to join the sections creates curves in the knot. This provides an aesthetically pleasing knot. Bain (1986) then gives the final steps of cleaning up the knot work and then the most important part of construction takes place, the ‘over-and-under’ cord sequence. Drew (1998-1999) states that the arrangement, very rarely involves the path of a cord which either is under or over, twice in a row, as many other authors do, including Bain (1986). Fig 2.3 shows sample stage of the described technique.

There are many methods similar to the above layout, methods which use the shape of the grid as reference points for cord crossings and curve placement. There are more interesting techniques though, which produce much more variation in the knot. It can be shaped by placing ‘Walls’ described by Mercat’s (1997) more interesting method and Bain (1986) also uses this same technique but denotes this additional marker as the ‘Inside boarders’. These extra defining features act as a type of block where the cord is ‘controlled’; Bain (1973), by demonstrating this is that without this additional element, one is left


14

with a regular weaved knot, so adding these ‘Breaks’ causes the cord and weave to loop back on itself. These back loops help give a more interesting pattern, but, as with all knot work, they are based around a defined set of rules, and so there is also a typical set of conventions for placing these ‘Breaks’. A vital aspect of these break lines, is it enables Celtic artist to ‘Encapsulate’ the knot patterns, in a simple way to describe this is ‘Containing the Knot in a box’ Mercat (1997). This enclosure of the patterns helps to create a variety of interesting knot shapes from large letters to intricate patterns which make up a larger picture – for example, jewellery (WWW: deSignet International, 2000- 2004) Many Celtic artists (Mercat (1997), Bain (1986), Bain (1973), Sloss (1995)…) commonly use and arrange these ‘breaks’, either vertically or horizontally, but never any other way within there grid types. However, these breaks can also occur in different positions when using a different grid outline and the more common shapes used for this purpose are triangular, square, as we have already seen, and hexagonal. However, there are a variety of possibilities for making different shapes by just creating a lattice based on a series of Tessellations - any repeating pattern of interlocking shapes, Mercat (1997) Fig 2.2.

Sloss (1995) approaches the use of a grid in an entirely different way. As a substitute for using the grid as the basis for the knot work lines; Sloss (1995) uses each grid defined square as a slot for a pre drawn Celtic knot section. He then populates the grid with these sections, fitting the fragments together until a finished pattern emerges. Looking at the various types of method for constructing the Knots, this stands out from the rest as being very suitable for computerisation. Sloss’s (1995) fundamental difference gives us a good contrasting algorithm. But which construction method is best suited for transferring to a computer? One very interesting approach to the construction of Knot work has been the recent development of what is now known as “The Celtic Knot Font Method”. As many enthusiasts, including Isdell (2001, 2002) demonstrate. It bases its core practice


15

on developing the pattern using pre generated sections of the knot work as described above. Of course this is very suitable for computer use, as the engine to the implementation can only be generated on a computer. Although using a computer to construct a knot provides a high level of benefits, the correct use of the system and the underlying concepts for describing the Knot can be hard to convey to a potential user with no experience of Celtic Knots. So what kind of information will need to be conveyed towards a novice user to apply this to the proposed system and harness how the typical construction characteristics behind the Knot define its shape? Pictures, text or another medium or simply a combination. Many educational elements of Celtic knot-work simply use text and pictures, but is this information correctly published for novice users? The answer lies between many areas, so let’s look at some of these domains in terms of conveying information across our final medium, a computer interface. 2.3 Educational Multimedia The secondary objective looks at the concept of using multimedia as a teaching tool and we will now look at this area in a little more depth. The goal of educating is to teach but the information used is only a part of this process. The information used can be through a variety of mediums, from books to pictures and auditory to demonstrative motion information. Today in our age of computing, this educative information can be presented via a computer screen. With technology advancements and lower costs, schools are beginning to introduce this type of educating medium via an application. Metaxas (WWW. 04/2004) talks about the introduction of multimedia applications for educational purposes. With the introduction of these, Metaxas has found that “some of them have been successful, others have not. (Here, by successful we mean the degree that has helped students learn the material that is presented through the applications)”. Although he also goes on to criticize the today's research in 3-D and VR GUIs, he argues that they may not automatically be successful in finding an optimum user interface. This use of 3D and VR interfaces sadly will net be addressed here but rather a more focused view of the material design of the multimedia. What is multimedia?

The use of computers and/or digital functions to present various forms of visual and audio media in a meaningful context, Incorporating: animation, audio elements, CD-ROM, computer entertainment, convergence media, data compression, DVD,


16

graphics and graphics interfaces, hypermedia, text, video, videoconferencing, virtual reality, and an ever expanding list of technologies targeting this growth area.

East of England Multimedia Alliance Ltd, 2000-03 It is quite obvious that this mainstream of Multimedia is an ever enlarging area; where by the use of technology improves our ways of better communicating the information. The information material is at the heart of the Educational Multimedia, into which the use of various types of computer media are brought together to provide a means that can be used to educate the receiver of the desired information. Educational Multimedia presents a huge domain, in that the area is becoming increasingly more complex and vague. Najjar (1997) suggests that the area of multimedia and its effects on learning is somewhat inconsistent and although this media helps people learn (Levie & Lantz 1982) there are times when it is said not to be helpful. When discussing this area of learning through multimedia, and how a measure of the ability of a particular multimedia piece is at teaching, we need to lay down some theoretical basics as a reference. Bransford (1979) and Jenkins (1979) and more recently Najjar (1995) proposed a set of foundations which specify four categories, each supplying a certain aspect on the addressed issues towards how one evaluates learning. These are (a) the materials – the type(s) of multimedia used to convey the information, (b) the learner – the user who is trying to assimilate the presented information, (c) the learning task – the information that is required to be learnt, and finally (d) the test of learning – how well the user has assimilated the information; usually in the form of a test or exam. These references will provide a good starting point into which the design and construction of the multimedia guides can use. Firstly, we must look at the basics of how the learning process and how it is conducted by the user. The area is known as ‘Cognitive Learning’ and the subject looks at the processes of how a person interprets the information given through a variety of senses – for example, the ears, the eyes. However, this mainstream topic is theoretical, and so many developed conclusions come only through gathering empirical evidence. A general definition of ‘Cognitive learning’ is:

Learning is an active mental process of acquiring, remembering, and using knowledge. Learning is evidenced by a change in knowledge which makes a change in behaviour possible. Learning itself is not directly observable.

Woolfolk (1998)


17

This Cognitive theory is the basic metal model used, showing how people use their ‘mind’ to store and remember knowledge. This model forms the groundwork for many Educational Multimedia design and understanding. It allows designers of multimedia to realise how they must form and implement what they will use to demonstrate facts to a learner for him/her to retain this information as best as possible. Let’s briefly look at some aspects of this theory, as this will help to steer further towards the design issues. Let’s look at the three main types of how one absorbs and retains information. The first is ‘Sensory memory’ which is thought to be used when first receiving information. However, this memory only retains the data for very brief times (Woolfolk 1998) unless the information is something that we wish to retain, upon which it is moved into the ‘Working memory’. Woolfolk (1998) Describes ‘Working memory’ as one’s short term memory, where the information from the ‘Sensory register’/ ’Sensory memory’ you are focussing on at one particular moment is stored. Again this memory is only said to be able to retain information for a short while; it is also considered to be ‘easy retrieval memory’. The final type of memory is our ‘Long term memory’, which denotes our memory store. These basic essentials which are thought to exist and operate only represent a model of our memory. Many other authors such Ormrod (1998) and Wollfolk suggest a variety of memory Mnemonics which one uses to help remember data. Before we look at specific types of multimedia and its design, one follow up from these memory basics, is the type of knowledge which wants to be committed to memory. Learning Celtic knot construction is categorised as a procedural Domain specific type of fact: Woolfolk (1998) describes that ‘procedural’ information is “knowledge that is verified when we perform a task”, and secondly, ‘Domain specific’, in that “the information only applies to one situation”. There are a variety of approaches which are considered to be fairly definitive and use aspects of the ‘Cognitive learning’ theory to relate learning as an ability of each user. One of the major proposals which is said to govern multimedia learning is the ‘Cognitive Theory of Multimedia learning’. The proposed cognitive theory is based on some basic assumptions:

‘Working memory includes independent auditory and visual working memories’

Baddley (1986) ‘Each working memory store has a limited capacity’ Sweller & Cahndler, (1994)


18

‘when meaningful learning occurs when a learner selects, organises and connects corresponding verbal and non-verbal information’ Moreno & Mayer (2000)

These statements yielded some preliminary principles (Moreno 2001) of instructional design for multimedia explanations, that is to say that it is the design of multimedia which provides an instructional explanation. The first of the two is the ‘Modality principle’ which describes how verbal information should be presented to users to enhance there learning from animations: audio as speech or visually as on-screen text. It was found that by utilising the independent working memories of a person by presenting text as spoken audio information improved learning; this result was found by experimental evidence rather than a proposed theory. The second principle developed demonstrated that audio narration, which provides very good secondary information, enables one to process visual and audio information at the same time thus constructing coherent storage of the information. But this does have a problem. The problem arises in overloading the ‘sensory channels’ which creates a more confusing environment. A particularly important phrase from Najjar (1998) cited that “The characteristics of the learning materials can significantly affect learning”. Bransford (1979) describes the typical characteristics of the material to be learnt and it follows that these features can be used to provide better ways to design the material to present the user and thus increase the learning value of the implemented multimedia. These ideas provide a good base onto which we can carry out these material learning situations and so let’s look at combining these environments within an interface. Educational multimedia looks at the development of Computer-Human Interaction, where a computer provides an educative learning environment for the user. So, educational Multimedia Interfaces can present a variety of information such as text, audio and visual data to help in the learning process. Najjar (1998) brought forward many ideas about how one should design the necessary interface based on standard empirical testing on users of multimedia. It was found that the interface design can be broken down into some main areas with each providing a critical aspect for the users’ interaction. Although this approach seems logical, the foundations of these experiments are based on the critical starting point of the material being learnt. The primary findings of Najjar were that supplying a greater sense of interaction in the user interface implementations seems to have a substantial and positive effect on learning. Interactive interfaces can:


19

(i) Provide a means for learners to control, manipulate and

explore material learnt, or (ii) Allow the computer to periodically ask learners to answer

questions that help them to integrate the material, or (iii) A combination of both

Interaction may be useful because it encourages learners to elaborate more, i.e. take a greater amount of time to analyse and store the information given at that time. As I worked my way through the empirical testing that has been done by Najjar (1998), it became clear that the supportive evidence is stronger for some guidelines of interface design than for others. Najjar (1998) summarised the findings which start at the strongest evidence for supporting his proposed guidelines: The Strongest evidence lay in:

making the multimedia experience interactive and Creating tasks that encourage learners to actively process (elaborate) the information.

The Moderately evidenced findings were that:

Using multimedia in a supportive, not decorative way, and using motivated learners (the novelty of multimedia can increase motivation initially, but tends to fade over time).

As with all experimental findings, there were some not so promising findings:

Using multimedia to effectively focus the learner's attention, Using the medium (speech, text, and graphics) that best communicates the information and using the medium(s) that best facilitate elaboration.

There is no question that multimedia, used appropriately and not dominatingly, can improve a person's ability to learn and remember. 2.4 Current Applications available There is a mass of available software for automating the tedious construction of the knots, from simple applet designs to advanced 3D rendering applications. Although these applications provide good solutions, we must not forget that the project is not solely looking for


20

an application to create the knots, but a program which can provide educative and demonstrative features. Let’s look at the evident 2D packages where we can take a look at possible construction methods previously used and analyse their benefits. Knot Worker. Software by David Hall, Goldcup Software & Design The application offers a variety of aspects which the user can control to create, quickly, Celtic Knots. The primary control for the Drawn Knots is the ability to edit the Break line positions to create your own pattern structure, which is the primary essence of the Knot work. The most interesting feature is that the user can create multiple patterns and then using the familiar ‘Drag & Drop’ options, one is able to build up complex pictures using the artwork created. The application includes facilities to add graphical effects onto the Celtic art you create. One can alter the colours of the knot, rotate the patterns, and manipulate the layering of the sections. Lastly, the application provides abilities for saving the creations. The software also includes the capacity to create and switch between many different Knot-styles – similar to the described Knot font. Celtic Knot Draw. Software by Saul Scudder Celtic Knot Draw supplies limited functionality, although it does provide some interesting aspects for the knot itself. The system provides options which can alter how the knot is perceived, and the application presents the user with a set of choices which alter the grids perspective, and thus change the way the knot is viewed. The main knot work is fairly fixed in its position but the size of the knot can be adjusted using another menu section. The program offers no functionality to define any break lines or other features which would alter the knot shape, rather the purpose of the program only seems to be to generate random new knots with a defined number of cord crossings.

Celtic Knot Thingy. By Douglas Zongker. This next program utilises the rather unique method proposed by Sloss (1995), where sections of pre-drawn knot work are used to occupy the grid. Once the ‘Break’ Markers are placed down to define the kno t pattern, he then uses an algorithm which looks up, using marker points, to find the relevant tile to be used in that particular grid square. When cords become interlaced, he uses a system of columns, again defined in the grid, to locate intersections, and with this he determines that in alternating columns, the cords will pass over and then under or vice versa.


21

As with all of the above current solutions, each has the ability to save ones pattern when complete. However, very few current applications provide tutorials on the construction of the knot work and at best these tutorials provide only information for using the system. As with the currently available software it only provides a solution to drawing quick Celtic knots, 2.5 Implementation Methodologies There is no right or wrong way to implement a Celtic knot drawing package, but one would see immediately, an implementation in a more so, graphically tending language would have to be a must. However, currently all the drawing packages, provide an interface, which the user can use to control the design of the knot work, some with very little difficulty and some provide limited control over this. The general feeling I get when using the currently available software is that many of the interfaces are basic, with little or no thought in the interaction style, and so this will be the primary goal to seek a more ‘User Friendly Interface’. The project will look to design an interface which must provide an environment from which a user has the ability to interact with the guides and simultaneously with the system; Najjar gives a clear motive that this highly improves the learning quality. The system will be using the gathered properties found to construct the Knot work. The user will be allowed to have power over the main control parameters of the Knots construction which will provide cohesion between the guides and the systems use; the basis that the user will be able to experiment with the system at the same time as the guide runs. However, the project is consumed primarily on the manipulation of graphical elements which will be used to represent the Celtic knots. However, the level of background knowledge essential is very small and so it has been omitted from this review on the basis that an advanced level will not be required for the eventual system. Discussed earlier, the system will be based on using sections of pre-drawn graphics rather than generating them and so reduces the amount of graphical objects required. The interface design will initially require the routine development stages of standard design where the most successful approach is geared towards a user-centred design as this will endeavour to fulfil my primary goal. Certain aspects of a goal-centred design which Cooper & Reimann (2003) remind us that designers often get user requirements wrong. So building on the more substantial elements of modelling the user interaction will provide the final implementation a much more secure and stable program.


22

An Implementation language is the next question, as the final package is heavily restricted on being able to provide a quick interface and a requirement for the language is to provide quick access to visual interfaces to incorporate the multimedia being considered. It must provide the ability also, to include and contain the possible elements of audio and animations. Summary We have looked at two distinct sections, the Celtic knot construction domain in which we have considered the more mainstream types of construction methods and various forms of knot work. Much of the methods we came across, briefly, certain aspects which could be considered for computer implementation with the strongest type of construction leaning towards the ‘Tile method’. To follow up this section, we have taken a look at currently available implementations of existing Celtic knot drawing packages, with emphasis on evaluating there functionality. Many of the existing applications provided some definite functionality which I should retain for my final implementation. Nevertheless, the functionality must not hold down the educative principles I am trying to achieve through the application. And so, at some point there will have to be a balance which I will only know after considering existing packages and incorporating my own input to alleviate the complexity of the problem. The second half of the review concentrated more on the findings of psychologists and, where they use key aspects of ones learning abilities to model just how a person theoretically conducts the storage of information based ideas of ‘Cognitive learning’. This then lead onwards to educational multimedia interfaces, which are aimed at providing a learning environment, and this then conveyed aspects of design that must be used in order to provide a good learning environment. The basis for the proposed system has been laid down. To conclude the review, we looked at the types of methodology for interface design. I have concluded that I shall be using aspects from many different methodologies and this mixture must provide a coherent outcome.

Chapter 3 Requirements

23

Chapter 3 Requirements Sommerville (2001) stated that the defining problem to all software development projects is the ability to derive a clear and unambiguous set of requirements from which the final system can be fully understood and defined. To approach the problem we must seek an appropriate method and structure for our requirements specification, and so I have opted for the structure provided by the ‘IEEE Recommended Practice for Software Requirements Specification’ (1998). Although the standard is not ideal, it contains a great deal of first-rate advice on how to compose requirements, and ways to avoid problems. It is therefore a good starting point for the following requirements analysis and its specification. 3.1 Requirements analysis The primary processes in requirements engineering are concerned with determining appropriate requirements, analyzing requirements for incompleteness, inconsistency and the practicality of each requirement which inevitably evolves into the final set of requirements for the system to be built on. There are two evident approaches to analysis which can be grouped into two categories, ‘Bottom-up’ and ‘Top-down’. ‘Top-down’ approaches begin by defining outcome of the project such as high-level goals and building the lower level parts of the project which lead to that outcome, typically associated with ‘Goal-Directed’ processes which recently have been explored by Van


24

Lamsweerde (2003). The other half begins with low-level knowledge of the system such as employing the use of ‘use-case’s’ (Kulak D. & Guiney E. (2004)). The system will contain a variety of general features. However, the system is composed of two amalgamated parts which include the Celtic knot drawing package and the multimedia tutorial element. By separating the two, it reduced the complexity of the composed requirements and the further design roles in Chapter 3. The Multimedia guides use a technique which is very dissimilar to the process tools that resolve the system requirements. This proved to be very useful as it allowed the projects main objectives to be separated and so any unforeseen problems arising from one objective will not cause any major difficulties for the other. With this in mind, the structure of analysis used for the project took a route using an object orientated development (OOD) approach as the use of case scenarios was found to benefit the breakdown of system specification (Jacobson (1994)). Appendix A contains a sample of the use-cases used for defining key system requirements. Analysis and design in an (OOD) hold a much tighter relationship than in other structured analysis and design techniques and so it was felt that as the project progressed through to the design phase, less effort would be required to transfer the requirements to the design thus improving the success for verification of the system through the project. Let’s start by looking at the basic concept of the proposed software: To provide a user with a graphical tool that will allow a user to generate Celtic knots quickly. To allow the system to generate the knots quickly, an efficient algorithm is required. By looking at the projects objectives, it is clear that we need a system that will contain an executable routine which is run to the construct the Knot. Without this, the application is useless. The selection of the method to be used was based on the level of graphics which would need to be drawn. Earlier in this project, we discussed the typical types of Knot construction techniques used and came across a particular method that used pre-drawn knot sections. It was felt that this choice of generation would have the lowest level of graphical elements to define. The only time that a graphical element would need to be specified would be only in one section of the knot and of course, this can be reused in another part of the knot without identifying any new graphical elements. Interaction with the system to alter the knot parameters considered using a form of input previously used in the currently available solutions to drawing the Celtic knots. The interaction specifies that the user uses his/her mouse to alter the knots graphical representation by directly selecting and moving parts of the knot around on its displayed layout. Although this system does have its benefits of true


25

manipulation, it was dropped for a more conventional style of altering the knots shape parameters. Using a secondary medium between the Knot and its parameters is the underlying technique. The approach chosen was to convey the underlying construction properties of the knot, such as its grid (discussed in Chapter 2) and its subsequently defined break markers. Allowing the user to add and remove the break markers from the grid display will manipulate the Knot. As with some current applications available, they only permit the user to work on one knot at a time. It was selected that the system will provide a means by the user can work on multiple knots at once to help compare parameters used within each. As for the remaining analysis on the other components of the system, it is grouped with its specification (below) defined for the system. 3.2 Requirements Specification 3.2.1 Definitions

• GUI – Graphical User interface

• System – The software component that is being constructed through this project.

• Class – An Abstract Object containing relevant attributes and

Methods in the System context

• Guide - Something that serves to direct or indicate a service 3.2.2 Implementation Language Choice

The choice of language was heavily influenced by the need for strong graphical capabilities. In addition to this graphical ability, the language needed to provide a means of constructing various prototypes to test their functionality before being integrated into the final application.

The choice was made to use Java, and interpretive language, because it fulfils these requirements. The meaning of an interpretive language is that the application code is not compiled down to machine code, but rather it is interpreted by Java’s Virtual machine (JVM). Any target machine which wishes to run a Java program requires this JVM to be active to run the application. However, this does come with its drawbacks and the primary disadvantage of this setup is that the program tends to run slower than a program in machine code.


26

Nevertheless, the requirements for this project specify that we do not need to consider the execution speed and so this consequence is not a concern.

The main reason for Java as the choice of implementation language is the languages inclusive Java Foundation Classes (JFC). The JFC provide a large set of class libraries that support the rapid development of graphical interface components and in addition to this, provide support for graphics and event handling via the Abstract Windows Toolkit (AWT) and the recent development of Java’s Swing package. The recent development of java’s JMF or Java Media Framework will allow the quick implementation of a media player for the support of the multimedia guides proposed. 3.2.3 System perspective The primary aim was to create an automated graphical package for constructing the intricate Celtic knots via the use of a GUI. In addition to this, it was necessary to allow the user to have the ability to customize certain construction rules for the Celtic knot. The secondary objective was the construction of a multimedia conveyed tutorial to educate the user for the use of the primary system and to aid in enlightening the user in the primary control points of the Celtic knots design and generation. It is the intention to provide a means whereby a user can utilize the benefits of a computer aided drawing package, where the user could create Celtic knots efficiently and quickly, having the fundamental controls of the knot design at hand to specify the knot design. However, the system is not an extension on existing systems but rather a way in which the user can learn about the Celtic knot design aspects through a guided multimedia system, with the ability to allow the user to explore the basic elements of Celtic knot design via the automated Knot generator. 3.2.4 System Features 3.2.4.1 Overview The system is identified through the use of a GUI that is required to give the user a visual interaction platform, from which the user can relate information he/she has learnt from the proposed multimedia guides and applying it to using the systems GUI layout and its tools. In addition, this transference from information processing to practical applications is the primary topic which was discussed earlier in chapter 2.


27

A key feature of the system is to provide a means by which this will allow the user the ability to build Celtic knots. Appropriately the system must intuitively display the generated knots, and from here the system permits the user the functionality to edit and manipulate the knot work. Built upon this idea of manipulation, the system would allow the user to save the currently drawn knot and so further alterations could be achieved later in time. 3.2.4.2 Creating Celtic knots The primary functional requirement for the system was to allow the user to generate a graphical 2D picture which is thus known as the Celtic knot. The formation of the particular set of system requirements situated around this graphical generator took shape based on the typical characteristics of the more general Celtic knot patterns (see below 3.2.3.4). The system must enable the user to choose between two generation methods, one which the user can use to generate a random Celtic knot, whereas the second choice is to permit the user to specify certain knot characteristics before it is generated. The first style of generation was required to accept no input from the user except the initial choice to generate the knot, to which the system was required to use randomly generated values for each parameter. A secondary requirement was that the system must not generate values outside the maximum parameter size specified by the system at compile time. The second approach of production required the system to allow the user an input phase to define certain features before it is generated. As with all user input, the system was compelled to validate all input values. The input from the user was required to contain three aesthetic parameters, cord width, cord colour, cord Line colour and background colour. The other main input value from the user was required to be the main break marker specifications and the system was obligated to provide a graphical interface for this. The second style of generation from the system was required to be initiated by the user but it would not require any input parameters from the user; however, it was felt that the system should be required to allow the user to manipulate and edit the drawn Knot once it has been generated. 3.2.4.3 Knot manipulation The system was required to project to the user the control parameters such as Knot break markers, cord colour, cord width and knot background colour. As a result the system was obliged to provide a


28

mode in which the user has access to the knot parameters. Evidently, the system was required to host these parameters which the user can manipulate through input from the keyboard and mouse. In addition, the system was required to provide update confirmation to any changes the user enters. In addition to this, the system was required to ensure that the entered values were within a given validated set and to indicate to the user any invalid input. With all Celtic Knot work, exist illegal positions for the break markers and so the system is required to, if any illegal markers are place, to warn the user. 3.2.4.4 Help System One of the main aspects of the system was to provide the user with an interactive help and guide system which would demonstrate the various tools of the completed system through the use of multimedia as evaluated in Chapter 2; the requirements for these guides are explained later in section 3.3. Secondly, under the secondary objective for the project, was that the system was required to provide a system which can be used by the user to play and control the flow of educational multimedia within a separate system (described below) that was required to convey background information on the Celtic Knots. 3.2.4.5 Media player As a secondary objective, the system is required to provide a tutorial sequencing player which the user can use to control the flow of the multimedia guides. It was required to be simple and intuitive but must provide the basic elements for control, such as, Play, Stop, Pause and close. As discussed early in this project, allowing the user to explore the material was at the forefront of the requirements. By structuring the guides in such a way that the user is required to be asked questions on material that he/she has been presented and provide adequate experimentation time on the material and tools within the system. 3.2.5 User attributes The systems primary end user would be someone of any I.T. competency, although a familiarity of basic GUIs was essential to run the system and distinguish elements of the system, although, if successful, the tools of the system will be sufficiently described to the user through the proposed guides.


29

3.2.6 Operating environment The final stages such as Implementation and testing took place on a Microsoft based Windows operating system, therefore it lead to the formation of the operating environment requirements to be equivalent. This focus also represented a beneficial factor, in that the later development stages such as system design benefited by the standard Microsoft layout attributes for the systems user interface design, although many issues are present with the Microsoft standard, many system users will already be compliant with the interface formatting. The final requirement for the operating environment is clearly an environment which will support the graphical display of the eventual system. 3.3 Multimedia Specification Many aspects of the requirements elicitation and analysis techniques for the above system features cannot be used to formulate what is required to develop any sort of multimedia representation. However, the techniques typically used are somewhat in a state of flux with new ideas but the course of this project will see these techniques used, which have been discussed earlier (see Chapter 2). These should provide a good base for later development stages such as its design. As for now let us briefly look at the specifications for the included material. 3.3.1 Information The types of multimedia required for the system were divided into two groups, the tutorial sequences and the system guides. Although both are related to the system, the latter of the two is more system specific in that it provides system guides to the tools provided. The three main target tutorials, listed below, make up the majority of the multimedia within the system. 3.3.1.1 What are Celtic Knots? The basic tutorial sequence was required to provide the user with the background information to the Celtic knot and to give the user information regarding their history and decorative power. It was also required to give a much broader range of the types of Knots being drawn. At each junction of information, the tutorial was required to stop and ask simple questions to test the knowledge of the user he/she has just viewed. This has proved to be a technique to use (Chapter 2) to evaluate what the user has processed so far. It was also required to provide an interaction for the user to select the


30

additional material if the user has not successfully scored high marks in the sample questions. 3.3.1.2 How to create Celtic Knots within the system? The first of the two main system guides was required to enforce a direct mapping onto the system and provide an audio-visual reference to the actual application itself. It was required to demonstrate how a Celtic knot could be constructed within the system via the two generation methods specified in the application. This would in tern provide the user with a better mental model of the systems use; again this is a guideline which has proved to be successful, described in more detail in Chapter 2. 3.3.1.3 How to alter Knot parameters within the system? Similar to the previous guidelines but the required information was specified to look at the four main knot parameters, and so was required to be subdivided into its constitute elements so as not to ‘overload’ the users auditory and visual memory at one time.

Chapter 4 Design

31

Chapter 4 Design As with all developments of software, the transference between system requirements and system design is the most complex part. Many methodologies created for the development of software have evolved to provide the best means of success, but as the ever changing complexities of software occur and so it has become increasingly difficult not to fail. This project took the route of using concepts built upon OOD techniques, from the initial analysis to implementation. 4.1 Methodology From requirements analysis to design, the methodology used for this section was based around the techniques provided by Jacobson (1994). After employing his defined use-cases, the systematic breakdown of these using his proposed analysis model was carried out. He defines three types of objects in a system: interface objects, entity objects, and control objects, which describe how a group of objects will collaborate in a chosen system state - typically a single use-case. Since the system is not complex, this stage of design was relatively simple and after defining the system objects, an Interaction diagram of these system components was drawn up (see Fig 4.6) to show how messages would be traded within the system; similar to UML sequence diagrams.

Chapter 4 Design

32

4.2 System Architecture The User interface is central to the system and provides access to two forms of interaction, Celtic Knot construction or running help guides. The first of the two interaction forms allows the user to generate, edit and remove knots from the graphical screen. In order for the system to perform these functions, the system uses a graphical generator object which is built up from various data parameters spawned by other objects. The Help system which runs parallel to the tutorial sequencer provides the user with the multimedia help system that will incorporate the proposed properties discussed in Chapter 2. 4.3 User Interface The interface encapsulates each mode of interaction with the system and with the use of simple paper based, low fidelity prototypes its overall view was establish. The interface structure and its designs can be transferred directly to the implementation stage and using the paper prototypes as the basis for the interfaces layout. The User Interface provides the basis for all interaction between the system and the end user, so it was felt that the design of the interface would benefit by being divided into four main components, the main screen, the Multimedia screen, the Knot screen and finally, the generator screen. The main screen was designed to allow access to all parts of the system functionality. This included generating knots, control over certain parameters of the generation process, the manipulation of the

Chapter 4 Design

33

generated knots, running help tutorials and to save and reopen currently spawned knots. Running as a window within the main screen, the Knot screen’s functionality was to contain a generated knot submitted by the user. The Knot screen needed to provide the graphical representation of the knot which the system used to generate an animation of the knot drawing process by sketching out the visual image of the knot once generated by the generator class. Finally the Multimedia screen provided the capacity to allow the user to run the multimedia tutorials, as well as to skip points, pause sequences and rerun the sessions. The above three sub interface designs are detailed below as well as the specifications for the more important program classes. 4.3.1 The Main Screen The primary Design feature of the project was the Main Screen. It needed to ensure that the user could perform all the required tasks such as generating Celtic knots, loading and saving knots, and in addition to this, editorial responsibilities; additionally to provide access to all the systems interaction modes. It must also have the ability to switch between the two identified primary sub-systems, the Tutorial sequencer and the drawing package but also allow the two systems to run synchronously and provide the means to switch between multiply drawn knot Windows. 4.3.1.1 Menus The menu bar is designed to hold simple commands which the user can access easily. These operations would allow the user to gain access to some system functionality that is not present within the main screen. The menu bar itself would hold three main menu items, File, System and Help. The File menu contained commands to create, load and save Celtic Knots. Following the convention for File menus, the Exit command was also placed in here, and allowed the user to shut down the system at the end of a session. Secondly, the System menu item would contain focused operations which activated the different types of Window which are displayed within the system area. The options are: Tutorial, which would display the Tutorial sequencer for running the multimedia available to the system. The second: Draw knots, would present the user with the Knot generation system. As with both choices, the commands from this menu item were obligated to spawn a dialog box

Chapter 4 Design

34

in which the user must confirm the commands activation; especially when changing from Drawing knots to tutorial sequencer so that the user can save the knot before continuing. Finally, the Help menu includes two items. The first for evoking the multimedia guides of the functionality of the system and secondly, the menu item ‘About’ which included the systems version and creator; slightly less important. 4.3.2 The Multimedia Screen The Tutorial mode displayed in Fig 4.6, once active, alters the mode of interaction with the user and adjusts the interface layer by creating a multimedia player. The particular screen created is the Multimedia screen which houses the mult imedia sequences and contains the sequencer controls which are used by the user to control the flow of the system guides. The main area of the screen holds the sequences where they are played out onto the monitor. The sequencer controls design was taken straight from the standard layout that is incorporated into all products that require these control selections. This meant that the controls were very easy to learn. Below is a depiction of the typical layout, Fig 4.3.

4.3.3 The Knot Screen Once the system spawns a new Knot screen in which the mode of interaction here is the editorial mode, allowing the user to make alterations to the Tiles and the break markers (Depicted in Fig 4.6 ), the systems interaction mode changes from the ‘generation mode’ to this ‘edit mode’. The knot window was designed to incorporate both the Celtic knot that the user generated internally and the options to provide manipulation for this knot. In addition to this, the Knot screen needed to provide the graphical representation of the Knot itself. The design of this environment provided the user, having operated the appropriate generation option, could visually see the Celtic knot and its parameters. The design of this Knot screen specified that the left of the interface would house the visual representation of the Celtic knot. To the right

Chapter 4 Design

35

of this, the screen would contain the knot parameters that the user could use to alter the knots shape and aesthetics, e.g. the colour scheme. At first it was thought that this area should be sub-divided into two sections, one for the pictorial representation of the knot, and the second to cover the knots parameters and editing roles. However, this would mean that the separation of the screens would confuse the user as to which ‘Knot screen’ would go with which ‘parameter screen’. Since the application will allow multiple knots to be drawn and displayed at once, the parameters that control the Celtic knot perspectives would be jeopardised and our secondary goal would suffer (see chapter 2). The design of this particular part of the system ran parallel to the design of the Generator Screen (see below 4.3.4). As the system was designed so that the generator screen could be used to house the generation of the Celtic knots when required by the system and in addition, its’ secondary design goal needed to ensure that the system could reuse its form to provide a base from which the user could alter the knot parameters directly from the Knot window; I shall not describe the Generators design aspects here as they are depicted below. The last points to mention here are that the interface is designed to incorporate two buttons situated south of both the two main windows. One for resetting the entire window; the system needed to provide a dialog to confirm the reset action before saving the current Celtic knot. The second button was designed to allow the user access to the Knot within the window. Its function is to update the Knot with the currently set parameters; if no changes have been made by the user, the button becomes inactive to signify that the user has not made any changes. 4.3.4 The Generator Screen The generator screen is available in two modes of interaction within the system - The ‘generation mode’ and its subsequent ‘edit mode’, however, these different modes have no effect on its displayed layout. The Generator screen provides an interface between the user and the underlying methods and attributes for controlling and producing the Celtic Knots. The key design element verified through by means of using the low fidelity prototypes, namely paper prototypes, helped to posture ideas about how the interface would look and its functionality. The main concern for the interface was that the eventual screen would act as a means for the user to generate and manipulate the Celtic knots through the knot window, and so the system needed to be able to distinguish between an editing system and a generation structure.

Chapter 4 Design

36

This design issue was eventually resolved by using a system of flags to tag each Generator (see 4.4.3 The Generator class for more information). The interface needed to provide an output preview as a user alters the parameters for the Knot colour scheme and so this design feature was accommodated with the use of a single Tile placed into the interface layout. When a user alters any one of the given parameters, the system will update the Tiles visual representation by sending the update data to the Tiles object associated with the generators preview section. The parameters which can be altered and are required to be updated are - Background colour, Cord Width, CordLine Colour and Cord Colour. As the requirements stated, the system must validate all user input to check that it is within the working parameters of the system; however, the design saw that by using drop-down selection boxes, this would be averted and so all input is defined by the system; the user is limited to pre selected data. The preview layout that will be used is depicted below in Fig 4.1. However, since the generator screen will be providing two modes of interaction this update property for the single preview Tile will be taken into account if the generator object is associated with a drawn knot or in generation mode; again this differentiation process for the Generator class is given later in 4.4.3 The Generator class.

The interface also needed to provide a simple system to separate the cord colour scheme, and break marker sections but still allow the user to quickly switch between the two. The basis for this choice was that it would help the user to concentrate and focus more on each separated section, rather than providing to much information at once. The Break marker section of the interface, where the user defines the knot break markers, needed to establish a connection reference with the generated (or to be generated) knot, and so the system is to provide the layout grid of the knot (or the knot to be). As the user moves the mouse over each grid intersection point, the system visually represents to the user that the mouse is over a clickable part of the grid which can be selected. The design of the system also

Chapter 4 Design

37

needed to ensure that when the user wanted to place a marker into the grid, via the mouse, the interface would respond to each click by placing a red marker point onto the grid intersection that the user had clicked on; if the position of the mouse is not over the defined intersection point, no marker is placed. Once the system detected that two placed marker points are adjacent to each other in the grid, the interface would respond by placing a break marker line between the two points in the grid. The interface to the system was then required to update the necessary data fields embedded in the generator class ready for the user to update the Knot. At which point, this data is cascaded through the re-drawn Knot Tiles and on to complete its defined structure. 4.3.5 Multimedia Help The system needed to provide the user with a help system that the user could use within the main system area. Unlike text tutorials, the system was designed with more interaction. In fact the help guides provide a form of demonstrative interaction, rather than the system providing the user with a simple ‘read’ text based guide. This will allow the user to ‘watch’ the visual guide and experiment on the system simultaneously, if needed. Each guide proposed in the requirements section was designed using an audio guided, visual direct mapping onto the systems layout view. Although this approach is described negatively in Chapter 2, it is felt that this direct mapping onto the system would in fact encourage a good visual memory mapping of the system and its tools. The two main guides proposed for the system were the Generation tool and the main editorial tools, both of which the system needed to specify within the Help system. The multimedia material is specified to reside on the local systems File system, upon which it can be called up from the application when required and manipulated accordingly. 4.4 Class Design 4.4.1 Overview The foundation of the Knot generating package includes the Tile, which provides the graphical representation of the knot sections that is arranged to give the final Knot (see Chapter 1). The choice for using Slosse’s (see Chapter 2) method of predawn graphics would take more of an organizational structure on the Celtic knots construction rather than drawing the graphics straight onto the “Canvas” as other Celtic artists currently do for paper based art. Although this method switches

Chapter 4 Design

38

the role of manufacturing the graphics for the knot from scratch, what was proposed was to create an algorithm that will organize predawn sections of the knot into a comprehensive Celtic knot. Below is a summary of the design aspects for the Knot generator class and the Tile class with the design portion of how editing will be conducted. Other classes within the proposed system are omitted as their design was trivial such as the Knot window, as its primary concern is simply to provide an interface to the other functionalities given. 4.4.2 The Tile Class The Tile, as seen in Fig 4.6 forms a data store within the proposed system. Its interaction with the system serves only to receive its activation and using its received parameters to be created and subsequently be displayed. The data stored within the Tile is based on previously drawn Celtic knot sections which when formed correctly establish the Knots shape; this formed the basis of the concept used during the design of the generation algorithm (see 4.4.3). The Tile class is atomic, meaning that the class does not contain or depend on other classes, but contains the actual graphical data such as the cord line within the knot and its colour scheme. Since the system would be using the single definition of our Tile, the attributes and methods are designed with a general focus. The primary four attributes were cord colour, cord line colour, cord width and background colour. These attributes are defined when its associated activation occurs. This meant that all internal attributes within the class are only created and accessed at construction time. A description and use of these attributes is as follows. The design saw that there existed five main Tile types (Depicted below Fig 4.2), from which all other Tile types were simply reflections or rotations of these. The Tile class will house all the graphical elements of all the different Tile types found. It is vital that the class can distinguish between all the possible sections of the knot as each is required, otherwise the class will display itself incorrectly. To avoid this problem, the class is designed to contain certain methods that control its illustration properties at construction time. Based on the required type it receives, this will distinguish its type, and so will lead to a correctly supplied Tile. Before we discuss this further, we need to look at the other properties that each Tile type has below in Fig 4.2. Notice that the Tiles which contain the extra line within the Tile’s corner, this represents the corner on which the cross over will take place.

Chapter 4 Design

39

With this established, the Tile Class would contain a series of attributes to decide on its orientation. These attributes decided in which direction the Cord was drawn in, and so the Tile was designed with specific edge names to orientate the flow of the cord through the Tile; e.g. the four compass directions, N, S, E and W. These would allow the system to generate all the possible Tile types. However, there are two Tile types that require an extra method (the Tiles which contain two cords within their walls) which at the final stages of generation will be used to form the crossing points, i.e. the ‘over-and-under’ elements. Depending on which type of crossing is required, the input to the method will evoke the appropriate graphics to be drawn. The Tile encompasses the vital graphical components from which the Generation algorithm would subsequently used to display the Knot. However, Tile type is modeled to provide the generation algorithm an appropriate ‘type for position’ within the eventual grid; this is described in the algorithm below. A crucial factor in the Tiles design was that the graphical element had to be constrained so that when the Tiles are put together the connections between all the Tile cords line up accordingly. This was simply done by ensuring that the cord graphics always begin and end equally proportional to the middle of each Tile edge. As for the diagonal cord paths, this rule still applies as each cord line still is equally proportional to the middle of each side; only now the two drawn lines are spaced from two different edges. 4.4.3 The Knot Generator Class The Knot generator class hosts the most important construction data for the application. It maintains the most important position within the application and is at the forefront of the systems eventual interaction. After considerable thought, it was felt that this class would host a series of objects. From this, a sequence of development processes would take place to generate the knot parameters and onto the knot itself. The design of the generator class was important, as this class would inevitably produce the knots. The breakdown of the class took form via dividing the process of ordering and arranging into two separate parts

Chapter 4 Design

40

to lower the complexity of the generation process. If we consider the Knot itself, we see that there are two fundamental aspects of all Celtic knots; one, the shape formed by the weaving cord(s) and second, the interaction between two cords crossing, or better known as interlacing (discussed in Chapter 2). And so the outlining methods contained in the class design itself, conceived through the analysis process, lead to the subdivision of the problem into the two processes (stated above). The first process that the generation method needed to perform was arranging the tiles in our given grid to give the actual shape of the Celtic knot. The focus of this design problem was based around a ‘type to position’ technique, which it’s self is based around a lookup table or a system of conditional branches to distinguish where a Tile should be placed into the grid. Each grid segment is defined by any break markers that that particular grid sector is encapsulated by and this encapsulation is the basis for the algorithm. Consider an example (Fig 4.5) of a grid segment which has two break markers. This particular sector can only house one type of Tile and so it is simply a case of finding the Tile which will fit the sector. The second defining feature of each grid section will be that of two simple corner posts, unseen by the user, but are used by the system to distinguish the direction of the Tiles cord that needs to be placed. Grid areas which do not have any break markers attached become sections filled by a default Tile; again the Tiles cord direction will vary according to the orientation of the systems virtual ‘corner posts’. The beauty of the system is that the generation algorithm simply looks in the table and compares the grid section it is looking at, to find which Tile to place there.

The second process is far simpler than that of the first procedure. Now that we have our grid filled with the Tiles, the knot is one stage from being complete. At each intersection on the grid, we now need to resolve the appropriate cross over pattern and evoke the method within the Tile objects that will draw it. The system will place alternating cross over types in each coulomb starting from column one and working across the grid. This ensures that we always obtain alternating cross points, essential to the Celtic knots characteristics.

Chapter 4 Design

41

Let’s now look at a possible algorithm for generating the Knot which will proceed along the following lines.

1. Retrieve the inputted user data to the generation algorithm or subsequently, send the system chosen parameters.

2. Construct the Knot window and place it within the application

screen and hold a direct reference link to this window.

3. Begin placing Tiles into the knot window starting from row one and column one. At each position reached, obtain the break markers which have been placed around this grid reference from the users or systems input and the defined corner posts. Use this information to search the lookup table to find what type of Tile to place. If grid position contains a crossing Tile type send a message to Tile object to initiate cross point draw method. 3.1 If an odd numbered column, draw ‘over-under’ graphic. 3.2 If an even numbered column, draw ‘under-over’ graphic.

4. Use the information returned from the lookup table to generate

the appropriate Tile object. Add the Tile object to the grid position currently processing.

5. Increment along the column of the grid by one and repeat steps

3 to 5 until we reach the end of the grid.

6. Increment along the rows of the grid by one and repeat steps 3 to 6 until we reach the end of the grid.

In addition to generating Celtic knots the system needs to be able to distinguish whether the generator class is in an ‘edit mode’ or ‘generation mode’. The consequence of this meant that the system required a type of flagging system. The system would use a simple check routine which would be run whenever the user or system accesses the methods within the generator class to see if the class holds a reference to a Knot window or not. If the reference exists, the generator class will know that it should not generate a new knot but only update the Tile objects within its specified knot window. However, if any break markers have been altered through the generators system, the generator class will know that a new knot must be constructed and so it will discard the referenced knot and reconstruct the Celtic knot with the updated break markers in place and so again the generator will be re-referenced with this new knot; in addition, this reference will be used to save and re-open Knots.

Chapter 4 Design

42

4.4.4 Editing Knots Within the systems interaction, depicted in Fig 4.6, lye a series of underlying messages which allow the system to communicate the various parameters needed for the system to run. When creating and editing the knot parameters, the selections made by the user for the Knot will be encapsulated within two primary data objects. The introduction of the Tile parameters and its counterpart, the Knot parameters , made the editorial tasks relatively simple to design; note that when editing or creating a knot from the user selected knot parameters, they are not editing directly editing this object. 4.4.4.1 Tile Parameters Designed to hold data, the Tile parameters object is used in two interaction modes within the system. It is created when a new knot has been initialised to be drawn and is updated when any alternations are made to a drawn knot. It will contain the data which defines the size of each Tile used and will contain the information regarding the aesthetics of the Tile: Cord color, CordLine color, Cord width and Background Colour. 4.4.4.2 Knot Parameters Within the systems interaction, the Knot parameters object is generated simultaneously to the Tile parameters object. Again, its interaction within the system follows what has already been described; however, it holds the defining parameters of the knots shape, the break markers specification. When the system detects any updated Knot parameters which the user has entered, the required data he/she selected is passed. Once the data is submitted by the user, the design specified that each field in the generator interface – for example colour and dimension, it would be subsequently transferred to the overall generator algorithm, upon which update changes would take place to the Knot. As for any changes to the knot shape, as described above this information is dealt with by the generator quite unlike the other changes, in that a new knot is assembled.

Chapter 5 Implementation

43


The following Chapter gives an overview of the more important implementation decisions took for the project and will tend to omit the more tedious aspects of implementation. Additionally, the selected language enforces the choices made in the design methodology, and so the implementation language provides the final level of design to support the approaches discussed in Chapter 4.

5.1 Overview The design stage specified the majority of the primary classes which can be found within the source code of the application but in this section we look at their implementation and the decisions took on there construction; see the Appendix B. The system is composed of ten classes, three of which are self dependent and are only used as data stores which help encapsulate information messages within the system; these include the Tile class, the Tile parameters and the Knot Parameters class. All but one of the remaining classes make up the core of system, with the final class which only has one purpose, to initiate the application and run the system within a new Thread; a Thread is used to allow the application to run independently from the already running programs on the host machine.


44

The Main Screen class is initiated on the applications start-up and provides the primary interaction space. When the user has selected to draw a Celtic knot from the system via the two designed methods, the system creates a new Knot Generator object. Once the initial input parameters are specified, a Tile Parameters and a Knot parameters object are created and sent to the Knot Window class. The new Knot Window that gets instantiated contains a Knot Panel object that displays the Knot generated by the sequence of Tile objects specified by the parameter objects it receives at its initiation. Referenced to the Knot Panel and the Knot Window objects, is the Knot Generator object that is also created when the Knot Window is produced. This object references a new Break Marker object to allow the systems mode of interaction to be changed to suit the editorial mode. 5.2 Creating Celtic Knots

5.2.1 The KnotWindow The KnotWindow is the highest level of containment other than the applications running environment. The functionality of the KnotWindow is to contain all elements of the Knot drawing process which use and store the defined input from the user (described later in this chapter). This includes the Knot Generator, an input interface to the parameters of the Knot and to hold and display the generated knot. The knotwindow was required, as defined earlier, to be instantiated many times, allowing the user the ability to manipulate and edit multiple knots simultaneously running within the main application view. The application is based around this necessity and so provides this base for the Knotwindow(s); however for a number of knotwindow classes to be added and manipulated a particular type of inheritance is required within java’s class libraries. Java provides the capability in the form of a JInteranlFrame, part of java’s swing package. The JInteranlFrame class allows any application to add multiple JInteranlFrame’s to its view, however, when adding multiple windows, java, by default, adds each JInteranlFrame at position (0,0) (this corresponds to the top left hand corner of the Frame) within its parent components view. So if its position is not altered by the user before adding an extra KnotWindow, the system will place the new window on top of the other. A way round this problem was to add a counter which would relay how many knotwindow’s have been created and added at a given point in time. The next step was that this could be used to calculate an offset position from the default of (0,0), to any possible position. The choice to use an increment value of 30 for the X position and 30 for Y was an


45

arbitrary decision; below demonstrates a portion of the constructor within the KnotWinow object which is executed when it is instantiated and added: ... static int openFrameCount = 0; static final int xOffset = 30, yOffset = 30; ... . this.setLocation(xOffset*openFrameCount,

yOffset*openFrameCount); ... The primary reason that our counters have been made static is that by defining them in this context allows these values to be accessed externally from the Knotwindow and so its value does not need to be referenced. 5.2.1.1 The Knot Panel The primary algorithm for aligning the Tile’s is stored within this objects attributes and this is the sole purpose for the object. Using this style of creation allowed the system and the generator class to create and destroy the knots quickly. Rather than allow the generator class to edit the knot directly, it was found that by simply replacing the current knot panel and destroying the old was much simpler in its implementation, secondly it provided much healthier maintenance results as there are no update routines to consider, only construction routines. This implementation decision did overpower one of the projects design decisions but the trade-off was considered to be of a higher value. As the panel it’s self is simply a storage container, and requires only to display the Tile objects added, it was found that using a simple JPanel would fulfil the design specification. Upon initialisation, the Knot Panel receives a KnotParameters object and a TileParameters object which contain the dimension of the Tiles needed and there appropriate colour scheme, in addition to this the breakmarker data as well. The entire structure of the Knot Panel is composed of a sequence of conditional statements embedded into a loop within its constructor method; the constructor() method is run when any object is initialised. Each run of the loop results in a new Tile object to place within its component; the loop starts from the top-left and runs through to the bottom-right of our breakmarker array. Using the constructor in this way helped build the knot work quickly and efficiently, with little complexity. When adding components (Tile objects) to a specified container, java’s swing package requires that each component, before it is displayed,


46

must be validated to check that all containers within its interior have been confirmed and that no abnormal contents exist; as specified by JavaTM 2 Platform Std. Ed. v1.4.2 (04.2004). For each component, java specifies a Layout Manager that arranges all components within the container; secondly, it also validates the container. Java provides an extensive library of Layout Managers, each capable arranging the components in a variety of ways. A particular type of Layout Manager selected for this panel was the GridLayout Manager which positions the components in a rectangular grid of equally sized rectangles; specifically, this grid will be made up of equally sized squares and was chosen specifically for this. The Layout Manager for the JPanel is created and is set using the JPanel’s setLayout() method as follows. ... . GridLayout gridLayout = new GridLayout(); this.setLayout(new GridLayout()); ... As each pass through the loop occurs, the breakmarker data is compared with each branch of the conditional tree and is used to zero in on the Tile required. Once the execution path reaches an outermost branch, the Tile is found and as a result, the associated Tile object is created with the use of the TileParameters object. Subsequently this is added to the panels’ environment; at which its set gridLayout manager will arrange its position. The choice of using this type of elimination to find the Tile to place was found to be less complex than using a lookup-table. A trade off between efficiency and simplicity resulted in opting for a less complex means of identification rather than speed. 5.2.1.2 The Tile The Tile class contains five main construction layouts, each of which assembles a different type of Tile specified in Chapter 4. Each type utilises the concepts brought forward from Chapter 2 and as discussed in chapter 4, in that the lines drawn use a simple system of mathematical coordinates to define the different curves and straight lines. Utilising the java2D package, a variety of graphical objects can be instantiated to execute pre-programmed methods to construct each Tile Type.


47

The Graphics2D class extends java’s Graphics class to offer more sophisticated control over such graphical elements as geometry, however, for this project it provides the fundamental class for rendering the 2-dimensional shapes for our Tile’s. When creating a Graphics2D object, the GraphicsConfiguration specifies the default transform for the target of the Graphics2D (JavaTM 2 Platform Std. Ed. v1.4.2 (04.2004). It’s default transform aligns the user space coordinate system to screen coordinates (the screen pixels) so that the origin (0,0) maps to the upper left hand corner of the target region or parent component with increasing X coordinates extending to the right and increasing Y coordinates extending downward. This allows a high degree of control as to where the defined shapes for the Tiles are positioned. To use Java’s 2D API features, the Graphics object passed into a component's rendering method must be cast to a Graphics2D object. public void Paint (Graphics g) { Graphics2D g2 = (Graphics2D) g; ... Generating the different types is simply done by changing the stroke and paint attributes in the Graphics2D context before rendering takes place. This allows the system to negotiate the colour scheme for the Tile object and the size of the shape to be drawn to fit its final destination. Once the rendering context is set, a call to one of the Graphics2D rendering methods can be made such as draw(). A total of three types of shape were used in conjunction with the draw() method, they were, drawLine, drawArc and a combination of defining a QuadCurve2D and its relevant rendering method. 5.2.2 The Generator

This class encapsulates the Knot and Tile parameters and provides access to the parameter objects through an interface layer. As discussed in Chapter 4 the system needed to provide the ability to separate the input parameter layers from the user but still allow switching between the two with one simple action. This characteristic and ability is found inherently in tabbed panels. Java provides this capability in the form of the JTabbedPane , again part of the Swing package. The JTabbedPane class provides a component which looks much like a group of folders one would find in a filing cabinet. Only one folder can be selected at any one time and the information in that folder is only visible when it is selected. Therefore, a JTabbedPane was implemented with two panels, the first entitled ‘KnotColours’ and the second, ‘BreakMarkers’. Each folder needed to display the relevant interface layer but each layer has been classified separately; the first


48

tabbed panel is defined internally as the second tabbed pane was constructed externally to the JTabbedPane as well as being added separately upon the generators instantiation. The user specification of the Knots colour scheme, presented in the ‘KnotColours’ Panel was designed to provide the user with an interface to the underlying colour scheme. Since all input from the user was required to be pre-specified to remove any user input error, the choice of the input style was to use a simple selection box, namely, java’s JComboBox. Pre-defined objects within the JComboBox restrict the user only to the selection provided, consequently fulfilling our input objective. The JComboBox’s used to specify the colour settings needed to be customized to allow the internal structure of each selection box to display colour. As well as this, input from the user needed to be detected by the system to allow the Generator class to retrieve the input selected; the generator class needed to listen for user interaction. A listener is an object that is notified when an event occurs’ (Schild 2002). In order to make an object such as our Generator object react to events created by the user, such as selections made, it needs to firstly be ‘Listening’ for events and secondly be able to deal with the event. Java provides a variety of possible ways in which an object can do this, however, the most important When a class implements an interface such as an event listener, it is often required to provide and thus, override certain defined methods which the interface defines. In the case of the MouseListener interface a total of seven methods are required to be implemented and overridden, although, in the context of this project the more important methods are only mouseClicked() and mouseMoved(). However, java also includes a particular class , and Abstract class, which provides empty implementations of all the included methods and so one simply needs only to override the desired method(s). This alleviates coding implementations of all methods even if some are not essential. Defining Abstract Listeners, unlike interfaces, do not require the new defined object to implement the listener interface; rather, it is required to extend the abstract class listener. The actionPerformed () method is called whenever the system detects an action which has been performed on a component that has an associated ActionListener. In the case of this system, each and every component has its own unique event listener object, each defined from the associated type of Abstract Listener. The choice to define separate inner class listeners for each component was to improve maintainability and improve efficiency with the code. Rather than clustering a large set of methods to deal with all types of


49

events caught by there listeners into a single event handler. This sort of structure would consist of a variety of conditional statements within the handler to execute each components branch and its resulting protocol. However, if any alterations are necessary, changes can become complex and may lead to errors within the new code. A typical example of the defined listener class is given below. . ... class Knot_Window_Close_Knot_Window_actionAdapter implements java.awt.event.ActionListener { Knot_Window adaptee; Knot_Window_Close_Knot_Window_actionAdapter(Knot_Window adaptee) { this.adaptee = adaptee; } public void actionPerformed(ActionEvent e) { adaptee.Close_Knot_Window_actionPerformed(e); } } … 5.2.2.1 The BreakMarker Panel The panel is simple in its implementation Input from the user comes in many forms of event, but in particular, input through the use of the mouse. The following panel is used to construct the KnotParameters object and its subsequent alterations. The panel listens to two types of event to allow the user sufficient input power, both of which are types of MouseEvent. This is important because the MouseEvent object contains detailed information about the event such as the location of the click, which can then be used to perform application specific actions. One of the key uses for this is user interaction and in particular, user interaction with the graphic elements sketched by the BreakMarker panel. To allow the user to interact with the graphics drawn and displayed, one needs to be able to determine if the user has clicked on a drawn graphic component. The Graphics2D hit() method provides a way for you to easily determine whether a mouse click occurred over a particular drawn shape. Alternatively one can retrieve the location of the mouse click within the parent component and execute the


50

contains() method on the shape in question to determine whether the click was within its bounds. This method of detection is illustrated below in the CheckHit() method which uses the information gathered within the mouseEvent to determine if a rendered component in our breakmarker panel has been ‘hit’. public Point CheckHit(RectanglePoint[][] points,

MouseEvent e){ for (int j = 1; j < Rows; j++) { for (int i = 1;i < Cols; i++) { //Test for hit if (points[i][j].rect.contains(e.getX(), e.getY())) return new Point(i,j); } } } return new Point(); ... With each user-interface exchange, the breakmarker panel is updated accordingly, drawing any defined breakmarker lines that have been establish; any two markerpoints adjacent vertically or horizontally that have been clicked within the breakmarker panel creates a new break marker line. This information is updated within the KnotParameter object immediately so that the system has at any given time the most recently defined knot characteristics. As break markers are placed within the panel, the system was designed and required to verify all input from the user, rather than allow the system to store invalid input. Illegal breakmarkers defined by the user are prompted by the system to notify the user of the mistake encountered. The system must cease all input unless the user has acknowledged the error. This form of interruption is carried out by the system using a JOptionPane, a particular type of frame that overrides all other input within the system when activated. Upon which the user must click the ‘Error acknowledged’ button situated on the JOptionPane to resume system use. An essential part of many systems is to provide adequate feedback and so the choice halt all system input will focus the users’ attention onto his/her mistake before the user is allowed to continue. 5.2.2.2 The Knot Parameters The Knot Parameters class is one of the core objects that are used within the application. The object is defined only to hold the key characteristics of the Knot such as the knots size and grid square


51

width and height. However, the most important part of the object is the KnotMarkers, a two-dimensional array which stores the defining features of the Knot. Its principle feature is that in each particular point that it stores, lays a String (word) of length one to four characters long. This string provides the basis of which Tile object to place in our KnotPanel when constructing the Knot work.

Consider the above diagram, as each selection is made through the interface, each corresponding point within the two-dimensional array is given a value, and this depends on the alignment of the BreakMarkers. As the above example demonstrates, the KnotMarker points are given a series of characters based on the input given and so a selection of “NW”, our array point is given this exact value, “NW”, and so on until each corresponding point in our array is specified. 5.2.2.3 The Tile Parameters The choice to create two working types of parameter objects was that it was felt that although one would be sufficient to encompass all the data, the need conform to the design principles of object orientated relations within the system was more important to help with any maintenance. So, working in conjunction with the Knot Parameters object, the Tile Parameters object completes the Knot characteristics. However, unlike the Knot parameters object, this object has little responsibility as it only represents the Knots Tile colour specification such as Cord colour, Cord Line colour and finally the background colour. Both parameter objects serve only to be transports, in that the information and user input is classified into these two objects and subsequently used to create the Knot, nothing more.

5.3 Main Application Interface The key feature of the main application screen is that it is required to handle multiple window objects and have the ability to move and switch between multiple knot windows. Java’s swing package includes


52

the capability to do this via a type of Frame known as a JDeskTopPane. By using this swing object, one can create a JDeskTopPane to use for an application interface, but in this situation, I am using one of java’s typical package objects known as a JFrame to encapsulate the application. The benefits of using the JFrame is that Below outlines this procedure in establishing a JDeskTopPane which inevitably is used as the content pane of our JFrame. ... . public class MainScreen extends JFrame { JDesktopPane contentPane = new JDesktopPane(); ... . this.setContentPane(contentPane); ... Since the applications environment is based on the JDesktopPane , any resulting window or windows added to this location are obligated to be a type of java object known as the JInternalFrame (discussed earlier). 5.3.1 Help Guides The help guides were constructed externally to the system implementation and were amalgamated and encoded into the file type Mpeg4, a rich media format that includes audio and visual data. The choice to use this type of file format was that the multimedia information, as suggested by the results found in chapter 2, recommend a combination of audio and visual graphical data, exclusive of text elements, provide the greatest success of learning and storing the material. The material produced was created external to the application and as such, the full listing of its construction is given in Appendix D. However, its integration into the system used a recently developed package from java. The support work with rich media formats, such as AVI files for video or MP3 files for audio, one needs to utilise the Java Media Framework (JMF) API.

Chapter 6 System Testing

53

Chapter 6 System Testing System testing occurs in a variety of different manners, each result in fine tuning a particular part of the system or focus on a complete system examination. The dissertation focuses on two areas of system interaction which each require separate testing techniques to be applied. The process of testing the Celtic knot drawing package, exclusive of the Multimedia guide material, benefited from two main approaches of testing. The centre of attention for both testing approaches is to test whether or not the system meets the specified system requirements and this will result in the validation of the application. The first form of testing proceeds to validate the functionality of the system. This software testing process is the execution of an implementation of the source code, with test data, for example – the test data can be specified Parameter objects specifically designed to test the Knots construction algorithm. The outputs and operational behavior are then analyzed in order to check the system's behavior is as expected, and supports the specification. This type of test method was selected to ensure that the Celtic Knot construction algorithm produced the knots correctly. The Tests were purposefully designed to include data intended to make the system reveal any errors in the code and more specifically, the drawing algorithm. These included, for example - injecting a fault through the Knot Panel, which included falsified Tile data or non-existent Tile forms as the argument to its construction algorithm. This is derived from the assumption that if user input errors may occur then the system will counteract these before they are passed to the Knot Panel as specified in Chapter 3. However, this also leads to the


54

error prevention routines within the system. They were tested more thoroughly to eliminate these errors and so would subsequently cascade through the system and prevent any construction algorithm from performing illegal routines. The correction here made testing the construction algorithm easier as it was found that errors could be sourced from input or system related and so reducing the input level of errors would inevitably lower its presence when locating errors in the Celtic knots production routines. Although testing took place once the system was completed, an element of assessment did take place during the projects implementation stage and throughout its integration. Isolation testing, surrounds the class under test with stubs below (such as method calls) and drivers above where needed (such as graphical storage Panels). This meant that only one class needed to be written before testing could commence. Because of the time restrictions of this project, it was highly desirable to begin the (often lengthy) testing process as soon as possible, and have testing and coding running in parallel. For this reason, isolation testing was the main testing method used. Such examples included Testing the system’s integration stability was found to be beneficial to aid and reduce the final level of testing and so checking the individual modules under their perceived operating conditions took place. There were two types of program that were written in order to test integration the incomplete system; these are commonly seen under the heading of White-Box testing (Galileo Computing (2003)):

Drivers - Classes that are higher than the class under test, and include the bare minimum code necessary to call the methods with the chosen parameters. Stubs - The opposite, in a sense – they are classes containing empty methods that the class under test needs to call. Minimum code necessary includes methods that have the same name, return type and arguments of the real method, just with as little computation as possible - an example is the following Knot parameter object used to test the construction algorithm of the Knot Panel. class Knot_Parameters { public static String[][] KnotMarkers = {{"NW","N","N","N","N","N","N","N","N","NE"}, {"W","NONE","NONE","NONE","NONE","NONE","NONE","NONE","NONE","E"} {"W","NONE","NONE","NONE","NONE","NONE","NONE","NONE","NONE","E"} {"SW","S","S","S","S","S","NONE","NONE","NONE","E"}, {"NW","N","N","NS","NS","N","NONE","NONE","NONE","E"}, {"W","NONE","NONE","N","N","NONE","NONE","NONE","S","ES"}, {"W","NONE","NONE","NONE","NONE","NONE","NONE","NONE","N","NE"},


55

{"W","NONE","NONE","NONE","NONE","NONE","NONE","NONE","NONE","E"} {"W","NONE","NONE","E","W","NONE","NONE","NONE","NONE","E"}, {"SW","S","S","ES","SW","S","S","S","S","ES"}}; public int KnotWidth, KnotHeight; public int GridWidth, GridHeight; public Knot_Parameters(){ KnotWidth = 40; KnotHeight = 40; GridWidth = 10; GridHeight = 10; } public String[][] getMarkers(){ return KnotMarkers; } }// end Knot_Parameters ... As each test is completed and the error corrected, each test must be re-run to verify that the change has fixed the error and that the change has not influenced further system errors. ‘Regression testing is the process of running tests that previously exposed faults in the code, and checking to see if the fault repair has indeed repaired the error, and not introduced any new faults’ - (Galileo Computing (2003)). The Generation of the specified Celtic Knot was tested using Validation Test Criteria. This method uses a table which is created and contains headings for expected result, actual result and pass/fail. Each stage in the process being tested is represented by row in the table. A stage passes (is validated) if the actual result matches the expected result. However, even with all the test management and validation techniques, testing cannot guarantee a bug free system. The only disappointment with the testing is that the help guides were never tested against a population of users to determine if it had an effect on there use of the system.

Chapter 7 Conclusions

56

Chapter 7 Conclusions 7.1 Further Work During the work applied in the dissertation, a number of possible extensions and possible improvements were found. One major area of improvement for the project would be to collect some test results, by experimentation, on how successful the multimedia guides had been. The simplicity of the guides does also provide a possible area of improvement in that a more extensive look at the material would generate more complex tutorials. The system was based on ideas of providing a help guide sequencer with its proposed multimedia tutorials based on the systems Celtic knot construction tools. The projects domain has left a promising hole for future work based on this extension and its subsequent evaluation. The interface and its underlying system could be extended to form a fully functional Multimedia interface, rather than only present a small factor as a help guide system. Another improvement might concentrate more on the topics discovered in Chapter 2. The system could be developed to allow the user to encapsulate the knot in various other shapes, rather than the square. This proposal would be simple to adapt the existing system to do as the only difference is the shaped defined when creating the Break Markers.

Chapter 7 Conclusions

57

7.2 Concluding remarks Demonstrating that Celtic knots can be generated quickly and still provide the customisation of the Knots suggests that the proposed system has fulfilled, to some degree, the initial objectives of the project. However, the design and construction of the system did find some problems along the way. The construction algorithm was relatively simplistic in its design and implementation, but the type of algorithm used has many downfalls. A variety of illegal Tile formations are present and so a small number of break marker possibilities are only aloud. This also caused a variety of errors which had to be fixed within the input correction routine. The Knot is confined to very strict rules within the system but does provide the functionality that was set out to be achieved.

Bibliography

58

Bibliography Allen J.R. (1993). Celtic Art in Pagan and Christian Times. Dover Publications Baddeley, A. D. (1986). Working memory. Oxford, England: Oxford University Press. Bain, G. (1973). Celtic Art: the Methods of Construction. (Reprint of 1951 work) Bain, I. (1986). Celtic knotwork. London : Constable. Bransford, John D. (1979). Human cognition: Learning, understanding, and remembering. Belmont, CA: Wadsworth ‘Celtic KnotWork’. WWW: http://www.museangel.net/knot.html (29/04/2004). Cooper, A. & Reimann, R. (2003). About Face 2.0 : The essentials of interaction design.Wiley Publishing, Inc East of England Multimedia Alliance Ltd, 2000-03: http://www.emmauk.com/articledetail.asp?articleid=6. (11-2003). Galileo Computing. (2003). “Software-Testing and Internationalization” LISA/Lemoine International. IEEE Std 830-1998. (1998). IEEE recommended practice for software requirements specification. Isdell, D. L. (2001-2002). http://www.clanbadge.com/tutorial.htm: 2 Ways to Draw Celtic Knot work Jacobson, I. (1994) Object-Oriented Software Engineering. Addison-Wesley Publishing Company. JavaTM 2 Platform Std. Ed. v1.4.2 (04.2004) WWW : http://java.sun.com/j2se/1.4.2/docs/api/java/awt/Graphics2D.html Kulak D. & Guiney E. (2004) Use Cases: Requirements in Context. Addison Wesley Professional

Bibliography

59

Kotonya, G. & Sommerville, I. (1998). Requirments Engineering: processes and techniques. John Wiley & Sons Ltd. Levie, W. H., & Lentz, R. (1982). Effects of text illustrations: A review of research. Educational Communication and Technology Journal, 30 , (pp195-232). Marcat, C. (1997). http://www.entrelacs.net/ : Celtic Knotwork – The ultimate tutorial. James, S. (1993). The World of the Celts. Thames & Hudson Moreno, R. & Mayer, R. E. (2000). Meaningful learning: Applying cognitive theory to multimedia explanations. ED-MEDIA 2000 Proceedings (pp. 747-752) Charlottesville, VA: AACE Press Najjar, L.J. (1998). Principles of educational multimedia user interface design, Human Factors Metaxas. P. T, “On User Interfaces for Educational Multimedia Applications”. Computer Science Department Wellesley College. WWW: http://www.wellesley.edu/CS/pmetaxas/M2E2.pdf (04/2005). Ormrod, J.E. (1998). Educational psychology: Developing learners. (2nd ed.). New Jersey: Prentice-Hall, Inc. Schild, H. (2002). Java(tm) 2: A Beginner's Guide (Fifth edition). McGraw-Hill Osborne Media.Top of Form Sloss, A. (1995). How to Draw Celtic Knotwork: a Practical Handbook. SommerVille, I. (2001). Software Engineering, 6ht Edition. Person Education Limited. Sweller, J. & Chandler, P. (1994). ‘Why some material is difficult to learn. Cognition and instruction’, 12. Van Lamsweerde, A. (2003). From System Goals to Software Architecture, Informal Methods for Software Architectures, M. Bernardo & P. Inverardi (eds), LNCS 2804, Springer-Verlag, pp. 25-43. Woolfolk, A.E. (1998). Educational psychology (7th Edition). Needham Heights, MA: Allyn & Bacon CanadaBottom of Form WWW: deSignet International, 2000- 2004)

Appendix

60

Appendix A: Sample of the Use Case scenarios System Start-up

1. The user starts the system. The system presents the user with an empty view

2. The user chooses to generate a random Celtic knot and is prompted for confirmation to generate the random knot.

3. The user is presented with the generated knot in the system view

Saving current knot

1. The user selects the knot that he/she wishes to save for a later date by clicking onto the appropriate knot-box.

2. The user selects from the menu the save option. A dialog box prompts user for name of file to save too.

3. User confirms name and clicks OK. File is saved Opening previously drawn Knot

1. The user selects from the menu the option to open a saved Knot.

2. The system presents the user with a selection box. The user selects the appropriate Knot.

3. The user is presented with the saved knot. Create Random Knot

1. The user selects from the menu items to generate a random Celtic knot.

2. The user is prompted to confirm generation. The user clicks the confirmation.

3. The Celtic knot is displayed within the system view within a new window.

Animate generating knot?

1. The user selects to generate a new Celtic knot from the menu bar.

2. The user is prompted to confirm generation.

Appendix

61

3. The new knot is displayed within the systems window. 4. The user clicks the animate Knot button within the new Knot

window displayed. 5. The Celtic knot displayed within system view is animated and

the knot is drawn out so that the user can see it being constructed.

Switch between knots drawn Option a)

1. The user selects from menu bar the appropriate Celtic knot the user wishes to bring into view and select.

2. The window containing the Celtic knot is brought to the front in the system view.

Option b)

1. The user uses the mouse to select the Knot which the user wishes to bring to the front of the system view.

2. The user clicks the window containing the desired knot. 3. The window is brought to the front of the System view

Close all Knots

1. The user selects to close all currently displayed knot windows from the system menu

2. The system asks the user to confirm the closure of all Knot windows before saving any of the knots.

3. The user confirms to close all windows. 4. The system closes all windows to leave empty system view.

Close System

1. The user chooses to close the system. The user selects exit from the systems menu.

2. The system asks for confirmation of closing the system if there are knot windows present within the system view. The user confirms system closure.

3. The system exits Edit knot Colour background

1. The user selects the knot he/she wishes to alter the knot colour background.

2. The user clicks the edit display button associated with the knot window.

Appendix

62

3. The user selects the new background colour. The knot is updated instantaneously with the new background colour.

Edit knot Cord Size

1. The user selects the knot he/she wishes to alter the knots cord size.

2. The user clicks the edit display button associated with the knot window.

3. The user selects the new size parameters. 4. The system updates the Knot with the new co rd size.

Edit knot Cord Colour

1. The user selects the knot he/she wishes to alter the knots cord colour.

2. The user clicks the edit button associated with the knot window. 3. The user selects the new cord colour. The user confirms change. 4. The system updates the Knot with the new cord colour.

Create Custom Knot

1. The user chooses to create a new custom parameter knot. The user selects from the system menu to create a new custom knot.

2. The user sets the parameters for the knot. Parameters include Cord colour, background colour, cord width and break markers. There are default values if no user selection is made.

3. The user confirms the input parameters. 4. The system places the new knot into a new window placed into

the systems view.

Appendix

63

Appendix B: The Code Listings See the enclosed CD labelled “Dissertation documents” It contains the full uncompiled code and an archived .jer file which can be run by calling the method “java –jar (FileName).jar

Appendix C: A Sample of the Test Results

The Design and Implementation of a Celtic Knot D rawing...

Documents

Transcript of The Design and Implementation of a Celtic Knot D rawing...