Eighth Java & the Internet in the Computing Curriculum Conference ...

Proceedings of the Eighth Java & the Internet in the Computing Curriculum Conference (JICC 8) London Metropolitan University, Monday 26th January 2004 Organised by London Metropolitan University and the LTSN-ICS, University of Ulster, in co-operation with the ACM SIGCSE Editor: Peter Chalk, London Metropolitan University Programme Committee: Peter Chalk (Chair, LondonMet), Fintan Culwin (LSBU), Sylvia Alexander (Ulster), Peter Burton (QMC), Cornelia Boldyreff (Lincoln), Pam Wain (Women's Engineering Society), Frank Martin (LondonMet), Peter Martin (UWE), Robert Stroud (Newcastle), Sahithi P Siva (LondonMet), Craig Gaskell (Hull).

The Eighth Java & the Internet in the Computing Curriculum Conference (JICC 8) Programme London Metropolitan University, Monday 26th January 2004 9.30-9.55 9.55-10

Coffee and Registration Welcome by Jeff Naylor Head of Dept of Computing, Communications Technology and Mathematics London Metropolitan University

10-10.30

10.30-11

Southampton Institute

Java Data Objects: Transparent domain model persistence for Java web applications

Richard Hill & Dharmendra Shadija

Teaching Encryption to Reluctant Programmers

Mark Cranshaw

Sheffield Hallam University 11-11.15 11.15-11.45

Coffee and Publisher presentations in foyer Klaus D McDonald-Maier

The Embedded Web

University of Kent 11.45-12.15

Mike Lockyer, Gary Griffiths, Briony Oates, Barry Hebbron

.NET & Web Services

University of Teesside 12.15-12.45

Gary Griffiths, Barry Hebbron, Mike Lockyer, Briony Oates

SWMing at Teesside

University of Teesside 12.45-1.45 1.45-2.30

2.30-3

3-3.15 3.15-3.45

Lunch and Publisher presentations in foyer Robert Stroud

Tutorial:

University of Newcastle

Evolution of Java

Fintan Culwin

Demonstration:

London South Bank University

Java Class Factories - form and wizard

Coffee and Publisher presentations in foyer Gordon Fletcher

Cargo Cults in Java

University of Salford 3.45-4.15

Stuart Lewis and Phil Davies University of Glamorgan

4.15-5

Representatives from

The Automated Peer-Assisted Assessment of Programming Skills Presentations on Perspectives

IBM, Microsoft and Sun Organised by London Metropolitan University and the LTSN-ICS, University of Ulster, in co-operation with the ACM SIGCSE

The Eighth Java & the Internet in the Computing Curriculum Conference (JICC 8) Introduction to the Proceedings Welcome to the eighth annual JICC conference and the third to be held at London Metropolitan University. It is the fourth since we added 'and the Internet' to the title, broadening the scope and reflecting the increasingly diverse ways in which Java has become the vehicle for teaching about computer science. The first section of the conference has papers by Cranshaw on using Java Data Objects to illustrate object persistence in web applications, and by Hill & Shadija on teaching encryption techniques, in Java, to students of eCommerce. The second section covers areas of internet engineering. McDonald-Maier describes the use of embedded web serve rs in robotic devices to teach technology and design. Lockyer, Griffiths, Oates & Hebbron present two papers as a team working in the field of web technology. The first shows how software engineering techniques can be taught in the context of developing .NET applications. The second describes a specific technique, the Simple Web Method (SWM), developed by the team at Teeside. A tutorial on the new features planned for the next release of the Java JDK, version 1.5, is given by Stroud, while Culwin gives a demonstration of a web-based software package for teaching object oriented software development. The final section, before industry representatives describe their latest educational initiatives, covers topics in the pedagogy of teaching programming. First, Fletcher uses ethnographic research methods to identify strategies used by students to produce their programming courseworks. Lewis & Davies describe developments to the Coursemarker CAA system that support peer support and peer assessment. So, overall, JICC8 provides some excellent examples of the diversity of research into, and developments in, teaching Java and the Internet. I hope we can all partake in a lively and interesting day.

Peter Chalk, Chair, Programme Committee

Java Data Objects: Transparent domain model persistence for Java web applications Mark Cranshaw Senior Lecturer in Computing Faculty of Technology Southampton Institute

Introduction This paper is based on the experience of teaching Java-based web application development to Level 3 students on the BSc(Hons) Computer Studies and BSc(Hons) Software Engineering degrees at Southampton Institute. Students study object-oriented application development in Java as a prerequisite for participating in the Distributed Computing in Java option unit. This unit has been running for three years and during that time object persistence in web applications has been achieved using the JDBC API to store objects in relational database tables. My aims here are to outline some of the problems associated with this approach and to propose an alternative that makes use of the Java Data Objects (JDO) specification to achieve transparent and direct persistence of the domain object model.

Object Persistence in Java Applications There are a number of different approaches that can be used to permanently store objects in Java-based applications. When students develop stand-alone applications object persistence can be achieved using file based storage or in some problem domains omitted completely. File based storage is particularly straightforward to achieve using Java's serialisation mechanism which allows objects that implement the Serializable interface to be written directly to file. However, as students seek to implement three-tiered web applications the use of relational database stores and the need to address the issue of mapping objects to relational database tables cannot easily be avoided. In commercial OO applications where persistent storage of objects in a relational database is required, specialised object/relational (O/R) mapping tools are commonly used to take the pain out of mapping objects to relational tables. Enterprise Java applications would be likely to use Enterprise Java Beans to achieve persistent storage with the option of O/R mapping being managed automatically on the server side. In some contexts object databases may provide a solution. However, none of these options are ideal for use within HE institutions. Specialist O/R mapping tools have proprietary APIs and carry a significant learning and knowledge overhead for students that is not reusable, they are also expensive. The same applies to OO databases. On the other hand, development using EJBs involves a degree of complexity and a level of knowledge that cannot be easily assimilated by the average student in a one semester course.

1

Using JDBC The most straightforward and economical solution for achieving object persistence is to use the JDBC API in conjunction with a relational database. JDBC drivers are freely available for most commonly used relational databases, including open source products such as MySQL. This is also the approach that has been generally adopted in textbooks covering Java based web application development. I suspect that it is the most widely used approach in HE institutions. Providing the appropriate connection strings are known, making an connection to a relational database from a Java application using JDBC is a simple matter of putting the JDBC Driver in the application CLASSPATH and including a few lines of code to load the DriverManager and create a Statement instance (the class that is used to create and manipulate database tables). However, this is where the fun starts. Students must make decisions as to how the objects in their application will map to relational tables. For simple classes with attributes of primitive type this activity is straightforward. For more complex models incorporating graphs of objects and inheritance this is a non-trivial exercise. Once the relational schema has been designed the student will need to create a database either using a tool provided by the database vendor or alternatively in Java code via JDBC. The database can then be populated and edited from Java application code by passing SQL update and query statements as Strings to the Statement. Queries return a ResultSet object, the records of which can be manipulated using the JDBC API. The mixture of SQL and Java code can be seriously problematical for the student particularly when complex queries are required. Debugging can be difficult and time-consuming. Furthermore, SQL is nonstandard across databases and students frequently encounter typing problems when porting applications between development and deployment databases.

The Preferred Architectural Model The approach to the development of Java-based web applications that we advocate at Southampton Institute is use case driven. Having carried out object-oriented analysis and design on a given problem specification, students are encouraged to make decisions as to which objects in their design need to be persisted. Design patterns are applied to ensure that the JDBC code controlling the persistent storage of objects is encapsulated within specialised classes.

Student Practice The actual approaches adopted by students both in the Java unit and in their projects often vary considerably from the preferred model. Those influenced by previous server side development experience using technologies such as Microsoft Active Server Pages (ASPs) tend to use to JDBC to make direct connections to the database from their Java Server Pages (JSPs) or Servlets. Classes exist in the domain model but fail to make the cut at the detailed design/implementation stages. Other students will adopt a database driven approach to the problem. Working on prior knowledge from database application development units their starting point will be the identification of entities within the problem domain and the relationships between them. From the resulting entity relationship diagram a database design will be created and from

2

this an object model derived. With this approach it is the structure of the data that drives the development process rather than the usage patterns as represented in the use case model. The relational schema is often much more complex than what is required and what would have been specified had candidates for persistence been chosen from the object model on the basis of the persistence needs of the application. Students will invariably spend considerable amounts of time developing SQL queries to access the datastore. Given the learning outcomes of the units in question this is time that could be more usefully employed in activities more directly related to the object modelling process.

Java Data Objects My aim is to address these problems by introducing Java Data Objects (JDO) as the persistence mechanism for Java-based web application development. The JDO specification is an outcome of the Java Community Process that was approved as a standard by the executive committee in 2002. JDO provides an interface based persistence definition, while vendors provide implementations for the JDO interfaces. The key advantage of JDO from an educational perspective is that it provides for transparent persistence of domain objects. Access to the JDO APIs is located within the workflow rather than within the domain model, thus in the context of web applications, server pages contain the JDO APIs, while objects in the domain model remain free of persistence detail. JDO allows objects to be stored without requiring any specific methods or attributes to be added to the classes, without requiring changes to access modifiers and without requiring get and set methods for attributes. This is in marked contrast to the work required to develop Entity Beans in EJB 2.0. Candidate persistent classes must implement the PersistenceCapable interface and although the implementation of this interface can be written by the programmer, the more normal case is for it to be achieved using an enhancement tool provided as part of the JDO implementation. Enhancement is carried out after the domain model is complete, and is usually applied to the compiled byte code, making it a completely transparent process. The binary compatibility of JDO instances means that they are portable between databases without recompilation, providing a JDO implementation is available. Schema generation tools provided with JDO implementations1 handle the mapping of objects to relational tables without programmer intervention. Vendor implementations of JDO can front object databases, file storage systems and XML storage systems in addition to relational databases, and can be used in all three editions of the Java 2 platform, standard, micro and enterprise.

1

I am currently using KodoJDO from SolarMetric who have been very helpful in the provision of educational licenses. See Appendix 1 for a link to a comprehensive list of vendors. 3

Using JDO JDO can be used in what are described as managed and non-managed environments. The term non-managed environment refers to a standard Java application, while the term managed environment refers to storage within the context of a J2EE container. It is preferable to deal with usage in non-managed environments first. From the student developer perspective the ability to use JDO outside of the server environment does facilitate development and testing. Furthermore, it is possible to use the techniques for non-managed environments within a web server, albeit without the benefit of J2EE container managed transactions . Any class that is to be persisted must have a corresponding entry in an XML file, known as the persistence descriptor file. The developer may supply a separate descriptor file for each class or a single file for a package. It is this file that is used by the schema creation tool to create the O/R mapping and generate the necessary tables. The minimum entry for a persistence descriptor file specifies only the name of the classes to be persisted for example:

Storing objects Within the client code it is necessary to retrieve a PersistenceManagerFactory from the JDO implementation, which is instantiated with the appropriate database connection strings. The PersistenceManagerFactory can then be used to retrieve an instance of PersistenceManager and it is this class that is responsible for managing the life cycle of persistence instances. Instances of persistence capable classes are passed to the makePersistent method of the PersistenceManager. JDO supports transactions, consequently any call to make an object persistent must be made within the context of a transaction. The current transaction can be retrieved from the PersistenceManager. For single threaded client server applications with a single PersistenceManager the transaction instance is retrieved as early as possible and is used for many serial JDO transactions. The call to the makePersistent method of the PersistenceManager is contained within a begin and a commit on the transaction. The following Java code fragment illustrates this process: //pm is a PersistenceManager instance //get the current transaction and persist an object

4

Transaction t = pm.currentTransaction(); Student student = new Student(111111, “Computing”, “BscSE”); t.begin(); pm.makePersistent(student); t.commit();

If the object that is made persistent has other PersistanceCapable objects as attributes, these will also be made persistent. These instances can subsequently be retrieved through the class that contains them as we shall see later when we look at the JDO query mechanism.

Retrieving Objects JDO allows applications to navigate through the persistent fields of instances using the familiar dot operator. As objects are required they are loaded from the datastore and added to the PersistentManager's cache. Thus the entire graph of objects appears to be available in memory. Three different methods are available for retrieval of the first persistent instance in a graph. •

PersistenceManager getObjectByID()

Each first class2 persistent object has a unique identity, which can be accessed by the application and stored for the purpose of retrieving the object. Alternatively IDs can be generated using data input by the user. •

The Extent interface

The PersistenceManager interface provides a method for retrieving the Extent of any class. The Extent contains all persistent instances of the class (and its subclasses). Retrieval of the Extent does not in itself result in retrieval of instances from the datastore. This is achieved by retrieving an Iterator from the Extent. •

The Query interface and the JDOQL

JDOQL is a query language specified within JDO, with Java-like syntax using Java operators. It is independent from the query language of the datastore thus providing a standard that is transferable across database implementations. Queries executed using JDOQL return an unmodified collection of all the instances of a class that satisfy the specified filter condition. The following code fragment illustrates JDOQL usage retrieving all undergraduate students from the Computing Faculty: Extent students = pm.getExtent(Student.class, false); 2

JDO supports first and second class persistent instance. Only first class instances can be accessed directly from an application. Second class instances are usually part-of a first class instance with lifetime dependency. They can be accessed via the containing first class instance.

5

String filter = ”faculty == \”Computing\” && course.startsWith(\”BSc\”) ”; Query query = pm.newQuery(students, filter); Collection results = (Collection) query.execute();

With a small number of exceptions the syntax of JDOQL is the same as Java.

6

JDO in a Managed Environment Coverage so far has focused on the non-managed environment. However, JDO was designed for seamless integration in the J2EE environment and can thus be integrated with EJB applications. The preferred method of plugging a PersistenceManager into a J2EE container is by means of the J2EE Connector Architecture(J2EE CA). For the purposes of this paper, I will limit my comments to JDO integration with the Web tier. There is very little extra that needs to be known in order to use JDO in the context of a web server. With Servlets, a PersistenceManager should be retrieved in the init() method of the Servlet and the current Transaction retrieved, used and committed within the scope of the HTTP request. As stated earlier, calls to the JDO API are contained within the workflow rather than the domain model. JNDI lookup is the preferred method for retrieving a PersistenceManagerFactory instance from a container. The process of instantiating and registering a PersistenceManagerFactory with the naming service will be specific to the Application Server. When working with JSPs one good approach would be to use the ViewHelper3 pattern and encapsulate the JNDI lookup in a dedicated JavaBean and access through the action.

Conclusion This brief and high-level discussion of JDO in the context of Java-based web applications was not intended to provide the reader of the paper with a complete toolset to use in adopting JDO as a persistence mechanism. For such a purpose the reader would be advised to consult the resources cited in Appendix 1. It was intended to demonstrate that the use of JDO as the persistence mechanism in Java based web applications enables transparent persistence of the domain model while significantly reducing implementation complexity in the persistence layer compared with approaches that use JDBC directly. The fact that ordinary Java objects can be persisted with ease and retrieved using familiar Java code allows students to focus more effectively on the object modelling process when developing Java-based web applications.

3

http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html 7

Appendix 1

References and Resources Roos Robin (2002) Java Data Objects Addison Wesley Sun’s JDO page http://java.sun.com/products/jdo JDO API and other resources: http://access1.sun.com/jdo/ JDO Central: Website of the JDO Developer Community. Includes a comprehensive list of JDO vendors http://jdocentral.com TheServerSide: J2EE Community website, host to some interesting discussion threads on JDO, particularly in comparison with EJB and O/R mapping tools http://theserverside.com The Solarmetric site, for downloads and licenses for KodoJDO http://www.solarmetric.com/Software/Evaluate/

8

Teaching Encryption to Reluctant Programmers Richard Hill & Dharmendra Shadija Faculty of Arts, Computing, Engineering and Science Sheffield Hallam University Howard Street Sheffield S1 1WB [email protected] [email protected]

Abstract An approach to teaching encryption is described in which an XOR encryption algorithm is used to demonstrate simple encryption concepts for E-Business payment with credit cards. Small groups of undergraduate and postgraduate learners manually encrypt a four-character word, and then exchange the encrypted data with another group. Each group then attempts to decrypt the data as quickly as possible. Learners show an increased understanding of the encryption process and demonstrate greater success when programming in subsequent tutorials. This work is currently being developed to enhance the teaching of asymmetric Public Key encryption.

Keywords E-Business, encryption, teaching & learning, JavaScript, online payment

Introduction This paper describes an experience of teaching programming techniques for encryption to undergraduate and postgraduate learners studying 'E-Business'. This module is an increasingly popular level 5 module option (second year undergraduate), selected by learners from a range of computing backgrounds. In addition, there is a large demand for E-Business teaching at postgraduate level also. The module comprises a variety of topics including, marketing, strategy, portals, client-side and server-side programming, encryption and payment processing. Learners are introduced to concepts by a combination of online learning materials and weekly seminars. One hour tutorial sessions per week allow learners to practically apply their learning through a series of specific activities which are classroom or laboratory based. Learners are assessed in three ways: 1. Throughout the year by means of regular Phase Tests; small multiple choice tests conducted online to test knowledge of concepts and the relevant jargon. 2. A group assignment in which they propose a business case for an e-business venture and then produce a functional prototype application. 3. End of year written exam. The broad module content tends to challenge all students, irrespective of background, and we have experienced particular difficulties whilst attempting to teach encryption programming. This paper discusses a 'back to basics' approach and our results to date.

Student Profile The wide range of skills and abilities can be difficult to address when designing course materials and the perennial problem of addressing specific skill deficiencies, without holding

1

back high achievers was particularly prevalent. Most of the learners have weak programming skills, and tend to prefer the use of tools to build applications. Many of the learners also work part-time to fund their studies, and exhibit a pronounced 'need to know' attitude, by which they openly question the industrial relevance of topics. Within the cohort there are three broad categories of learner: 1. Software Engineering/Network Engineering. These learners are technically quite able, and find the programming demands from E-Business fairly straightforward. 2. Business Information Systems. This category of learners are generally high achievers, though they do demonstrate mental barriers towards programming. Once they overcome their initial fears they become capable programmers. 3. ‘Generic’ Computing. These learners find programming difficult and need a significant quantity of support. They struggle with syntax and often get bogged-down with logic.

Understanding Concepts The barrier to programming lead us to conclude that we should spend the minimum amount of time on actual implementation; however we felt that although we wanted to successfully teach the concepts, we still had to demonstrate the practical relevance of the learning. We decided to recreate a typical E-Business scenario where a customer wishes to pay for some goods online. Immediately this requires a web form and some simple validation. Our first attempt focused on the web form generation, and we quickly lost the learners when it came to implementing the encryption logic with JavaScript. Our experiences of teaching programming ranged from painful to tolerable, especially with such a varied level of learner interest and ability. However, web page scripting technologies do seem to be received rather better than C or Java, even amongst self-confessed reluctant programmers. These learners are able enough to copy scripts and customise through editing, very successfully in some cases after witnessing their web design efforts. This proved puzzling, as we assumed that the learners would take to the JavaScript and get on with the business of understanding the encryption concept. What we had not realised was that it was the misunderstanding of the encryption logic that was creating the problem, rather than knowledge of the JavaScript syntax. The learners blamed their ignorance of programming, and the sessions were judged to be largely unsuccessful. After much consideration we decided to try and make the learning of the concepts more transparent. Our previous attempt did not truly focus on the concepts that we wanted to teach, and we had not addressed the barrier towards programming. In fact we had faced it head-on without teaching the underlying encryption principles.

Outline of Session The fundamental concepts that we want to describe are: 1. A method and process logic for encrypting plaintext messages into cyphertext. 2. An appreciation of the resources required to decrypt a message using brute-force techniques. After the normal class administrative tasks, a problem is described. The scenario is based upon the transmission of a credit card account number from a client machine accessing the Internet to an online store. A short class discussion highlights some pertinent issues including: • HTTP requests are insecure and could be ‘listened’ to by another party;

2

•

If the credit card number entered is incorrect then the server has to process the entire number before detecting the error, thus increasing network traffic and giving the user a perception of a 'slow' interface; To fully validate the credit card number at the client-end would require every credit card number issued to be downloaded to the client; It is possible to perform some basic client-side checks in the browser to reduce the impact of erroneous entry on server performance.

• •

Additionally the process logic of symmetric encryption is discussed as below (Figure 1): Encryption

Plaintext

Algorithm

Cyphertext

Key

Figure 1.

An eXclusive OR (XOR) encryption algorithm, which is available in JavaScript is explained using a truth table as follows (Table 1): A 1 1 0 0

B 1 0 1 0

A VB 0 1 1 0

Table 1.

A worked example is provided, showing the process of encrypting the word “FRED”. 1. 2. 3.

Work out the Binary equivalent of FRED. Choose a key and an algorithm. In this case '00000011' and 'XOR' are used. The XOR encryption is applied to the word. This is then converted back to ASCII and the resultant cyphertext is 'EQFG'. In order to 'hack', a number of possible 4-bit keys are used starting with '00000001' and ending with '00001111' ('00000000' is not a choice. Why?).

4.

Text FRED

Binary 01000110 01010010 01000101 01000100

Key 00000011

Table 2.

To apply an 8-bit encryption you must break-up your binary number into 4 parts, and then apply the XOR algorithm. 01000110 01010010 ^ ^ 00000011 00000011 01000101 01010001 01000101 01010001 01000110 01000111

01000101 ^ 00000011 01000110

01000100 ^ 00000011 01000111 EQFG

Table 3.

3

Once the text is encoded, you will have to decode using all the possible keys and then check the messages to see if it makes sense. You can see in Table 5 that if we use all of the keys, only one of the decoded words makes sense. Text EQFG EQFG EQFG EQFG EQFG EQFG EQFG EQFG EQFG EQFG EQFG EQFG EQFG EQFG EQFG

Encoded Binary Equivalent 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011

Key 00000001 00000010 00000011 00000100 00000101 00000110 00000111 00001000 00001001 00001010 00001011 00001100 00001101 00001110 00001111

Decoded message 01000100010100000100011101000110 01000111010100110100010001000101 01000110010100100100010101000100 01000001010101010100001001000011 01000000010101000100001101000010 01000011010101110100000001000001 01000010010101110100000101000000 01001101010110010100111001001111 01001100010110000100111101001110 01001111010110110100110101001101 01001110010110100100110101001100 01001001010111010100101001001011 01001000010111000100101101001010 01001011010111110100100001001001 01001010010111100100100101001000

Table 4. 01000100010100000100011101000110 01000111010100110100010001000101 01000110010100100100010101000100 01000001010101010100001001000011 01000000010101000100001101000010 01000011010101110100000001000001 01000010010101110100000101000000 01001101010110010100111001001111 01001100010110000100111101001110 01001111010110110100110101001101 01001110010110100100110101001100 01001001010111010100101001001011 01001000010111000100101101001010 01001011010111110100100001001001 01001010010111100100100101001000

DPGF GSDE FRED AUBC @TCB CW@A BWA@ MYNO LXON O[MM NZML I]JK H\KJ K_HI J^IH

Table 5.

The use of hexadecimal tables is also demonstrated by converting a four-letter word into hex, then into binary, ready to be encrypted. This session concentrates on developing an understanding of the logic of the process; a subsequent session deals with the JavaScript and server-side implementation. Upon completion of the worked example, the class is put to task. The class of 20 students is divided into four groups, who must each decide upon a four character word to encrypt, using one of fifteen keys (00012 to 11112 ) prepared by the tutor beforehand (Table 4.). Encrypted words are then exchanged between groups, and the decryption process is started. At this stage learners are left to their own devices; the tutor merely provides clarification, if and when required. Most of the learners were intrinsically motivated to perform the task, and any that were initially reluctant became involved quickly. Learners are permitted to use a computer to look up hexadecimal values, or use a spreadsheet to record their progress, but they are discouraged from attempting to write a program. The

4

emphasis is to manually decrypt the cyphertext, to give them an appreciation of the enormity of the task.

Results The session proved to have an immediate impact on the teaching of encryption logic. Other tutors on the module also commented positively and experienced a much more successful session. The improvement was two-fold: 1. The encryption session was enjoyed by all participants, and little intervention from the tutor was required. Learners were focussed and quickly organised themselves, devising strategies to ‘win’. Evaluation of the session was also productive, with learners actively discussing and debating learning points, as well as the use of different strategies. For instance some groups took a random approach to finding the key, by guessing, whilst other groups were more methodical and worked through all the combinations until they succeeded. Significant learning points emerged, particularly when one group mistakenly used the AND operator instead of XOR. As a result, the cyphertext could not be decoded, but it was the learners who deduced the error whilst decoding, reinforcing the understanding of the algorithm. Application of learning was demonstrated by learners who used spreadsheets to record their activities and check that every combination of the key had been explored. 2. The next session required learners to develop a client-side form using JavaScript to perform basic validation checks on a credit card number before encrypting and sending to a database. Prior to the revised approach to teaching encryption this session was fraught with difficulties and in many cases was not productive for the learners. Learners did not understand the concepts or the logic, and struggled also with syntax. After attending the encryption tutorial, the learners were clearly more comfortable with the underlying principles and could concentrate on syntactical and typing errors. This was also confirmed by students who were absent from the first session, who found the JavaScript implementation difficult to comprehend. An informal straw poll of students at the end of the module supported this in so much as when asked which tutorial they remembered most, they all said, ‘the hacking class’.

Future Work In terms of teaching the principles of encryption to learners, this session has proved useful on the postgraduate programme also. However, as many of the postgraduate learners either have prior industrial experience or are currently working, it was decided that a more relevant example of encryption was required. Contact time with undergraduate students is limited, and considering the breadth of topics undertaken for the E-Business module, two sessions on encryption is already regarded a luxury. However, the teaching at postgraduate level is generally more flexible, particularly on residential courses, so it was decided to develop the exercises further. One general outcome from the first session is that the learners have gained confidence in their ability to decrypt a simple symmetric cyphertext, to the point that some of them believe they can decrypt anything. We decided to address this by extending the exercise to include asymmetric encryption, using private and public key pairs.

5

Additionally we have decided to formally record some data and we shall commence by asking each learner to assess their own skills and abilities. This exercise will then be compared with the results of an end-of-module evaluation questionnaire. The key concept we are attempting to demonstrate is that whilst symmetric encryption can ‘mask’ a message, an exchange of keys still has to take place. Again students will manually generate public keys, and this time will post them onto an online discussion forum such as that provided by Blackboard. The Prime numbers used to generate the keys will be restricted by the tutor to give the learners a chance of decoding the key. In small groups of learners they will choose one of the public keys and attempt to decrypt it by using a calculator and a list of Prime numbers. Of course it is very difficult to find the answer, and it is feasible that many groups will not achieve this in the time available. Knowledge of these concepts does open up opportunities for interesting assignments or homework; learners could be given an encrypted answer to an assignment question, or an encrypted list of questions that might appear in a subsequent phase test. It is envisaged that the competitive atmosphere generated by our initial experiments will also transfer through to the further work described, together with the associated benefits.

References Blackboard Inc., URL: http://www.blackboard.com/ [last accessed 1/11/2003] Rezai, M., E-Business, URL: http://www.shu.ac.uk/schools/cms/teaching/rh1/ebiz/index.html [last accessed 1/11/2003]

Rubin, Aviel D. "An Experience Teaching a Graduate Course in Cryptography." Cryptologia 21, no. 2 (Apr. 1997): 97-109.

6

The Embedded Web Klaus D McDonald-Maier University of Kent, Department of Electronics, Canterbury, Kent, CT2 7NT, UK Email: [email protected] Abstract This paper discusses the curriculum development of a teaching module for embedded web servers as well as the design and development issues for such web servers. The module is supported by practical lab sessions where the students configure and program such an embedded web server by generating html files to monitor the temperature and filling level of a fridge, and to also regulate the temperature through the web. Work is underway to extend this to the web based control of a roving robot. 1. Introduction This article discusses the motivation, development and implementation of The Embedded Web, a final year teaching unit that introduces the principles, design and programming issues for embedded web servers to students on a Multimedia Technology and Design (MTD) course. This new course integrates creative content composition and design with the underlying technology for the communication of such content. The Embedded Web was motivated by the fact that embedded systems play an ever increasing role in our lives. Of the 6.2 billion processors manufactured in 2002, less than 2% became the brains of new PCs, Macs, and Unix workstations. The other 6.1 billion went into embedded systems. The essence of every modern electronic device, from toys to traffic lights to nuclear power plant controllers, these rely on processors to help to run factories, household devices, and enable the flow of information, products, and people. Virtually every electronic device designed and manufactured today is an embedded system [1]. Increasingly, these embedded systems become candidates for what is also referred to as ‘embedded internetworking’, that means embedded applications that turn into small scale embedded web servers and provide internet access [2, 3]. The main objectives of such systems are the control of electronic devices and possibly selfmaintenance of the device and pervasive, wearable computing. These developments serve as background for The Embedded Web teaching unit, as they are particularly relevant for students on a course such as our MTD programme. 2. Content Development Background research into content available for the general field of the The Embedded Web yielded only limited results in terms of similar programmes or related teaching material. This seems to be mainly due to the fact that the field is only recently beginning to emerge and draws on the fields of embedded systems and internet technology, integrating both with focus on the requirements of small scale embedded webservers.

Based on these requirements the course content was divided into several parts and a related laboratory based experiment is outlined in the following sections. 2.1. Introduction to embedded systems and Web servers This particular part of the unit introduces embedded systems as combinations of hardware and software that are used for specific applications and are subject to constraints. Typical functions of embedded systems are to monitor and control their environment using sensors and actuators. Constraints for embedded systems are among others small size, low weight, low cost and reliability. Embedded systems might also not have disk drives, keyboards, display devices and are typically restricted in terms of power, memory, user interface and debugging interfaces. The central building blocks are microcontrollers, i.e. microprocessors integrated with memory units and specific peripherals for observation and control of the environment of these embedded systems. Following the embedded systems introduction, the ‘Client-Server Model’ is presented to describe the basic functional principle of a web server: the internet based service provision for users. The model is based on two computers that run application programs where one provides a service (the server) and one requests a service (the client). This clarifies that in fact, application programs communicate with each other and not users or computers. A consequence of this is that one machine can be both a client and server. The client runs only when needed by the user, then it actively opens communication to the server and closes it again when finished. In contrast the server is running infinitely but only initiates service when it is requested to do so by a client. 2.2. Ethernet and TCP/IP protocol based communication With focus on current and future applications for the embedded web a central underlying principle is the Ethernet and TCP/IP protocol based communication. As second part of this unit, the concepts behind currently used internet infrastructure are discussed. First a basic description of internetwork topology is described, based on three hierarchy levels that are connected through routers that select the path for data packets to be communicated: 1. A subnetwork that is just a simple LAN, 2. a network that is a collection of subnetworks linked through routers and 3. an internetwork that is a collection of networks, again linked by routers. With a basic understanding of the topology in place, the ‘nuts-and-bolts’ of TCP/IP based communication are covered. IP addresses are introduced and the use of subnet masks to identify if there is a direct connection between two nodes or if routers have to be used is explained. The principle function of the IP, i.e. routing, is clarified and the general structure of an IP datagram is analysed. This is then extended to the second part of the TCP/IP protocol architecture TCP which is responsible for creating a reliable connection between two network nodes. The underlying principles and operation are discussed. A web server operates by using HTTP over a TCP/IP protocol architecture. Therefore the principle aspects of the Hypertext Transfer Protocol were also covered. The HTTP

protocol essentially works by exchanging text messages followed by transfer of web data across TCP connection. 2.3. Design aspects of a miniature Web server implemented on a microcontroller Based on the http communication across a TCP/IP based communication the requirements for an embedded web server can be identified: Clearly a TCP/IP based communication interface is essential for the web server. Beside that a basic HTTP protocol support needs to be present as well. With respect to real-world applicability, control I/O, size and cost are decisive factors for such web servers. This points to implementations using low-end microcontrollers that are low cost, small and provide sufficient I/O capability to observe sensors and control actuators. With the prime focus of the module being directed on the understanding of embedded web servers and not directly related to its actual implementation, a suitable sample implementation was identified to further discuss practical aspects and use cases for an embedded web server. PICDEM.net [4] is a demonstration implementation for a TCP/IP based embedded web server based on the popular PIC microcontroller platform [5]. It is a typical low specification microcontroller that could be equipped to operate as a miniature web server. The PICDEM.net platform is based on a PIC 16 series PIC Microchip microcontroller, a general purpose microcontroller which is relatively low in cost and size. It provides a number of integrated peripherals such as analogue-to-digital converter, pulse-width modulation modules, serial ports and synchronous / asynchronous receiver-transmitter sets. Particular aspects of the basic function and operation of these peripherals were introduced to the students to demonstrate the basic features of the embedded microcontroller and how this is interfaced with networking infrastructure, sensors and actuators. To determine the detailed implementation requirements a careful evaluation of the different available protocols and applications is undertaken to decide what is needed and what can be omitted. This is a crucial consideration as the microcontroller devices often lack sufficient CPU and memory resources to handle the entire TCP/IP stack and all of its variations. Located in the middle of the entire communication stack, the TCP/IP layers ensure proper point-to-point communication and take care of the routing and delivery of packets. With the limited processing and memory infrastructure available it is essential to strip down the system to the bare essentials. When implementing the TCP/IP protocol stack to medium or low-performance microcontrollers, a number of functions normally used within the TCP/IP stack can be safely omitted, depending upon the specific application requirements. For example, the support for fragmentation is one of the first candidates we can consider dropping completely. In the IP layer, messages that are longer than 1,500 bytes are fragmented during transmission and then reassembled by the receiver. On an 8-bit microcontroller with a total address range of 64 kbytes, one does not want to waste any of

valuable code space. In any case, the device must generate an appropriate error response; if a large, fragmented message is sent to it. 2.4. Development of HTML and Java script code for the Web server to interact with external hardware. A classic web server simply provides without alteration, it is simply a file server. In contrast to this a more advanced, dynamic Web server alters web pages on the fly and creates web pages from scratch when requested. This can be realised by means of a Common Gateway Interface (CGI). Such a CGI relies on the manipulation of large amounts of strings which, as a result, require a powerful machine with high level language such as Perl. For embedded web based control the ability of inserting live web pages is also required but this has to be done using only modest computing resources. Implementing the CGI standard is problematic for embedded control particularly since it requires the simultaneous execution for several connections which is not possible on a modest microcontroller CPU. Therefore a specific API needs to be generated that includes some CGI like functionality. The minimal functionality to be included in this API is to call an application specific function when a page is fetched from the server and to call application specific functions using embedded tags when the file is being sent out. The PICDEM.net implementation contains a TCP/IP stack and also an API as described above. After a detailed coverage of the implemented functionality a design example that is related to the laboratory class described in the following is investigated. 2.5. Laboratory Class: A Web server to control refreshments provision. This one-day Laboratory Class is designed to give students experience in using a small scale microprocessor based embedded web server to carry out several tasks, thereby supporting the lecture course. The experiment uses a PICDEM.net development board system for the capture, processing and display of sensor readings representing weight and temperature. Furthermore these sensor readings will be used for control of an active cooling element for a small fridge. This experiment gives the students the opportunity to get some practical experience in implementing and applying some of the techniques which have been introduced in the course. In this experiment the students will be encouraged to develop several pages for the embedded web server using HTML and Java Script. This will allow them to see at first hand what is involved in developing the content of an embedded web server used for data capture, processing and control as well as providing some practical demonstrations of the effects their work is likely to produce. 3. Conclusions Both the module content and the practical class for a novel course in embedded web servers have been introduced. Both the taught lectures and the laboratory class are briefly outlined to provide an overview of the content.

The student’s feedback for the module indicates that is well received. In particular the practical aspects in terms of implementation and the related laboratory class, are very well received by the students. Currently these practical aspects are developed further towards an application of embedded webservers in the control of a roving robot such as the Hemisson robot shown in Figure 1 [6].

Figure 1: A candidate for embedded control: the Hemisson roving robot [6].

References: [1] [2] [3] [4] [5] [6]

Ganssle, J.G., Barr, M.: Embedded Systems Dictionary, CMP Books, Gilroy, CA, 2003 Pfeiffer, O., Rodrigues, J.: 'Internetworking' treads on MCU turf, EE Times, May 21, 2001 http://www.eet.com/story/OEG20010521S0066 Pfeiffer, O., Rodrigues, J.: Internet connectivity: The time is right and the technology is ready for you, http://www.esacademy.com/faq/docs/embint/index.html http://www.microchip.com/1010/pline/tools/picmicro/demo/pdemnet/ Bentham, J.: TCP/IP Lean – Web Servers for Embedded Systems, R&D, 2002, ISBN 1-578-202-08X http://www.hemisson.com, these robots are designed, manufactured and distributed by K-Team S.A., Switzerland.

.NET & Web Services by Lockyer et al

University of Teesside

.NET & Web Services Mike Lockyer, Gary Griffiths, Briony Oates, Barry Hebbron School of Computing University of Teesside Middlesbrough, TS1 3BA UK [email protected]

ABSTRACT

In this paper we present our current approach to teaching .NET and web services within an integrated approach to the development of Complex Web Applications. The principal philosophy of the development is to support simplicity, consistency, completeness and traceability. We present details of the method, process model, notations and tool, and draw conclusions about the suitability of such an approach for inexperienced developers.

KEYWORDS

Web Services, Web Development, Web Engineering, CASE. 1. Introduction In this paper we describe our approach to the teaching of .NET and Web Services and explore techniques and tools to support the analysis, design and implementation of web systems that are simple enough to encourage their use. Our principal focus is on an approach that would be ideal for inexperienced users in industry or for students. There are many novice web developers in industry, and that is likely to be true for some time given the forecasts of the extra numbers needed in the next few years [Andersen, NCC]. So, simple methods are in the interests of commercial developers. This is backed up by recent research [Barry] that showed that current methods are not being used in industry, but that the simpler techniques (like storyboards and navigation charts) are popular, usually within an in-house method. It has often been the case that education is neglected when considering methods [Lockyer, 1989] and simple, easy-to-learn methods would also be appropriate for students. 2. History The module that we are discussing is called “Designing for Web Exploitation” and is a core, double module in the second semester of the MSc in Information Technology. The MSc was rewritten a few years ago to have a web focus. The students study Java in the first semester and also undertake modules in systems analysis & design and networks. “Designing for Web Exploitation” was conceived as a server-side development module. The module has run for 5 years and was initially based on Active Server Pages.

jicc8-lockyer.doc

(Version : 2 saved on 03/11/03 14:59)

1 of 6

.NET & Web Services by Lockyer et al

University of Teesside

2.1 Active Server Pages (ASP)

Microsoft introduced ASP in 1996 and it underwent various version updates. It provides a way to create data driven web pages and runs within Internet Information Server (IIS). One of the advantages of ASP was that it was relatively easy to set up on a student’s home machine based on Personal Web Server and it would run on Windows from 95 onwards. The biggest problem with ASP was the lack of student-friendly tools and so one of the authors built a simple ASP-syntax editor (MASPEdit) with the following features : •

Syntax highlighting of ASP code

•

Syntax highlighting of HTML and Javascript

•

Embedded FTP upload to the server

•

Integrated run-time error reporting.

The course was a success: •

It was liked by students

•

It was liked by employers – a significant number of students went on to get server-side development jobs.

•

The grades were good.

There were some problems though: •

Network problems had a significant impact on the laboratory use as the students required access to the remote server to run their code.

•

The embedded ftp application meant that students lacked any real understanding of ftp issues when they moved away from MASPEdit.

•

Database access was restricted to Microsoft Access.

2.2 ASP.NET

When rumours of an update to ASP began to appear, we could see that ASP.NET would give us significant advantages over ASP: •

A proper integrated development environment

•

A graphical forms based designer

•

Integrated debugging

•

Use of SQL Server.

jicc8-lockyer.doc

(Version : 2 saved on 03/11/03 14:59)

2 of 6

.NET & Web Services by Lockyer et al

University of Teesside

We used ASP.NET in 2002 for the first time. It went well and the students thought it the best module on the MSc. There were problems though: •

The ideal configuration required a local version of IIS and administration rights.

•

There was a lack of suitable text books

•

The graphical forms based designer tended to create unreadable code.

•

Following the Microsoft professional training course was not a success.

•

We did not use any analysis and design tools.

This year our intention is to rewrite the course structure based on a 3 level approach: 1. Explain the concepts using an example but with no mention of a Microsoft approach. 2. Look at the basic code necessary to perform that operation 3. Look at using Visual Studio .NET We also intend to embed the course with a Web Method. 3. Web Methods We have considered the development of Web Sites and Simple Web Applications in another paper [Griffiths, 2002], so for the remainder of this paper we will concentrate on Complex Web Applications. Complex systems could be developed using traditional Information Systems methods like Yourdon [Yourdon] or UML [Rational] augmented with techniques for web page design. Alternatively, specialised web methods could be used, like WebML [Ceri] or Conallen’s adaptation of the UML [Conallen]. We wanted to explore the appropriateness of structured methods [Yourdon, Ashworth, Griffiths 1998] for web development for simplicity and for teaching. 4. Philosophy In order to provide a simple method for developing Complex Web Applications (CWAs), we propose the Simple Web Method (SWM): a strong integration between three support mechanisms. 1. A Process Model – provides the steps 2. A Web Notation – provides a set of modelling notations 3. A Software Tool – automates modelling and performs consistency and completeness checks. 4.1 The Process Model

Before we look at the Design and Build stages of SWM for Complex Web Applications in section 5, we should briefly consider the Analysis stage. Planning, analysis and maintenance would be very similar for Web Sites and Web Applications. In fact, the only difference is the Content Analysis jicc8-lockyer.doc

(Version : 2 saved on 03/11/03 14:59)

3 of 6

.NET & Web Services by Lockyer et al

University of Teesside

and Modelling step in the Analysis stage. For Complex Web Applications, we are not trying to model content so the step is inappropriate. However, the essence of the step – to define the scope of the system – is still appropriate. We do this in a similar way to defining the scope of a development in structured methods. We draw a data flow diagram to model the whole system and then draw a dotted line to denote the ‘Web Boundary’ (rather than the ‘Automation Boundary’ traditionally). 4.2 The Web Notation

The Web Notation essentially comprises three models : an event list, an Entity Relationship Diagram and a Web Flow Diagram. The first two of these are well known [Yourdon]. The notation used within our Web Flow Diagram uses elements of Data Flow Diagrams [Yourdon] and WebML [Ceri]. To visualise richer concepts, and yet control the complexity of those concepts, we have extended and enhanced the original notations [Lockyer, 2002]. 4.3 The Software Tool.

The software tool ASCENTW is a direct descendent of ASCENT [Lockyer 1989, Hoggarth]. It supports the web notation defined above and provides code generation to ASP, PHP and ASP.NET. It is important that the tool supports simplicity. Consequently the tool helps developers control the complexity by providing explosions and drill down mechanisms enabling them to perceive the system at an appropriate level of abstraction required at any particular point in the process. The tool filters the models to present the most appropriate view of the model. It allows the developer to take a user view or a data only, structure only, event only view. When the tool allows the model to be compartmentalised on a particular event, then the response thread for that event can be isolated, presented and animated. (See [Lockyer, 2002].) 5. Design And Build Steps For Complex Web Applications The design and build of Complex Web Applications are described briefly below. More detail can be found in [Lockyer, 2002]. List events and entities - a rough list of events and entities within the system are made. This is not an exhaustive list at this stage and the process is more akin to brainstorming than to a methodical approach. Relationships are not identified for entities until later. Consider events methodically - the rough event list is considered in detail and broken down. Events may be composed of sub-events, which we call tasks. Also, each task may have system responses. All of these are recorded at this stage. Sometimes storyboards are used, not to map the layout of the pages, but to help think about events, tasks and responses. To consider the events in this level of detail helps discover and focus on missing events, missing entities, attributes for entities, data administration and referential integrity Verify events with users - the full list of events, tasks and responses are discussed with the users for verification. This usually results in some changes to the list. Complete attributes for entities - some attributes for entities will have been recorded when considering the events methodically. All of the entities must now be examined in turn and a complete list of attributes recorded for each.

jicc8-lockyer.doc

(Version : 2 saved on 03/11/03 14:59)

4 of 6

.NET & Web Services by Lockyer et al

University of Teesside

Generate test plan from full event list - it is relatively straightforward to define an initial test plan from the full event list by defining a test for each event, checking that each task is accomplished successfully. Build entity relationship diagram (or class diagram) - a hierarchy of entitie s would indicate an OO approach and would lead to modelling the data in a class diagram. A complex structure with many to many relationships would indicate a structured approach and would lead to modelling the data in an entity relationship diagram. Relationships are added to the entities to build a full entity relationship diagram. Types of user, obligatory/non-obligatory relationships and referential integrity are all considered to complete the model. Build the database - the database is implemented from the entity relationship diagram, defining required fields and data types. Stored procedures and the database access layer are also considered. Stored procedures are SQL statements or queries that are stored in the database, not in separate pieces of code. These are more efficient and more secure, but difficult to debug. These would not be used in the first prototype, but might be used subsequently. The database access layer is a set of functions that allow database access without SQL. It is particularly useful with an OO approach although there are substantial benefits for any system. It needs to be decided at this point because it is difficult to change later. Draw storyboards by going through each event - each event could generate many storyboards (or pages). Exceptions should be identified and the delivery technology for the web front end to the system should be considered e.g. HTML, Flash. The links to the database from each page should be considered. Develop page templates - this step is interleaved with the previous step to draw storyboards. It is useful to consider if the templates form a set or a hierarchy at the outset as this can lead to coding sharing and simplifications. When developing the templates, ‘controls’ may be developed which sit in parts of the page and provide the links, content or functionality. Visual style is considered and style information is defined, like in a Cascading Style Sheet. Navigation is also considered. Verify storyboards and page templates with users - storyboards and page templates are shown to users and amendments made based on their feedback. The presentation to users could be on paper, in a word processor or with an HTML mock-up created quickly with something like Dreamweaver. Integrate storyboards for all events - the sequence of pages and database table accesses for each event should be modelled graphically. The resulting diagram is not unlike a web-oriented data flow diagram. Prepare for code generation - for most pages we need to define the purpose of the page (or sub page), give it a pagetype and define the SQL statement. The types of page (or sub page) and implementation strategy is system & language dependent. For instance, in Active Server Pages (ASP) and PHP we would need to implement a number of separate server-side pages to perform adding data, updating data and sorting data. In Microsoft’s .NET version of ASP, only one page needs to be implemented as all that functionality can now exist in a single page. Implement access for different types of user - we need to model the different types of user that the system needs to respond to and to define types of users’ access rights to pages. This needs to be supported at the code generation stage.

jicc8-lockyer.doc

(Version : 2 saved on 03/11/03 14:59)

5 of 6

.NET & Web Services by Lockyer et al

University of Teesside

Refine the HTML - having written or generated the server-side pages neede d to run the application, it is usually necessary to refine the HTML in order to enhance the user-interface. 6. Conclusion In this paper we have described our teaching of .NET and Web Services utilizing a Web Method. We have revisited our Simple Web Method (SWM), which was formulated with the development of Web Sites and Simple Web Applications in mind, and considered the appropriateness of the stages and steps for developing Complex Web Applications. All of the stages, and most of the steps, are appropriate for both types of web system. We have proposed the philosophy for our Simple Web Method that it exists as a strong integration between three support mechanisms: the Process model, the Web Notation and the Software Tool. We have set out the activities that are different for Complex Web Applications. In doing this SWM has moved towards being a process model rather than a simple method. That is, SWM does not now set out a sequence of steps to be followed in developing any web system. Rather, it defines a menu of possible steps, and a method (or process) would be instantiated from this to develop a particular system. There are a number of areas for further work, particularly method guidance and integrating the Windows-based ASCENTW with our web-based diagram editor to enable a complete internet based development environment.

References Andersen Consulting, 2000, Internet Enabled Job Creation, Andersen. Ashworth and Slater, 1993, An Introduction to SSADM Version 4, McGraw Hill. Barry and Lang, 2001, A Survey of Multimedia and Web Development Techniques and Methodology Usage, IEEE Multimedia, April-June, 2001 Ceri, Fraternali and Bongio, 2000, Web Modelling Language (WebML): a modelling language for designing web sites, Proceedings of 9th International WWW conference, Amsterdam. Conallen, 2000, Building Web Applications with UML, Addison Wesley. Griffiths, 1998, The Essence of Structured Systems Analysis Techniques, Prentice Hall. Griffiths et al, 2002, A Simple Method and Tool for Web Engineering, Web Engineering Workshop, Proceedings of Software Engineering and Knowledge Engineering, Ischia, Italy. Hoggarth and Lockyer, 1996, Systems Development Methods Guidance and CASE: An Integration between CASE and CAL, Software Engineering Journal, May 1996 Lockyer and Griffiths, 1989, ALSETT - Towards an Educational IPSE, Software Engineering Journal Lockyer, 2002, AscentW : a Tool to support Web Development, University of Teesside technical report, available at http://scm-wiz.tees.ac.uk/research/webeng/ascentw.pdf NCC, 2000, Salaries and Staff Issues in IT 2001, NCC. Rational Inc., 2001, The Rational Unified Process, Rational. Yourdon, 1989, Modern Structured Analysis, Prentice Hall.

jicc8-lockyer.doc

(Version : 2 saved on 03/11/03 14:59)

6 of 6

SWMing at Teesside

University of Teesside

1 SWMing at Teesside By

G Griffiths, B D Hebbron, M A Lockyer, B J Oates University of Teesside 2

Abstract

In this paper we outline the development of Internetrelated modules and degree routes at Teesside. We focus on the Web Engineering module, explaining how we make the case for engineering web systems and survey web methods and techniques. We introduce the method we have developed: The Simple Web Method (SWM, pronounced ‘swim’), and describe it in use. We discuss student evaluation and tool use.

1

Introduction

In the early 1990s a group at Teesside held a series of meetings to discuss what they called ‘Millennium Computing’. This resulted in our first Internet-related degree route called Information Society (after the EU label). The curriculum was a blend of Web technologies and sociology. It was soon decided to develop a technology-only route and B Sc Multimedia was launched. The main focus of this route was off-line multimedia (i.e. development for CDs), although there were a significant number of Web modules. There was demand from students for a creative route that concentrated more on content production than system structure and BA Creative Multimedia was approved. In 1999, Murugesan et al [1] published their ideas about Web Engineering. A research group was formed in this area at Teesside and it was decided to develop a Web Engineering degree route. For marketing reasons it was eventually decided to call it Web Development. In the first year students cover programming in Visual Basic, web development in HTML, Dreamweaver and Flash, and content production (capturing and embedding images, video, streaming etc.). In the second year the students cover databases, web application development in ASP and various other technologies (e.g. PHP, PERL), together with a group project. In the final year they cover Web Development Issues, Web Server Administration and choices from a range of other options.

3

Types of Web System

The discussions of the Web Engineering research group concerning different types of web systems contributed to the structure of the Web Development degree. We have often found it difficult and confusing to try to communicate about web engineering and web development. One reason for this is vocabulary: there are sometimes a number of different names for essentially the same thing. Another reason is the range of different types of web site that exist. When discussing techniques that are necessary for web site development, it is unlikely that the participants will agree if the example uppermost in one person’s mind is a document-oriented information site (like the news pages on the BBC web site [2]) and the example uppermost in the other person’s mind is a database-driven e-commerce site (like Amazon [3]). The challenge is to accommodate a diverse range of experts, each with their own traditions and approaches. Even if an 'essentially creative person' and an 'essentially technical person' were solving the same problem, they would approach it in different ways, use a different process and a different set of tools, techniques and vocabulary. The challenge is to identify a method in which a broad church of disciplines could coexist and work together. It could be argued that there is a continuum of different types of web systems from pure, static information s ites, through systems that maintain state or process information client-side, to dynamic systems with serverside database processing. Conallen 4[ ] suggests that there are essentially two types of web-based systems – Web Sites and Web Applications. The former are information sites, the latter are more like traditional information systems but operate over the Internet. It is attractive for simplicity, and in considering the techniques to be used in different types of web-based systems, to adopt Conallen’s two-types view, distinguishing between sites that have a database and sites that do not. This led to simple framework for web system modelling. WEB MODELLING INTERACTION MODELLING DATA MODELLING

The top layer, Web Modelling, must be undertaken for all web systems to plan and design the structure of the site, rough out what the pages will look like, and so on.

jicc8-griffiths2.doc

Page 1 of 6

SWMing at Teesside While Web Modelling must be undertaken in the development of all web systems, for Web Sites it is the only modelling that needs to take place. Web Applications (i.e. database-based web systems) require two further types of modelling: Data Modelling and Interaction Modelling. First, the database should be modelled using Data Modelling. The most obvious ways of doing this are to use entity relationship modelling and normalisation from structured methods (e.g.Yourdon), or class diagrams from object-oriented methods (e.g. Conallen). Second, once the web site and data are modelled, Interaction Modelling can be carried out. This involves mapping the interaction between individual pages in the web site and individual tables in the database. The framework helped us to see how we could structure the course. It is also useful for teaching in that we can reveal the complexity of the problem in layers as the students progress through their course. In the first year we concentrate on web modelling and development by HTML and packages. In the second year we move on to data modelling and database development, and interaction modelling and development using technologies like ASP.

3

The Web Engineering Module

Before the development of the Web Development degree, one area that the B Sc Multimedia staff had highlighted as missing from the curriculum was systems analysis for the Web and Multimedia. This was addressed by the introduction of a Web Engineering module into the Multimedia and Web Development degrees. The module

University of Teesside available to the students to allow them to learn. The teaching approach is based on problem based learning. The group-based assignment is handed out early in the module and the students follow the web method from start to finish, applying the techniques to their assignment. To reinforce the module focus, two -thirds of the marks are for the planning, analysis and design artifacts.

4

The Case for Web Engineering

The case for Web Engineering is not difficult to make to the students. Murugesan et al [1] argue that there is a ‘web crisis’ now, similar to the ‘software crisis’. They state that “poorly developed web-based applications that are mushrooming now have a high probability of failure”. They further argue that ‘web engineering’ should be the answer to the web crisis. Also, according to Nielsen [5], “There are essentially two approaches to design: the artistic ideal of expressing yourself and the engineering ideal of solving a problem for a customer”. While art is undoubtedly important on the Web, and can pose a significant challenge to more technically -oriented web developers, we argue that an engineering approach to design and development is crucial if we are to avoid repeating the mistakes of the past which led to poor quality, unreliable, inflexible and unmaintainable systems. Perhaps more persuasive is recent research into web systems by Ginige [6]: •

84% of systems don’t meet business requirements

•

53% of systems functionality

didn’t

have

•

makes the case for engineering web systems

•

surveys web methods and techniques

•

79% of projects were late

•

proposes a web method for the students to follow.

•

63% of projects exceeded budget.

the

required

These bullet points are all discussed further in following sections. This information is presented to students on a set of lecture notes and an associated web site. The learning is progressively student-centred with one lecture per week in the first half and just two lectures in total in the second half.

Another survey of commercial web development organisations [7] supported the view that projects were often late and over budget. It also asked the developers why they thought this was so.

The focus of the module is skewed towards the early part of the life cycle, with two-thirds of the time spent on planning, analysis and design, with the remainder concentrating on the development of a prototype in Dreamweaver. The package is not ‘taught’ as such, but online tutorials have been developed and are made

•

jicc8-griffiths2.doc

The primary reason given was problems with Analysis)

