MASARYKOVA UNIVERZITA

FAKULTA INFORMATIKY

}w���������� ������������� !"#$%&'()+,-./012345<yA|Iterative Web Systems

Development

BACHELOR THESIS

Roman Fianta

Brno, Spring 2009

Declaration

Hereby I declare, that this paper is my original authorial work, which Ihave worked out by my own. All sources, references and literature used orexcerpted during elaboration of this work are properly cited and listed incomplete reference to the due source.

Advisor: RNDr. Jaroslav Racek, Ph.D

ii

Acknowledgement

Appreciation is due to my advisor, RNDr. Jaroslav Racek, Ph.D, for hiscontinued support and guidance during the preparation of this thesis. Iwould also like to thank the band for useful suggestions and Mgr. KaterinaRepova, M.A., for her help with English writing.

iii

Abstract

The objective of this thesis is to examine the specifics of web informationsystems development, especially the iterative approach to designing smalland middle sized web applications. The aim is to select an appropriatemodelling tool and use it to analyze, design and partially implement a webapplication. Benefits and drawbacks of the employed method will then bediscussed.

iv

Keywords

WebML, agile, web, system, design, iterative

v

Contents

1 Models of life cycles . . . . . . . . . . . . . . . . . . . . . . . . . . 51.1 Waterfall model . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 61.1.2 Advantages and disadvantages . . . . . . . . . . . . . 6

1.2 Spiral model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 81.2.2 Suitability for web development . . . . . . . . . . . . 9

2 Agile methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Extreme Programming . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1 What is Extreme Programming? . . . . . . . . . . . . 112.2.2 Developing with XP . . . . . . . . . . . . . . . . . . . 122.2.3 Developing for the Web . . . . . . . . . . . . . . . . . 13

2.3 Other methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.2 Test-driven development . . . . . . . . . . . . . . . . 142.3.3 Feature-driven development . . . . . . . . . . . . . . 14

3 Developing Web System . . . . . . . . . . . . . . . . . . . . . . . 153.1 Web versus Software . . . . . . . . . . . . . . . . . . . . . . . 153.2 Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1 Quality web . . . . . . . . . . . . . . . . . . . . . . . . 163.2.2 Standards . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 Existing methods . . . . . . . . . . . . . . . . . . . . . . . . . 163.3.1 Web XP . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3.2 AWE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Web Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 WebML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.1 Data model . . . . . . . . . . . . . . . . . . . . . . . . 214.2.2 Hypertext model . . . . . . . . . . . . . . . . . . . . . 22

Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Pages, areas, site views . . . . . . . . . . . . . . . . . 23

1

Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Content management . . . . . . . . . . . . . . . . . . 25

4.2.3 Presentation model . . . . . . . . . . . . . . . . . . . . 255 Design of a web system . . . . . . . . . . . . . . . . . . . . . . . . 26

5.1 Development plan . . . . . . . . . . . . . . . . . . . . . . . . 265.2 Present status . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.4 First increment . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.5 Second increment . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.5.1 Data model . . . . . . . . . . . . . . . . . . . . . . . . 295.5.2 Hypertext model . . . . . . . . . . . . . . . . . . . . . 30

5.6 Third increment . . . . . . . . . . . . . . . . . . . . . . . . . . 315.6.1 Data model . . . . . . . . . . . . . . . . . . . . . . . . 315.6.2 Hypertext model . . . . . . . . . . . . . . . . . . . . . 31

5.7 Fourth increment . . . . . . . . . . . . . . . . . . . . . . . . . 325.7.1 Data model . . . . . . . . . . . . . . . . . . . . . . . . 325.7.2 Hypertext model . . . . . . . . . . . . . . . . . . . . . 32

6 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34A Contents of the enclosed CD . . . . . . . . . . . . . . . . . . . . . 38

2

Introduction

Computer science has been changing rapidly during the last decade. Incomparison with the period before the massive expansion of the Internetin the 1990s, the Information Age demands a lot more dynamics and flex-ibility. The Web has become a war field, where thousands of companiesstruggle for customers. Customers’ needs are changing quickly and soft-ware companies often have very little time to react properly.

It is deceptive to try to predict future, but without any doubt there is agrowing trend towards more flexible and faster process of developing soft-ware. Most of traditional methods (often more or less inspired by waterfallmethod), which date back to the period after the software crisis, are be-coming rigid and cannot compete against their modern successors. Clearly,many projects are still suitable to be developed using traditional approach.But speed and flexibility are the key words of modern methods. This trendis even stronger in designing web systems.

Agile programming is a very young branch of software engineering. Itemploys iterative development, which, among other things, provides nec-essary customer feedback. Unlike traditional approach, it prefers time andcosts to functionality. In other words, it is better to deliver an incompletesystem in time than to deliver a complete system with delay. Agile meth-ods are also known for their adaptability – they give priority to respondingto the change over following a plan. But, most importantly, they do notlower quality requirements.

Time and adaptability belong to the strongest advantages in the cur-rent web systems development. There are many software companies on themarket and a two-month delay can have serious consequences. That is whythis work will focus on iterative development of web systems, specificallysmall and middle sized web systems. Knowledge gained from examiningthe methods of web development will be used for designing and partiallyimplementing a small web system. No method will be employed directly,but the idea of incremental development will be applied, along with the useof a modelling tool convenient for web environment.

The first part of this thesis describes software engineering and models

3

of life cycles. Two most significant models of life cycles will be examined– waterfall model and spiral model. The following chapters are concernedwith agile methods, their principles and their use in web systems devel-opment. The rest of the thesis describes an analysis and a design of a smallweb system for a musical group. The language of the web system is English.

4

Chapter 1

Models of life cycles

The term software life cycle is closely associated with software engineering.The origin of these two terms dates back to the late 1960s, when improvingperformance of computers facilitated the development of more complexprograms. But with increasing complexity, major difficulties appeared insoftware industry. Here are some of them:

• Late delivery

• Running over budget

• Difficult maintenance

• Inefficient and low quality software

These problems were often caused by a chaotic code structure and an ab-sence of systematic management. Software was mostly developed usinga model which is called code-and-fix nowadays. It consisted of two basicsteps: writing a code and, subsequently, fixing the problems in the code.The major drawback of this approach is that as the number of fixes grows,the quality of the code structure rapidly deteriorates.

