General Requirements 73

The basic requirements of IWE are:

1. The environment should produce interactive worked examples, which must be usable by students. The students’ user interface should be user- friendly with straightforward operations and should also keep students’ attention on learning.

2. The environment should allow teachers to set up their own worked examples using an authoring approach and the internal relationship of

these worked examples should be revealed in a visible way. For example, a teacher has an answer to a problem that needs to be explained in their mind (it can be thought of as a big picture); it should allow the teacher to author the process of solving the problem, visualizing the whole thinking process.

3. Students are able to interact with these worked examples on demand and should be able use the worked examples to meet their individual learning purpose. For example, trying to learn some new concepts or understand concepts more deeply.

4. Teachers should obtain students’ feedback about worked examples that they set up in order to improve their teaching and worked example design. 5. The environment should support modification of worked examples. These

modifications are possibly based on the feedback from students, embedded question answers and data from log files.

4.1.1 The Overall Structure of IWE

Figure 4.1 shows the main components of IWE, how IWE structures them to present worked examples and how teachers and students can access them. There are two distinct types of user, teachers and students, and therefore two separate user interfaces to the system are required. The teacher interface must support the creation and modification of interactive worked examples, in the teacher’s mind, from a textbook or from a teacher’s handout, or past

examination questions. The teacher needs to be able to define the documents used for representing the worked example and define the process, including explanations, which will display the interactive worked example to the student. The student interface must support the exploration of interactive worked

Process(Generate All Views Step by Step) Teacher Interface Students Interface Explanation View Document 1 Document 2

System

Document 1 View Document 2 View

顶层包::Student

顶层包::Lecturer

Teacher

Students

Figure 4.1 Multiple Coordinated Views Structure to Represent Worked Examples Using IWE

For example, a teacher would like to create a worked example to demonstrate how an ER diagram can be generated from the requirement description. The Document 1 View can be used to represent the requirement description

document, and the Document 2 View can be used to represent the ER diagram document. Explanations will be edited during the creation of process step by step, and then be shown in the Explanation View. IWE can support more than 2 document views, but to keep the structure diagram in Figure 4.1 simple only 2 document views are shown. For example, if the teacher would like to further demonstrate how related SQL commands can be written to extend the previous example, the SQL commands document can be shown in a Document 3 View.

If faded work examples are being used, then the teacher interface must allow the teacher to insert questions into a process and the student interface must provide a mechanism for the student to answer these questions and store the students’ answers. These answers can be provided as feedback to the teacher.

Additionally, a feedback mechanism is required to allow students to send

questions or comments asynchronously to the teacher via the system. Collected feedback from the students is returned to the teacher, allowing them to modify interactive worked examples, for example, to correct errors, extend worked examples or improve explanations, if necessary.

4.1.2 Basic Concepts of IWE

Some basic concepts need to be defined before considering detailed

requirements. As mentioned before, the worked examples produced by IWE focus on transformation between representations and showing the relationship between representations. Hence, IWE must support the definition of documents that are either graphical or textual, as representations. In order to highlight the relationships between different parts of representations, the documents must be constructed of small pieces, called fragments, which can be graphical or textual. They are the fundamental components of a document. Hence, a document is built from a collection of fragments, for example, a collection of graphical fragments becomes a graphical document and a collection of textual fragments becomes a textual document. A graphical fragment could be a shape or a line with its unique attributes, like size, colour and so on. For example, Figure 4.2 shows three different graphical fragments. Fragment 1 and Fragment 2 are of the same type: they have the same attributes, but with different labels. Fragment 3 is a different type of fragment with different attributes and label compared to fragment 1 and fragment 2.

Figure 4.2 Graphical Fragments for Building Graphical Documents

In order to define a fragment, these attributes need to be encoded. Fragment type is defined to manage the attributes of a fragment. A fragment could be a graphical or textual, so the fragment type is either a graphical fragment type or a textual fragment type. Because a document consists of many fragments which may depend on different fragment types, a document type can be understood to manage a collection of fragment types which are used to describe a document.

In order to show transformations and allow the linkage of contents between representations to be highlighted automatically during the interaction, different documents and individual fragment relationships between documents need to be managed. An application is defined as a combination of different documents within a multiple coordinated views structure. A process is defined as presenting a sequence of related fragments from different documents with associated explanations in order to show a worked example interactively. A document can be used in more than one process within an application. A worked example is one process within an application. There should also be a mechanism that allows related fragments from different documents to be highlighted to show

correspondence. Correspondences should be highlighted automatically if an individual fragment of a correspondence is triggered by selecting it. Taking the previous requirement to ER diagram as an example, a correspondence can be between a noun in the requirement document and an entity (labelled rectangle) or an attribute (labelled oval), related to this noun in the ER document.

A student should be able to explore the worked example and interact with the documents in several ways, either by stepping through processes, which consist of a series of steps to display parts of the documents, or by interacting with the fragments of documents and observing relationships to other documents.

4.1.3 The IWE Data Model

Figure 4.3 shows the data model of IWE. It is organized into three layers: the Document Types, Documents and Applications layers. The Document Types layer is the fundamental layer of the whole model; it describes the types of fragment, either graphical or textual. The Documents layer is the core data layer of the whole model; it defines either graphical documents or textual documents, which contain a set of fragments based on the description of fragment types in the document types. The application layer of the model allows documents to be allocated into a predefined multiple-panel structure and stores the

representation of processes. A process involves: describing the sequence for presenting different fragments of documents in different panels; defining the relationships between different fragments in different documents; and adding the teacher’s explanations for each step in the process.

Applications

Document Types Documents

Document

Graphical Document Textual Document

Graphical Document Type Contains a set of Graphical

Fragment

Textual Document Type Contains a set of textual

Fragments Process

Graphical Fragment Textual Fragment

Associated with Dependent on One or More

occurrences

Note:

Figure 4.3 Data Model of IWE

Figure 4.3 defines the data model for building a worked example and supports the core function of IWE, presenting interactive worked examples to students. Student details, their feedback, answers to embedded questions and log files are stored in the system. This data is associated with a worked example, but not directly related to how the worked example is built and presented. Storage requirements for this data are defined in 4.4.1 System Requirements and 4.4.2. Log Requirements.