the

Requirements

phase

(i.e.

Other reasons were •

poor project management

Page 2 of 6

SWMing at Teesside •

poor project estimation effort

•

inadequate testing

The survey also found that ‘the majority of the development processes seem to focus on Implementation with Requirements Capture and Design being carried out as one combined phase at the beginning’. The authors believe that the problems with capturing requirements stem from this faulty process. Analysis should be separate from and precede Design. Also, it should be given more emphasis in the process. This justifies our focus on the early stages of the life cycle. We balance our argument with Lowe and Hall’s view [8] that not all web applications need engineering. It depends on an application’s size, focus and intended life. For example, marketing and promotional material is small size with a presentation focus and short-lived. It can be approached in much the same way as a printbased brochure. However, larger applications with a “structural focus” and a longer, evolutionary life do need engineering, since such applications are often mission critical and maintainability and reuse are important. Most non packaged e-commerce sites, for example, which are essentially a database system with a Web front-end, need engineering.

4

Methods and Techniques for Web Engineering

A number of methods have emerged in the last few years to model Web Systems, for example, December [9], IBM [10], DiNucci [11] and Powell [12]. Among the most wellknown research originated methods are RMM [13], WebML [14] and Conallen’s adaptation of the UML for web development [4]. While these are all good ways of modelling web systems, there are a couple of reasons why we wanted to e xplore simpler avenues. First, one of the main reasons that we are interested in web development methods and techniques is for teaching. We wanted a method that was simpler than those currently available and thus easier to teach. Others have also expressed a desire for ‘lite’ methods for teaching to students [15]. Second, we strongly believe in the KISS principle (Keep It Simple, Stupid). We wanted to look for simpler methods not just because we thought that it would be good for our students, but because we thought that it would be better for everybody. There are many novice web developers in industry, and that is likely to be true for some time given the forecasts of the extra numbers

jicc8-griffiths2.doc

University of Teesside needed in the next few years [16, 17, 18, 19]. So, simple methods are in the interests of commercial developers too. This is backed up by recent research [20] that showed that current methods are not being used in industry. While the various processes and methods mentioned earlier appear to be somewhat different superficially, in essence there is quite a lot of agreement. There is also some similarity at a high level with software engineering methods and processes like Yourdon[21], SSADM[22] and UML processes[23].

5

Simple Web Method (SWM)

In considering which method to teach to our students for Web Sites in the Web Engineering module, we found that no one method had everything we thought was important. But, across the range of methods mentioned above, most things were covered. So we decided to synthesise one by cannibalising what we consid ered to be the best parts of two methods (IBM and December), and adding in parts from our own experience. This was called the Simple Web Method, or SWM (pronounced ‘swim’) [24]. This initial method only addressed Web Sites. We have since developed the method to address Web Applications as well. If we examine the life cycle, or process model, of different Web Site method authors, we can see some similarities with each other and with software engineering. IBM [10] propose a development process of Planning, Design, Production and Maintenance; Lowe and Hall [8] have Analysis, Design and Production, Verification & Testing and Maintenance; December [9] has Planning, Analysis, Design, Production, Evaluation and Innovation. The similarity with the widely -recognised software engineering stages of feasibility, analysis, design, implementation and maintenance can be seen. In the initial SWM for Web Sites, the stages and techniques used in the Web Engineering module are: • •

•

Planning Project Planning Quality Planning Analysis Statement of Purpose Audience Definition Content Analysis and Modelling Constraint Analysis Market Analysis Design Site Structure Page Design

Page 3 of 6

SWMing at Teesside

•

Visual Style Navigation Building Content Preparation Web Site Building Testing and Evaluation

At the Planning stage, a simple project plan is prepared. Quality planning consists of the consideration and documentation of two things: •

Reviews and Inspections – what reviews, inspections, testing, usability studies etc. are going to be carried out to ensure quality.

•

Change Control – How the updating of versions of analysis and design documents, products etc. will be controlled and what the arrangements will be for backing up older versions to allow backtracking.

At the Analysis stage, a statement of purpose is produced. This need only be a few sentences, but the process of reflecting on the purpose of the site, and trying to express it very concisely, is often instructive. It is also useful to show this to a client for early verification. The audience is defined by classifying primary and secondary audiences for the site. Accessibility is also taken into account and some ‘user scenarios’ are written – a fictitious walkthrough of a visit to the site by typical audience members. The content of the site is analysed and modelled, and content creation begins in parallel with the other activities. Constraints are analysed for any potential technical, human, information, organisational problems. Finally, the market is analysed for competing or similar sites. This can alert developers/clients to potential competitors and give some ideas about content and style. At the Design stage, there is some agreement on techniques. Key techniques for modelling the design of Web Sites are navigation charts and storyboards. Navigation charts show how the content of the site is split up into pages and how to move around from one to another. In SWM these are used to show the Site Structure. Storyboards show a mock-up or sketch of pages from the site. In SWM these are used to show the Page Design. These techniques are reminiscent of graphical techniques popular in software engineering methods. Vocabulary is a problem here and names differ from method to method. But, essentially, the branching diagram of Di Nucci, the Package, Page and Link diagram of December, the flow diagram of IBM etc. are all types of navigation chart. Similarly, December’s Look and Feel diagram, Di Nucci’s Page Architecture diagram etc. are all types of storyboard. There is also some agreement that

jicc8-griffiths2.doc

University of Teesside Visual Style and Navigation need to be considered at this stage. At the building stage, development details like directory structures, file naming conventions and version control are finalised. The content preparation is completed and the web site built. This is then subject to testing and evaluation before launch.

6

Tools for Web Engineering

There are many tools available to support the building of web sites, but few that support their planning or design. Some, like Net Objects Fusion, allow the drawing of artifacts like navigation charts, but these tools are still essentially designed to support implementation. We used Net Objects Fusion the first time we ran the Web Engineering module because it forces the user to model the structure of the site before putting the content into pages, which reinforced the engineering model we were promoting. The students would have preferred the more popular Dreamweaver and we have now moved to that with the demise of Net Objects Fusion. We developed a Project Automated Web Site (PAWS): a repository for deliverables associated with project work by student teams. Each project team can upload their documents onto the site and then share the contents. This has been used with students. A research student has developed a Virtual Learning Environment together with XML Workflow Templates. This will act as a repository for student deliverables, but also impose a process on students and alert staff when deliverables have been uploaded (or not). We aim to use this with students this year.

7

Evaluation of SWM

Two formal evaluations of the use of SWM have been undertaken. A questionnaire was given to all students and a total of 47 replies were received. 85% of students felt that they mostly or completely understood the method. 77% of students felt that they mostly or completely understood what to do at each stage. Two cohorts of students of the Web Engineering module have been questioned closely on which parts of the method they found most and least useful. What emerged most strongly from these questionnaires, and talking informally to the students, was their relief at having a method (any method) to follow. 55% of students mentioned this on their questionnaire even though it wasn’t a direct question.

Page 4 of 6

SWMing at Teesside

University of Teesside

We tried to ascertain which Analysis techniques students would use again and which they thought were the most useful or important. Audience Analysis was the most popular, followed by Statement of Purpose. These two were cited as the most useful by 43% and 30% respectively. 95% of students said that they would use Audience Analysis again. The order of usefulness of the other techniques given by the students was Content Analysis, Market Analysis, Constraint Analysis, Accessibility Analysis and User Scenarios. The least popular technique, User Scenarios, would only be used by 54% of students on a future occasion.

jicc8-griffiths2.doc

Page 5 of 6

SWMing at Teesside

8

University of Teesside

Conclusion

In this paper we have traced the development of Internet-related degree routes at Teesside. We have considered different types of web site and proposed a simple framework that is useful in course development and teaching. The Web Engineering module has been described, concentrating on the case for web engineering and the methods and techniques available. We have described SWM: the method that we have developed and use with the students. We have outlined the web engineering tools that we have used and propose to use, and we have discussed student evaluation of SWM. We would urge others to incorporate some web engineering into their Internet courses if they have not already done so - particularly modules that concentrate on the early phases of the lifecycle: planning, analysis and design. It is an important topic for industry, a thriving research area and the students welcome the structure that it brings to their web developments.

9

References

1

Murugesan, Deshpande, Hansen and Ginige, Web Engineering: A new discipline for development of web-based systems, First ICSE Workshop on Web Engineering, Los Angeles, May 1999.

2

BBC – http://news.bbc.co.uk

3

Amazon – http://www.amazon.com

4

Conallen, J, Building Web Applications with UML, Addison Wesley, 2000

5

Nielsen - http://www.useit.com/

6

Ginige, Web Engineering: Managing the Complexity of Web Systems Development, Proceedings of SEKE 2002, Italy, ACM Press, July 2002.

7

McDonald A and Welland R, Web Engineering in Practice, Proceedings of the Fourth WWW10 Workshop on Web Engineering, Page(s): 21-30, 1 May 2001.

8

Lowe, D. and Hall, W., Hypermedia and the Web, Wiley, 1999.

9

December- http://www.december.com/web/develop/

jicc8-griffiths2.doc

10

IBM Web Design guidelines - http://www3.ibm.com/ibm/easy/eou_ext.nsf/Publish/572

11

DiNucci, D., Elements of Web Design, Peachpit, 1998

12

Powell, T.A., Web Site Engineering, Prentice Hall, 1998

13

Isakowitz, T.; Stohr, E.; Balasubramaniam, P. RMM, A Methodology for Structured Hypermedia Design, Communications of the ACM, New York, v.38, n.8, p.34-44, Aug. 1995.

14 Ceri, Fraternali and Bongio, Web Modelling Language (WebML): a modelling language for designing web sites, WWW9 conference proceedings 15

Lilly, S. ‘Planned Obsolescence’ Magazine Vol.3 No.5 p79-80 1994

16

Forrester Research, ‘Pumping Ebusiness Talent’, November 2000

Up

17

Andersen Consulting, Creation’, June 2000

Enabled

18

eSkills, Consultation Paper, February 2001

19

NCC, ‘Salaries and Staff Issues in IT 2001’, December 2000

20

Barry and Lang, A Survey of Multimedia and Web Development Techniques and Methodology Usage, IEEE Multimedia, April-June, 2001

21

Yourdon, E, Modern Structured Analysis, Prentice Hall, 1989.

22

Ashworth and Slater, An Introduction to SSADM Version 4, McGraw Hill, 1993.

23

Rational Inc., The Rational Unified Process, 2001

24

Griffiths, Hebbron, Lockyer and Oates, A Simple Method and Tool for Web Engineering, Web Engineering Workshop, SEKE 02, Ischia, Italy, July 2002, ACM Press

‘Internet

in

Object

Internal

Job

Page 6 of 6

Personal Background The Evolution of Java Robert Stroud School of Computing Science University of Newcastle upon Tyne

• Long-standing interest in object-oriented programming languages (>20 years) • Relevant teaching experience (>10 years): – – – –

Algorithms and Data Structures (in C++) Concurrent Programming (in Java) Internet Technologies (in Java) Advanced Programming (in Java)

• Previous JICC tutorials and talks:

[email protected]

– Java vs. C++ as introductory programming languages – Introduction to the Java Collections framework – Experience using Java to teach internet technologies

JICC 8, London, January 26th 2004

Introduction • Java = Language + Library (+ Tools + Platform?) • The Java Language has been relatively stable since JDK 1.1, but big changes are planned for JDK 1.5 • In contrast, the Java Library has just grown and grown… • My aim is to review recent and forthcoming changes to both the Java language and its libraries • Unfortunately, there won’t be time to say much about changes to the libraries! • Most of my JDK 1.5 examples are based on material available from Sun’s web site

Coverage • • • •

Necessarily very selective… All JDK 1.4 and 1.5 language changes A few library features Things that I think are interesting from a teaching perspective • Mainly J2SE but also a bit about J2EE if there’s time… • Lots of slides for the handout, far too many for a 45 minute talk!

1

Ancient history • Java changed rapidly in its first few years: – JDK 1.0 - original version of Java – JDK 1.1 - added inner classes, new AWT event handling model, character I/O rather than byte I/O – JDK 1.2 - added Swing, Java collections framework

• JDK 1.2 became J2SE (Java 2 Standard Edition) • Sun also developed J2EE (Enterprise Edition) and J2ME (Micro Edition)

Past, Present, Future • JDK 1.3 – Mainly a maintenance release – APIs for CORBA, dynamic proxies, StrictMath

• JDK 1.4 – Added assertions, chained exceptions – APIs for New I/O, Regular Expressions, Logging, XML Processing, Preferences – Java Web Start

• JDK 1.5 – Lots of interesting language changes – API for concurrent programming

Java Community Process • Since 1995, the evolution of Java has been controlled by the Java Community Process (JCP) • Proposals for changes are submitted as Java Specification Requests (JSRs) • Expert groups are appointed to consider each JSR, draft specifications are published and voted upon • Public participation is encouraged - individuals can comment on public drafts • For more information, visit: http://www.jcp.org

Some relevant JSRs • • • • • • • •

JSR14 - Add generic types to Java JSR41 - A simple assertion facility JSR51 - New I/O APIs for the Java Platform JSR65 - Concise object array literals JSR166 - Concurrency utilities JSR175 - A metadata facility for Java JSR181 - Web services metadata for Java JSR201 - Extending Java with Enumerations, Autoboxing, Enhanced for loops, and Static Import

2

What should we be teaching? • Modern Java, i.e. J2SE (aka JDK 1.2), not JDK 1.1 (or even JDK 1.0) – Swing, not AWT! – Java Collections, not Vector and Hashtable – Readers and Writers, not just Streams – Nested/Inner/Anonymous classes?

• But is there anything in JDK 1.4 or JDK 1.5 we need to be thinking about teaching? • Answer - most definitely!

Java assertions vs assert in C • C (and hence C++) has had an assert macro since the dawn of time - so what’s different about assertions in Java? • Java assertions can be selectively enabled or disabled on a class or package basis at run-time • They don’t need to be compiled into a special debugging version of the code • The C assert macro generates an error message containing the source code and line number • The Java assert statement throws an exception containing a stack trace and optional failure value

JDK 1.4 language features • JDK 1.4 introduced an assert keyword: assert bool-expression

• If an assertion fails at run-time, an AssertionError exception is thrown • Additional information can be provided about the assertion failure: assert bool-expression : expression

• The second expression could be an explanatory message, or the value that caused the failure • Assertions are a new language feature, so the compiler doesn’t recognise them by default

Using assertions • The JDK 1.4 documentation contains a surprisingly lengthy discussion of assertions: http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

• Assertions can be used to check internal invariants, class invariants and post-conditions • However, their use for checking pre-conditions of public methods is discouraged… • … because the pre-condition normally forms part of the API documentation • Here are some examples taken from the JDK 1.4 documentation…

3

Example checking pre-condition /** * Sets the refresh rate. * * @param rate refresh rate, in frames per second. * @throws IllegalArgumentException if rate MAX_REFRESH_RATE. */ public void setRefreshRate(int rate) { // Enforce specified precondition in public method if (rate MAX_REFRESH_RATE) { throw new IllegalArgumentException("Illegal rate: " + rate); } setRefreshInterval(1000/rate); }

Example - checking internal invariant if (i % 3 == 0) { ... } else if (i % 3 == 1) { ... } else // At this point, we know that (i % 3 == 2) { assert i % 3 == 2 : i; ... } // Question - can this assertion ever fail?

Example - using an assertion /** * Sets the refresh interval (which must correspond to a legal frame rate). * * @param */

interval refresh interval in milliseconds.

private void setRefreshInterval(int interval) { // Confirm adherence to precondition in nonpublic method assert interval > 0 && interval