Stagewise model was introduced in 1956 and established several phasesin software development (operational plan, operational specifications, cod-ing specifications, coding, parameter testing, assembly testing, shakedown,system evaluation). [8] The bottleneck of this model was the absence of anyfeedback; each phase was directly followed by the next phase without anyverification. And then, in the late 1960s, software crisis reached its peak.

In 1968, the Software Engineering conference took place and was fol-lowed by Software Engineering Techniques conference in 1969. [3] Softwareexperts agreed on the urgent need for change. The change was representedby employing engineering methods to the process of software develop-ment. Those included a sound specification, analysis and design of eachsoftware project. Also, the term ”life cycle” was discussed. These confer-ences established the future progress of software development and helped

5

1. MODELS OF LIFE CYCLES

to cope with the crisis. One of the most important instruments that repre-sented the engineering approach was the waterfall model.

1.1 Waterfall model

1.1.1 Description

The waterfall model is often misinterpreted as a method, although it is infact a model of a life cycle. The difference between these two terms is ratherblurry, but basically, a life cycle model describes only the phases of lifeof software and actions taken during its development, whereas a methoddescribes the process of developing software in more detail (such as teammanagement, the form of documents and others).

The waterfall model was introduced in 1970 by Dr. Winston Royce andis considered to be a breakthrough in software engineering. It is a struc-tured model with subsequent phases. [16] The main advantage over thestagewise model is the ability to return to the preceding phase in order toalter its output (see figure 1.1). The waterfall model basically consists of thefollowing steps:

• Requirements analysis – gathering information from the customerand capturing it in a formal requirements specification.

• Design – defining architecture. Designed interface, hardware, soft-ware, module, component and data architecture has to meet the re-quirements specification.

• Implementation – coding according to designed architecture.

• Testing – components, integration and acceptance testing.

• Operation and maintenance – maintaining and contingent modifyingof the system and its components.

1.1.2 Advantages and disadvantages

The waterfall model, despite being rather rigid nowadays, is still popu-lar among some projects managers, particularly for its simplicity and easyprogress control. Royce also stressed the importance of documentation.However, shortcomings are generally considered to be overweighing thebenefits.

6

1. MODELS OF LIFE CYCLES

Figure 1.1: Waterfall model

• Flexibility is poor. Any changes during the advanced phases of theproject are very expensive and time demanding.

• It is very hard to completely specify the whole system at the begin-ning.

• The customer only sees the working version after it is coded com-pletely and implementing any change is much more expensive thanin the early phases of the project. Provided the specification did notperfectly respond to customer’s requirements, the project may be con-sidered failed.

These shortcomings were partly solved by subsequent modifications, likethe Prototyping model or the Incremental model. In the Prototyping model,a number of prototypes are created before the final version is released, al-lowing the customers to better specify their requirements. The Incrementalmodel is based on iterative principles; the customer feedback is improvedby not delivering the product as a whole, but as a set of increments.

7

1. MODELS OF LIFE CYCLES

1.2 Spiral model

1.2.1 Description

The spiral model, introduced by Barry Boehm in his work A Spiral Modelof Software Development and Enhancement in 1988, defined a new ap-proach to software development. The main difference from the waterfallmodel is the emphasis put on iterations and risk analysis. The developmentof software is conceived as a spiral, where the radial dimension representscumulative costs, whereas the angular dimension represents the progressachieved by completing each cycle. Boehm declared that ”The model re-flects the underlying concept that each cycle involves a progression thataddresses the same sequence of steps, for each portion of the product andfor each of its levels of elaboration, from an overall concept of operationdocument down to the coding of each individual program.” [8]

Figure 1.2: Spiral model (from Wikipedia)

8

1. MODELS OF LIFE CYCLES

1.2.2 Suitability for web development

Since this thesis is focused on web systems development, I will list the keyadvantages and disadvantages of this model and discuss their impact onusing this model for developing small and middle sized web systems.

The primary advantage of the spiral model is that it provides the ad-vantages of the engineering methods, while its risk-driven approach pre-vents from their difficulties. It is a very complex solution suitable for big,complicated projects, and yet undoubtedly more flexible than the originalwaterfall method. The spiral model is an underlying inspiration for manymodern methods, e.g. Rational Unified Process.

On the other hand, for smaller systems and smaller teams, the amountof effort needed to employ the spiral model may be inadequate to the size ofa project. Furthermore, similarly to the waterfall model and despite the iter-ative approach, no piece of software is released until the project is finished;the spiral model only works with prototypes before implementation.

It is therefore clear that using the spiral model for developing small andmiddle sized web system is rather inadvisable. Internet customers want theresults quickly and employing a model of such a complexity, along withrepeated thorough risk analysis, could only slow down the developmentprocess, thus disadvantaging the team against the competition.

9

Chapter 2

Agile methods

2.1 Overview

Software engineering warded the software crisis off, although not com-pletely. As Brooks stated in [13], there is no silver bullet for solving all prob-lems in software engineering. Still, thorough planning enabled designingbetter quality software and better time and resources estimation. Managersbegan to be able to better trace the project velocity. The catastrophical ratioof succesful and unsuccessful software became better.

As I mentioned in the introduction, the world is becoming more dy-namic, customers’ requirements change quickly. Engineering approaches,however much they are able to guarantee development of quality software,are not very flexible and are rather time-consuming. They are suitable forbig, stable teams developing large projects. Nevertheless, projects with lim-ited budget that are to be developed in a short time period, are not reallysuitable for the use of an engineering approach. These drawbacks of soft-ware engineering lead to the creation of methods which are called agile.

Figure 2.1: Iron triangle modification

The figure 2.1 shows the main difference between traditional and ag-ile methods. Scope represents demanded features and functionality. As we

10

2. AGILE METHODS

can see, Scope is fixed in the traditional engineering methods. The require-ments are captured in the opening phases of the project development andare modified minimally. Considering the unpredictable nature of softwaredevelopment, it may be very hard to gather all the information needed inthe beginning and, consequently, to predict the amount of time and moneyneeded to finish the project. This can result in late delivery or running overbudget.

Agile methods, as opposed to traditional approaches, adapt all func-tionality to fixed costs and fixed schedule. Agile methods date back to 2001,when a number of respected computer experts wrote and signed Manifestofor Agile Software Development [2]. The authors of the agile manifestovalue these items: individuals and interactions over processes and tools;working software over comprehensive documentation; customer collabo-ration over contract negotiation; responding to change over following aplan.

It is important to remark that the authors of the agile manifesto do notconsider engineering methods inferior. They just emphasize the values initalics and value them more. Manifesto for Agile Software Developmentwas introduced by software authorities that agreed on a set of values theywere employing when working on software projects.

The goal of the agile approach is to deliver valuable software quicklyand effectively. Agile methods clear the development process from bureau-cratic elements; instead, they focus on interpersonal communication, al-lowing the customer to better specify his or her requirements. Anotherparadigm used in agile methods is iterative development – increments en-sure quality feedback from the customer and simplify the development pro-cess.

Since the declaration of Manifesto, many agile methods were introduced.I will describe the typical (and probably the best known) example of an ag-ile method: Extreme Programming (XP). Due to the extent of this thesis,other methods will be described only briefly.

2.2 Extreme Programming

2.2.1 What is Extreme Programming?

Extreme programming (XP) was introduced in 1999 by Kent Beck. XP abidesby the principle, that the only measurement of project progress is the sourcecode. It asserts that the work will be enjoyable to programmers (becauseevery programmer prefers coding over reading through complicated spec-

11

2. AGILE METHODS

ification document). The project is delivered in the shortest time possibleand with minimal costs. Four values of XP are communication, simplicity,feedback and courage. [7] These values are reflected in the basic principlesof XP.

Rapid feedback – time is of the utmost importance. The sooner the feed-back comes, the better for customers and the development team. Customersgain feedback in days and weeks, not months, or even years; programmersfeed back in minutes or even seconds, not days or weeks.

Assume simplicity – the simplest possible solution should always beimplemented. Traditional approaches recommend planning for the futureand design for the future reuse (”we implement for today, we design fortomorrow”). XP, on the contrary, suggests doing the best work now andtrust yourself being able to add more complexity and functionality when(or if) needed in the future.

Incremental change is the basic principle of XP and basically all otherapproaches. A development team should prefer numerous small changesto one big change.

Embracing change – accepting changes. Programming is a flexible pro-cess and changes are inevitable. Accepting change and not avoiding rewrit-ing or even throwing out the code demands courage.

Quality work – the purpose of extreme programming is to deliver qual-ity software. Programmers should enjoy their work, thus work well. Theonly possible values of quality is ”excellent” and ”insanely excellent.” Thereare several ways to achieve quality. Above all, it is thorough testing. Testsare written and run before, during and after implementation. The task isnot done until all tests have passed and the programmer cannot think ofany other tests that might break.

2.2.2 Developing with XP

A project using the XP principles starts with collecting user stories. Theseare somewhat analogous to use cases in UML. User stories replace the spec-ification document, but they are more focused on customers’ needs, becausethey are written by them, not by the development team. Each story de-scribes a part of the functionality of the system. Developers collect userstories and estimate, how long each story will take to implement (usuallyone to three weeks); release plan is then made on the basis of gathered es-timates. Each system release consists of a set of users stories that are to beimplemented.

As it was already stated, development is incremental. Each increment

12

2. AGILE METHODS

adds some functionality to the system and must pass acceptance tests whichare written based on user stories. Each iteration begins with an iterationplanning meeting, where customers can choose from a set of user storiesto be implemented and where an iteration plan is created. Programmersthen write, test and refactor the code. After all user stories have passed allacceptance tests, the iteration is complete. After all iterations are complete,the project is done. For further information, see [20].

Extreme programming puts stress on people. Not only does it employprogramming techniques like programming side-to-side or collective codeownership, it also makes recommendations about furniture positioning,frequent meetings and insists on immediate feedback, rich communicationand making the work entertaining.

In his book Extreme Programming Explained, Kent Beck answers thequestion why this method is called ”extreme” despite the fact that manyprogrammers see this method as commonsense principles put under oneumbrella. The answer is not complicated: XP takes these commonsenseprinciples and practises them to extreme levels. ”If code reviews are good,we will review the code all the time (pair programming.) If testing is good,everybody will test all the time, even customers. (...)” [7]

2.2.3 Developing for the Web

Is XP suitable for small to middle sized web systems? With reasonable mod-ifications (they will be discussed later), I suppose it is. XP provides neces-sary feedback and good project tracking by the use of iterative develop-ment. Quick and cheap development can be an advantage over the com-petition. Furthermore, XP is adapted to small teams, which are suitable fordevelopment of small and middle sized web systems.

2.3 Other methods

2.3.1 Scrum

Scrum is more of a collection of agile mechanisms than a set of engineeringpractices. For example, it was successfully used as a manager wrapper forExtreme Programming, but it can also be used for other agile methods.

Scrum operates with a term controlled chaos. As Kent Schwaber statedin [18], ”The closer the development team operates to the edge of chaos,while still maintaining order, the more competitive and useful resulting sys-tem will be.”. Scrum provides tools for controlling the development chaos.

13

2. AGILE METHODS

Three major phases are defined – Pregame, Game and Postgame.Pregame consists in planning and system architecture/high level de-

sign. A list of features that are to be employed in the product is called”product backlog”. Game is where the development runs. It is composedof a number of ”sprints”, each taking one to four weeks, depending onplanning and the project complexity. Game uses instruments like the burn-down chart and Scrum meetings, short meetings that are held every day.Postgame represents a project closure. It includes a preparation for release,testing, finishing documentation and release.

2.3.2 Test-driven development

Test-driven development (TDD) is a method where writing tests precedeswriting code. Each test must be written to fail in the beginning. Program-mer’s task is then to write the code so that it passes the test. When the codeis refactored and the programmer cannot think of any other test that wouldfail, the task is done. The tests are written by the programmer and are fullyautomated (unit tests like JUnit are often used). Although this method pro-duces a 100 % tested code, additional non-automated testing is required –i.e. interface testing, integration testing and acceptance testing. This factorwould be even more emphasized if TDD were used for web projects, wherevisual qualities and a user-friendly interface are highly significant.

2.3.3 Feature-driven development

The description of the feature-driven development (FDD) was first intro-duced by Jeff De Luca, Peter Coad and Eric Lefebvre in 1999 in the bookJava Modeling in Color with UML. [1] It employs an incremental approachfocused on features. Each project basically consists of five processes: devel-oping an overall object model, building a features list, planning by features,designing by features and implementing by features. Last two activities areiterated.

FDD does not describe its phases in detail; instead, it lets the team choosethe most suitable method, thus requiring a senior chief programmer tomake important decisions and choose the right method. Unlike most ag-ile methods, the feature-driven development emphasizes the importance ofmodelling. A model is created at the beginning of the project and a moredetailed model is also involved in each iteration.

14

Chapter 3

Developing Web System

3.1 Web versus Software

Is web development different from software development? Many expertsagree that it is. A complex enumeration of differences is listed in [12].

Web applications use a hyper-media paradigm where content is struc-tured and presented using hyperlinks. Navigation within a web site is dif-ferent from that of conventional software applications. Web applicationsshould look and work similarly on each platform (web browser), unlikeconventional applications, which are often developed for particular hard-ware, OS etc. Moreover, web applications are often developed for usersacross the whole world. As a consequence, developers often develop a prod-uct for unknown users with more or less unpredictable behaviour.

Primary technologies used are different. Web technology is changingfaster than that of software. It may be difficult for developers and organi-zations to keep up with what is currently available. Web applications arechanged, modified and maintained more often than conventional softwareapplications.

Approach to quality delivered is often even more important than that ofconventional software development. In the Web environment, the competi-tion is often one click away and it is therefore essential to deliver a qualityproduct. [14] also says that time is very important as well, especially whentalking about small systems, which are developed quickly and where thecompetition is even larger.

Last, but not least, web development employs distinct disciplines suchas hypermedia engineering, graphics design, usability engineering, networkmanagement and others. These disciplines require people with specific skills– graphic designers, copywriters, usability engineers etc.

15

3. DEVELOPING WEB SYSTEM

3.2 Quality

3.2.1 Quality web

Usability is essential to web applications. If a user cannot find his or herway across the site, he or she may leave the site to find another; hardly anycustomer is willing to read documentation. ISO 9126-1 defines these subsec-tions of usability: understandability, learnability, operability, attractivenessand compliance. Since the goal of this thesis is to design a web site for amusical group, I would emphasize the importance of attractiveness – thesite has to look good and attract users at the first sight.

Content is another quality criteria. Hollow pages, mistakes or out-of-date news will attract nobody.

Security, especially when the web application is working with personaldata or bank accounts and passwords, is a matter of the utmost importance.

3.2.2 Standards

The early years of HTML were often chaotic: the code contained both tagsfor logical structure and tags for visual appearance; browsers like InternetExplorer did not adhere to standards of W3C, forcing web developers touse tweaks for their sites to be displayed properly. Fortunately, there is agrowing trend towards developing standards-compliant web sites.

Web standards are a set of standards and specifications that define anddescribe World Wide Web. [4] When using web standards, the chances forthe site to be properly displayed grow. Moreover, standards-compliant websites are accessible to software (easier page indexing, format conversion)and people (people with disabilities). Accessible pages clearly make sensealso for business reasons. As [5] says, standards-compliant web sites areopened for future and mindful of past technology.

3.3 Existing methods

There are several methods for developing web systems on the market – WebXP, AWE, Crystal Clear. I will describe two of them: Web XP and AWE.

3.3.1 Web XP

Web XP is derived from Extreme Programming and employs its techniques.But since web development is different, the authors of [19] modified the

16

3. DEVELOPING WEB SYSTEM

method. The Web XP method is a result of real-world experience: the au-thors were using XP on multiple web projects and modified XP so that itcan be used for web development.

Web XP breaks one of the fundamental states of the original XP, whichsays that team members should not specialize. In web development, spe-cialization is inevitable. Web XP modified the original roles to suit the needsof web development:

Customer is (similarly to XP) deeply involved in development process;Strategist is the primary customer’s advisor; Interface programmer, usuallycooperating with graphic designer, translates how each page should lookand programs its interface; Graphic designer is responsible for the look ofeach page; Server-side programmer programs server functionality and isoften simultaneously an interface programmer; Mentor checks in with theprogrammers, asks questions, gives advice and takes action if things seemto be going off track; Tester is responsible not only writing and runningfunctional and acceptance tests, but also for manually testing e.g. user in-terfaces (tests often cannot be automated in web development).

In order to lower risks and improve project velocity tracking and feed-back, Web XP is, as well as XP and all agile methods, iterative. The authorsof Web XP recommend that developers enrich all iterations with graphicdesign process and install and configure database, servers and other devel-opment tools in the very first iteration. Iterations should be approximatelytwo weeks long.

From other best practices included, I would mention using XML andXSLT, continuous integration and writing code to agreed standards. Alto-gether, Web XP appears to be suitable for small teams developing small tomiddle sized web projects. The pitfall of this method could be XP practicesthemselves: not everyone gets easily used to pair programming, intensecommunication and the customer being always present.

3.3.2 AWE

Agile Web Engineering (AWE) was introduced in 2001 by Andrew McDon-ald and Ray Welland. AWE does not strictly determine specific engineeringtechniques. Instead, it only describes basic principles of developing a webapplication, allowing the team to use techniques that suit its needs best. Inaddition, AWE also allows the team to change the employed technique af-ter each iteration is finished in case problems have arisen or another, moresuitable technique has been discovered.

AWE is iterative and incremental. Authors recommend that ”each itera-

17

3. DEVELOPING WEB SYSTEM

tion of the life cycle should address the problems that the team perceive topresent the greatest project risk.” [15] Addressing greatest challenges firstenables the team to adopt change and deliver a working web applicationearly.

Another significant principle of AWE is communicating through browserexperience. This helps the team to understand End-User usage of proposedsystem. Moreover, since the communication through source code, used inXP, may not be convenient to multidisciplinary teams, AWE suggests com-municating through browser experience as well. It is interesting to noticethat AWE was introduced before Web XP, where this pitfall is partly solvedby mixing up teams for pair programming (graphic designer with interfaceprogrammer etc.) and intense communication.

Unlike a number of agile methods, AWE emphasizes the importanceof a design process. Design precedes implementation in each iteration, en-abling the system architecture to be able to cope with a small Web appli-cation evolving into a truly large Web system. Design should be high leveland independent of implementation details. The whole software life cycleaccording to AWE is depicted in figure 3.1.

AWE has not yet been updated since its introduction. Due to the fact thatit does not prescribe the use of any particular techniques, it can be widelymodified; presence of an experienced team leader is necessary, though. Gi-ven the emphasis put on the design process, AWE is suitable even for largeprojects.

18

3. DEVELOPING WEB SYSTEM

BusinessAnalysis

RequirementsAnalysis

Design

Implement

Test

Evaluate

DeployWeb application

Start Process

Start Process

(from existing Web presence)

(for new Webpresence)

Figure 3.1: AWE process life cycle

19

Chapter 4

Web Modelling

Conventional software engineering methods, like Rational Unified Process,use a number of tools for modelling a software product: class diagrams, usecase diagrams, activity diagrams etc. However useful these diagrams arefor software engineering, they are not sufficient for web modelling, though.The most important issue in web applications is navigation in the form ofhyperlinks. This is an area which is not covered by conventional softwaremodelling tools.

But as web applications grow more complex and many companies trans-fer their system to the Internet, a need for thorough analysis emerged, caus-ing an inception of web modelling tools. In this chapter I will select a mod-elling tool which I will consequently use for the design of a small web sys-tem for a musical group.

4.1 Overview

OOHDMOne of the first methods for the design of web applications was Object-Oriented Hypermedia Design Method (OOHDM). OOHDM provides in-struments for model navigation and interface structure. OOHDM uses wellknown object-oriented techniques and instruments, such as use cases orclasses. More information can be found in [10].

UWEAnother approach to web application modelling is UML-Based Web En-gineering (UWE). UWE is an extension for UML, which is used for thespecification of web applications. It is an object-oriented method, similarlyto OOHDM. UWE covers the whole life cycle of web application develop-ment. Models involved are as follows:

• Content model is a normal UML class diagram.

• Navigation model contains nodes connected by links.

20

4. WEB MODELLING

• Presentation model shows which classes belong to which web page.

• Process model comprises Process Structure Model (describes processclasses) and Process Flow Model (represented by Activity diagram).

Both OOHDM and UWE are object-oriented. This approach could ap-pear to be too complex for a considerably small web system like a musicalgroup’s web site. UML is no silver bullet for software development, despiteits qualities. I was searching for a tool that was originally purposed for de-signing web applications. An example of such a tool is WebML.

4.2 WebML

WebML was introduced in 2003 in the book Designing Data-Intensive WebApplications. Authors of [9] describe the term data-intensive as ”Web sitesfor accessing and maintaining large amounts of structured data, typicallystored as records in a database management system.” WebML is an abbre-viation for Web Modelling Language; nevertheless, it is not only a languagesince it covers the whole process of developing a web application.

WebML uses three types of models: Data, Hypertext and Presentationmodel. Hypertext model comprises of Composition and Navigation model.The connection between these models is illustrated in figure 4.1. After thedata model has been finished, it is used to create a hypertext model, whichis then mapped and implemented in order to define the look and feel ofpages. Let us take a closer look at each of the models.

4.2.1 Data model

Since data-intensive web pages are expected to work with a database, mod-elling in WebML starts with data model. No new language is introduced;instead, WebML exploits well-known Entity-Relationship (ER) diagram. ERdiagram consist of entities with attributes and relationships between them.

It is essential that the data model is conceptual and thus free from anyimplementation details. [9] says that all the most important design deci-sions that do not depend on the physical architecture of the applicationshould be taken during data and hypertext design, and expressed formallyand at a high level. This principle is important for application evolutionand maintenance. This approach results, for example, in the existence of Nto N relationships, which is usually implemented with joining table in a lotof databases, such as Oracle or MySQL.

21

4. WEB MODELLING

Figure 4.1: WebML models (source: slides about WebML from PolitecnicaMilano)

In addition to conventional ER diagrams, data model in WebML is sup-plemented with derived information, i.e. values that can be determinedfrom the value of some other elements of the schema. The authors of [9]use Object Constraint Language (OCL) defined in UML.

To sum up, data model in WebML is similar to conceptual ER diagram.WebML enriches this diagram with derived information. The difference isthat cardinalities are written in the opposite way to that of conventional ERdiagrams. I consider this decision to be somewhat confusing, since mostprogrammers are used to conventional ER diagrams.

4.2.2 Hypertext model

Hypertext model is comprised of two models: Composition and Naviga-tion. Composition model defines the elements of the web application – ar-eas, pages and units. Navigation model describes the connection betweenthose elements. Similarly to the data model, the hypertext model is concep-tual, using high-level abstraction and not committing too much to designand implementation details.

22

4. WEB MODELLING

Units

Atomic elements of composition model are units. [9] defines five basic typesof units (see figure 4.2):

1. Data units show information about a single object.

2. Multidata units present information about a set of objects.

3. Index units show a list of descriptive properties of some objects, with-out presenting their detailed information.

4. Scroller units enable the browsing of an ordered set of objects, by pro-viding commands for accessing the first, last, previous, and next ele-ment of a sequence.

5. Entry units represent model entry forms, whose fields allow gather-ing input, needed to perform searches or to feed update operations.Entry units express acquisition of information from users.

The content presented by the first four units is extracted from the datamodel. In order to determine the origin of a unit’s content, source (the nameof entity) and selectors (predicate, written in the brackets) are used.

This enumeration of units is not complete; an entire set of WebML units– derivations of the listed units – can be found at [6] in the Teaching re-sources section.

Pages, areas, site views

[9] says that pages typically consist of several units grouped together toaccomplish a well-defined communication purpose. Areas are containers ofpages, or, recursively, other sub-areas. Areas are typically enclosed withinsite views. Site views represent cohesive hypertexts aimed at fulfilling aspecific set of requirements, like the delivery of content to a specific usergroup.

In order to describe the hierarchy of pages and, simultaneously, not todecrease readability of diagrams, three properties of pages are introduced.They reduce the number of non-contextual links between pages, thus mak-ing the diagram more transparent.

• The Home page is the page at the default address. It is denoted by an”H” inside the page icon in graphic specification.

23

4. WEB MODELLING

Data unit Multidata unit Index unit

Scroller unit Entry unit

Figure 4.2: WebML elements

• The default page is the one presented by default when its enclosingarea is accessed. It is denoted by a ”D”.

• A landmark page is reachable from all the other pages or areas withinits enclosing module. It is denoted by an ”L”.

Links

A link is an oriented connection between two pages or units. A link trans-porting information is called contextual, links transforming no informationare called non-contextual. Links can be specified by parameters and para-metric selectors; however, these specifications can be omitted if the connec-tion is obvious from the context.

Not only do links represent anchors and buttons, WebML also definesautomatic and transport links. An automatic link is used without user’sinteraction, i.e. clicking the link. Transport links are used for passing contextinformation from one unit to another. These links enable only parameterpassing, not user navigation. A good example of transport link would be alist of albums automatically displayed when viewing details of an artist.

24

4. WEB MODELLING

Content management

WebML provides tools for describing data operations of the web appli-cation, e.g. adding goods to shopping cart or filling a registration form.The hypertext model is enriched with operation units and OK/KO links.WebML offers built-in, predefined operation units for creating, modifyingand deleting objects. However, WebML also supports generic operations.Generic operations function as a black-box, whose internal specification isnot a part of WebML, enabling the incorporation of external logic to thehypertext model.

Each operation unit has one OK and one KO link: the former is followedin case of a successfully executed operation; the latter in case the executionof the operation fails.

4.2.3 Presentation model

In WebML, all models are stored in the form of XML files. Therefore, thepresentation model represents the transformation from XML code into oneor more stylesheets for pages of a web application. This is typically doneby an XSL transformation. DTD for WebML can be downloaded from thehomepage of WebML – http://webml.org.

The program for developing web applications with WebML is WebRa-tio. WebRatio offers not only tools for modelling, but also for implementingthe designed web application. The technologies used are (X)HTML, CSSand JSP. WebRatio permits working with repository, thus allowing teamwork. On the other hand, WebML can be used even with pencil and paperand implemented in any environment.

25

Chapter 5

Design of a web system

5.1 Development plan

This chapter is focused on designing a new web system for a musical group.The iterative approach will be combined with modelling in WebML. Thesystem will be designed and partially implemented incrementally. I willkeep to some of the rules of the agile methods that were mentioned above.As it is recommended in Web XP, the development process will involvedesign of graphics. Each iteration (apart from the first one, which will bedevoted to graphic design and database configuration) will start with de-sign, namely modelling in WebML; this corresponds with AWE or Feature-Driven Development.

As a tool for modelling the web system I chose WebRatio, which is anative program for modelling in WebML. I was using a trial version 5.1.WebRatio saves data in XML, making the implementation of the model pos-sible by the use of XSL transformation. Nevertheless, due to the complexityof such a solution, I consider this option to be disproportionate to the sizeof the developed web system. WebML is therefore used only for graphicalrepresentation of data and hypertext structure, not directly for implemen-tation.

Due to the extent of this thesis, only the first iteration will be completelyimplemented. The rest of the web site will only be designed for me or some-body else to be able to finish the implementation in the future. The resultwill be used as a group’s new web page.

5.2 Present status

The musical group has been using its web site (depicted in 5.1) for 3 yearsand is determined to have it either reasonably upgraded or completely re-designed. The complete enumeration of the desired new functionality islisted in the next chapter. After some consideration, I decided to design acompletely new web site.

26

5. DESIGN OF A WEB SYSTEM

The main reason for this decision is that the code of the site is not validand the layout is rigid. CSS is used only for style; layout is made by ta-bles. This makes the code hard to maintain and disorganised. Although thediscussion about suitability of tables for layout has never been completelyterminated, there is a clear trend towards using CSS in the Internet commu-nity.

There are several more drawbacks. The news section is not very well-arranged; I find it hard to read through a vast number of plain news with novisual divider. The band contact is hidden in one section and is not presenton every page. There are many sections that are blank or not maintained –they only detract the user from the purpose of the web page, i.e. to intro-duce the band to the user.

The effort necessary to implement new functionality to the old web sitewould be similar to the effort necessary to design an entirely new web sitethat will be standards-compliant, simpler and more effective.

Figure 5.1: Old web page

27

5. DESIGN OF A WEB SYSTEM

5.3 Requirements

The requirements were agreed upon by the author of this work and themembers of the band. They result from discussions about a new web sitethat the band needed. No specification document was created; instead, aset of desired improvements and characteristics of the web site was writtendown.

1. New design : although the graphic design of the current web site is notbad, it is not modern enough and is somewhat disorganised. More-over, a new design is necessary to attract fans. An ideal interval ofchanging the graphics is after each album release.

2. Database : the main goal is to add a database functionality for themembers to be able to manage the content of the web site (news, con-certs, galleries).

3. Language : the web site should be available in English to allow theband to communicate with people from abroad. A Czech version isnot incorporated in this thesis.

4. Users : registered users should be able to interact with the band bymeans of discussion boards, rating songs and gaining credits for at-tended concerts.

The features of the the web system are described in more detail in thedefinition of each increment.

5.4 First increment

The first increment is devoted to the design of a static web site with onlybasic content (news, biography). The purpose of this increment is to showthe client – the band – the look of the page in order to avoid later redesign-ing. I created minimalist design with a simple logo and a small number ofcolours. The result can be seen in figure 5.2.

The layout is using CSS, thus dividing style from content, making anyfuture modification of graphic design or site layout easy to implement. Incomparison with the former web site, which was using tables, the new webpage is more accessible and the code clearer.

Since the menu and the footer needs no further explanation, I will de-scribe only the middle part of the layout. It is divided into three subsections.The first one (situated on the very left) comprises the most common links

28

5. DESIGN OF A WEB SYSTEM

and contact information; the content of this pane is static. The middle partis called container and is the centre of the web site. It displays data likebiography, news or information about booking. The right pane displays in-formation about upcoming activities of the band (mostly concerts). Sincethis iteration does not contain the implementation of concerts, it will betemporarily left blank.

Figure 5.2: New web site

5.5 Second increment

This increment adds instruments for band members to be able to managethe content of the web site, namely news, concerts, albums and songs. Thatis achieved through the use of a database. Members can log in and gainaccess to the administration section. Due to the increasing complexity of thesite, WebML model – consisting of data and hypertext model – was created.It follows the principles and rules stated in Chapter 4.

5.5.1 Data model

As it was mentioned in Chapter 4, the conceptual data model in WebML isvery similar to conventional ER diagrams. The main, and somewhat con-fusing, change is that cardinalities are written in opposite sequence thanin the conventional ER diagrams. Moreover, WebRatio does only allow to

29

5. DESIGN OF A WEB SYSTEM

write cardinality as ”maxCardinality”, i.e. number ”1” indicates cardinality”zero or one”. Were I not using WebRatio for hypertext model and for con-trolling its cohesion with data model, I would choose another modellingtool in order to create a more comprehensible data model.

A central entity of the model is called Member. It comprises basic in-formation about band members. Each Member can participate on zero ormore Albums, and each Album can be recorded by one or more Members.Each Album consists of one or more songs, but not every Song is necessarilyrelated to an Album. Each Song holds information about its duration.

Each Member has a possibility of writing and publishing News. An an-notation is the shorter part of the news which is displayed on the main pageand is limited by the number of characters. Text is the rest of the news andis displayed after clicking a corresponding link.

Concert is the last entity in this data model. Each concert has to be re-lated to at least one member, usually all of them. Nevertheless, not everyMember is related to every Concert.

WebRatio automatically adds three entities to each data model – User,Group and Module. Due to the size of the web system and the use of WebMLonly as a graphical representation, I do not consider these entities necessary,therefore I decided not to use them.

5.5.2 Hypertext model

The site view consists of two main areas: one devoted to regular users andone to administration. The public site consists of three basic pages – home-page, music, and concerts. This area is not very complicated; it is used onlyfor displaying content. Concerts are divided into past and future ones.

The administration area is more complex than the regular area. It holdsitems that allow members of the band to add and edit content. The de-fault page of this area is the News page showing the list of News limitedby scroller unit. Each news item has one author, but can be edited by anymember of the band. After selecting a news item to edit, the data from thenews entity are transferred into the form for editing news. In case a memberwants to add a new item, the form will be empty. After the form has beenfilled and sent, a new News item is created. In case of creating the news,the relationship between the author and the news is created consequently.Selector units are used instead of Data units. According to the Help of We-bRatio, the Selector Unit is somewhat similar to multidata unit, but it allowsthe programmer to specify the logic of a selector in a hypertext without thenecessity to display the extracted values on the page.

30

5. DESIGN OF A WEB SYSTEM

The page called Music displays a list of albums and a list of songs thatare not related to any album. The process of adding an album is very sim-ilar to that of adding news. The only difference is that more members canbe selected as authors of an album. After the album has been successfullycreated, the member is forwarded to the page for adding songs. Each songcan be edited or added by using a simple form and selecting authors. If themodification of the song fails, KO link (red) transports the parameters backto the form for the user to be able to try again.

The administration of concerts is very similar to the features mentionedabove.

5.6 Third increment

The third increment adds more detailed information about band members,simple photo gallery, music recordings and lyrics. All these new features areincorporated in the web site and can be managed in administration section.

5.6.1 Data model

Data model was extended by five new entities.

1. Gallery represents a set of photos from one concert or a set of photosrelated to some activity. Each concert has none or one gallery.

2. Each Photo is related to one gallery. A photo can be related to mem-bers. The meaning of such a relationship is read as ”a member is in aphoto”.

3. Recording is an entity which holds the recording in the form of a MP3or WAV file. Not each song has a recording, but some songs can berecorded more than once.

4. Lyrics is a text of the song. Each song has zero or one lyrics. Lyricsbelongs to one song.

5. Info comprises basic information about the band members.

5.6.2 Hypertext model

A new page called Gallery was added to the public web site. It contains a listof galleries, acting as links to a selected gallery. Galleries are also available

31

5. DESIGN OF A WEB SYSTEM

from each concerts’ detail. The page named Music began to display lyricsand recordings to each song.

The administration area was also altered. Each Member can create ormodify his or her Info. The page called ”Gallery Management” allows mem-bers to create or modify galleries. Each gallery can be connected to a max-imum of 1 concert and has to contain at least one photo (no photos areallowed to be placed outside a gallery). Having chosen a gallery, a membercan add edit photos in ”Photos Management” page. A photo can be con-nected with multiple members. When modifying a photo, a member canedit a description, a picture or members connected to the photo.

The page labelled as ”Songs Management” was enriched with the formsdesigned for adding and editing Lyrics and Recordings.

5.7 Fourth increment

The main purpose of the fourth iteration is to allow regular users to sign inas band’s fans, enabling them to rate music, post opinions to newly addeddiscussions and gain credits for attended concerts.

5.7.1 Data model

Two new entities were added to the data model: Discussion and Post. Eachdiscussion consists of 0 to N posts posted by any of the Members. Eachconcert is related to one discussion, but a discussion does not necessarilyhave to be connected to a concert, it can stand on its own.

The Member entity was extended by a new column of boolean type,labelled ”band”. This column determines whether the member is a regularuser (false) or band member (true).

5.7.2 Hypertext model

Fans of the band can sign for a concert. A list of fans who confirmed to at-tend the concert is displayed in concert details. The possibility of unsigningis allowed as well. Fans can add comments about past concerts using a dis-cussion (each past concert contains one discussion thread), but a user doesnot have to be registered in order to post a comment.

Another privilege of registered users is the ability to rate songs. An av-erage rating of the song is displayed among song details. An album ratingis calculated from average ratings of the songs from the album.

32

5. DESIGN OF A WEB SYSTEM

New pages in the public area are the ”User Details” page, where a usercan change his or her password, name and other information; and the ”Login” page.

The most significant change to the administration area is the possibilityof adding or removing relationships between fans and past concerts. A re-lationship between a fan and a concert represents attendance at the concert,each of which means particular amount of credits. Credits can be used forgaining a free entrance or buying band merchandise with a discount. An-other change in the administration area is adding a Mail Unit designed forsending e-mails to fans about upcoming concerts (this feature is optional).

33

Chapter 6

Implementation

As it was stated before, the web presentation was firstly completely re-designed to a static web site that is standards-compliant and has a newgraphic appearance. Emphasis was put on lucidity and minimalist designfor the users to be able to find their way across the site easily. Main coloursare black, white and blue; the last one is used mostly for hyperlinks.

After the completion of the static web site, database functionality wasadded. I chose the combination of PHP scripts and MySQL database forits simplicity and my previous experience with these instruments. As a de-velopment environment I used WampServer, open source environment forweb development in Windows. Database tables and web pages were de-signed to be consistent with that of WebML model.

The web system was successfully tested in four most wide-spread webbrowsers: Firefox, Opera, Internet Explorer and Google Chrome. I tried toavoid writing redundant code, for example by creating a file with globalvariables, used for gaining data needed for database connection. The sourceof inspiration and advice was [11].

The web system is divided into two separate parts, conforming to theWebML model: a public section and an administration area. The public sec-tion displays news and concerts. The administration section enables main-tenance of the content by adding, removing and editing news and concerts.The access to the administration area is granted only to band members byusing a login and a password.

The purpose of this thesis was to examine methods for web develop-ment and to model a small web system, the implementation is thereforeconsiderably uncomplete; the first increment and a half of the second in-crement (news and concerts partial administration) were finished. It servesmainly as an example of how a WebML model can be used for web sys-tem development. The source code of the web system is included on theenclosed CD with installation instructions. The implemented part is alsoavailable at http://bc.corposant.info.

34

Conclusion

The incremental approach turned out to be suitable for the development ofa small web system. It allowed better planning and feedback, although itdemanded the necessity to respond to change.

WebML confirmed its focus on data-intensive web applications – usingWebML for developing a simple web page would be disproportionate tothe size of the project and would probably result into a slowdown in projectprogress.

Using WebML for a graphical representation of a small web systemconnected to a database, however, appeared to add the level of abstrac-tion needed to design the system rigorously, while simultaneously leavingenough space for the developer to be able to choose appropriate implemen-tation details. The use of Web Modelling Language to implement a smallsystem by creating and applying XSL stylesheets for transformation of XMLcode to HTML code could be excessive, though – this approach is suitablefor large web applications. As a disadvantage of WebML I would mentionthe deviation from standards in data model, given the opposite way of no-tation of cardinalities.

WebRatio is a useful tool for modelling in WebML. It is user-friendly,quick and the possibility of exporting a project to a set of pages and scriptscan be attractive. It is suitable not only for a complete project development,but also as a supporting tool for graphical representation. Another advan-tage is a very comprehensive User Guide with a thorough description ofelements and principles of WebML. I missed wider options of exportingthe model to graphic formats. The inability to remove three stable entitiesfrom data model (user, module and group) and the inability to choose the”exactly one” cardinality are also drawbacks, that can discourage a devel-oper from using this program.

To sum up, the use of the iterative approach along with modelling inWebML appear to be suitable for developing web systems, although forsmall web systems, reasonable modifications may be necessary.

35

Bibliography

[1] Feature-driven development. [cit. 2009-03-16]. Available from: http://en.wikipedia.org/wiki/Feature_Driven_Development.

[2] Manifesto for Agile Software Development. [cit. 2009-03-01]. Availablefrom: http://agilemanifesto.org/.

[3] The NATO Software Engineering Conferences. [cit. 2009-02-28].Available from: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/.

[4] Web standards. [cit. 2009-03-29]. Available from: http://en.wikipedia.org/wiki/Web_standards.

[5] The Web Standards Project. [cit. 2009-03-29]. Available from: http://www.webstandards.org/learn/faq/.

[6] WebML.org homepage. [cit. 2009-04-04]. Available from: http://webml.org/webml/page1.do.

[7] Kent Beck. Extreme Programming Explained. Addison-Wesley, 1999.

[8] Barry W. Boehm. A Spiral Model of Software Development and En-hancement. 1988.

[9] Stephano Ceri, Piero Fraternali, Aldo Bongio, Marco Brambilla, SaraComai, Maristella Matera. Designing Data-Intensive Web Applica-tions. Morgan Kaufman, 2003.

[10] Gustavo Rossi Daniel Schwabe. An Object Oriented Approach to Web-Based Application Design.

[11] Yann Le Scouarnec, Jeremy Stolz, Michael K. Glass ElizabethNaramore, Jason Gerner. PHP5, MySQL, Apache. Computer Press,2006.

[12] Nile Mosley Emilia Mendes. Web Engineering. Springer, 2006.

36

6. IMPLEMENTATION

[13] Jr. Frederick P. Brooks. No Silver Bullet: Essence and Accidents ofSoftware Engineering. 1988.

[14] Vaclav Kadlec. Agilnı programovanı. Computer Press, 2003.

[15] Andrew McDonald and Ray Welland. Agile Web Engineering (AWE)Process. 2001.

[16] Contributor Melonfire. Understanding the pros and cons of the water-fall model of software development. [cit. 2009-02-28]. Available from:http://articles.techrepublic.com.com/5100-10878_11-6118423.html?part=rss&tag=feed&subj=tr.

[17] Petr Zelenka. Webml - projektovanı webovych aplikacı, 2003.[cit. 2009-02-28]. Available from: http://interval.cz/clanky/webml-projektovani-webovych-aplikaci/.

[18] Ken Schwaber. SCRUM Development Process. Available from: http://jeffsutherland.com/oopsla/schwapub.pdf.

[19] Doug Wallace, Isobel Raggett, Joel Aufgang. Extreme Programmingfor Web Projects. Addison Wesley, 2002.

[20] Don Wells. Extreme Programming: A gentle introduction. [cit.2009-02-28]. Available from: http://www.extremeprogramming.org/index.html.

37

Appendix A

Contents of the enclosed CD

• The text of the thesis (bc.pdf)

• WebRatio 5.1 trial version

• WampServer (Windows Web development environment – Apache,MySQL, PHP)

• Source code of the WebML model

• Images and XML output of the WebML model

• Source code and sample images of the partial implementation

38