These UML (Unified Modelling Language) diagrams are provided to help developers gain an understanding of the architecture and stucture of FLE3. Each diagrams is shown in PNG format and is available in unshrunk PNG and in vector WMF. All images were created using Together/C++ modelling software. For these purposes we generated C++ class headers from the Python sources, which Together/C++ uses as its modelling repository.
FLE3 has three global roles and three course specific roles. Each user has one global role and in any course that he/she participates in, one of the course specific roles.
User is the role for normal users of FLE. They cannot do much else besides log in and access their own Webtop. Of course, if they're participants in any courses, they can access that course and do anything that their course specific role allows them to do.
Staff is the role for employees or otherwise trusted users of the FLE system. Staff has the right to invite new users, change users' information (except FLEAdmins), create and remove courses and assign users to different courses. Staff can also promote other users to Staff status or demote them to User status. Staff also has all the rights that a normal User has.
FLEAdmin is the super user of the FLE system and has access to all system administration capabilities in addition to all the rights Staff has. FLEAdmin can promote other users to FLEAdmin status or demote FLEAdmins to Staff or User status.
Student is a normal participant in a course and can participate in knowledge building.
Tutor has all the rights a Student has, and can in addition create new course contexts and manage those contexts.
Teacher has complete control over a course. Teacher can select users to participate in the course and select each user's course specific role. He can also administer all the contexts of the course.
Normally Students in a course are normal Users and Teachers are Staff, but nothing is stopping a member of staff from creating a course and giving a normal user the Teacher rights to that course. Conversely members of Staff can be Students in some courses.
All FLE3 users have their own Webtop for storing information. Webtops are public, which means that all FLE3 users can view each others' Webtops and access all the information stored there. But only the owner of the Webtop (and FLEAdmin) can change the contents of the Webtop.
Webtops contain different items which can be grouped in folders. The owner can upload any binary files into the Webtop. He can also create links to anywhere in the Internet, or make shortcuts to interesting notes in knowledge building. He can also write down notes into memos. All these items are accessible to other FLE users.
The Webtops have clipboard functionality, which can be used to cut or copy files, links, folders and memos and to paste them somewhere else. They also have trash cans, which store all deleted files, so they can be recovered if the need arises.
Knowledge Building (KB) is a discussion tool designed specifically for collaborative learning and knowledge building. Each course contains one or more course contexts, each of which contains several discussion threads. Normal Students can participate in KB: they can read the notes, they can reply to them and they can start new threads.
Tutors can create new contexts and manage those contexts which they have created. Teachers can also create new contexts and manage all contexts within the course, as well as manage the users participating in the course.
Each course context has a knowledge type set associated with it. A knowledge type set is a set of knowledge types, which are used in the discussion. Each note in the discussion always has one knowledge type associated to it. FLE3 comes with several predefined sets, but new ones can be easily created. For example, the knowledge type set for Progressive Inquiry contains the following types:
Normal users can only edit their own information. Other user management functions are restricted to members of Staff. Managers (Staff or FLEAdmin) can list the users in the system, create new user accounts, send invitation emails to new users, freeze users (so they cannot login) and change the global role each user belongs to. Removing users is not possible currently, since that would remove the author information from knowledge building notes.
Course management is restricted to Staff only. Normal users can only open (access/view) the courses they participate in, but will not be shown the management interface at any time.
Staff can view the list of all courses, create new courses, select the participants (and their course specific roles) of the course, and also remove a course.
Course management also consists of knowledge type management. Staff can view the sets, create new sets (either from scratch or by cloning an existing set) and remove the sets. When a new set is created, it is in unfinished state and is only visible to the creator who can continue editing the set during a longer period of time. In the end he can either remove the set or finish it, whereby it will become uneditable, visible to all staff and can be taken into use in new course contexts.
This diagram is quite large, but shows quite a large portion of the FLE object structure in action. The topmost object is the FLE root object, which contains all the information in FLE. In this diagram it contains two objects:
The UserManager "fle_users" is on the left side of the diagram and contains three users (straight below it). The CourseManager "courses" is in the middle and contains the course "Finnish History" and another "courseB". Both courses contain a similar structure, but we'll concentrate on the first course.
The course "Finnish History" contains two course contexts: "Origin of Culture" and "contextB". Again, both will have similar contents, but only one is shown here. The "Origin of Culture" course context contains one ThinkingTypeSet (different term for Knowledge Type Set), called "progressive inquiry".
The "progressive inquiry" set contains six thinking types, which are the same ones that were listed above, in relation to knowledge building use cases.
The main attraction in this diagram are the three notes in the middle. The note "Question of Settlement" is the starting note for its thread (since it's directly inside the course context), is written by Ilkka and has the knowledge type "problem". It has two replies, one written by Teemu and another written by Samu. Teemu's reply contains a scientific explanation, while Samu's note contains his own working theory on the subject. Notice that the associations (not aggregations, which denote containment) specify the author and the knowledge type of the note.
This class diagram shows the structure of knowledge building. Each Course can contain any number of CourseContexts. Each CourseContext is associated with one ThinkingTypeSet, which in turn contains the ThinkingTypes that may be used in the discussions inside that CourseContext.
The CourseContext may contain any number of Notes, each of which represents the starting note for a new thread of discussion. Each Note is associated with one ThinkingType (for the type of the note) and one UserInfo (for the author of the note). Each Note can contain any number of new Notes, which are replies to that note.
This diagram shows the inheritance tree for knowledge building. The application domain classes are in the middle: Course, CourseContext, Note and also ThinkingTypeSet, ThinkingType and UserInfo. The top row contains abstract superclasses from which different properties are inherited to the domain classes. The Cruft class is moved to the bottom, since pretty much every class inherits from it. Cruft contains older, unclean methods, that are being phased out of the system.
Thread contains functionality needed for a discussion thread, so it's inherited into Course, CourseContext and Note.
NoteDTML contains UI related functionality that is needed to access the notes contained within an object. Since notes can appear inside notes and contexts, both Note and CourseContext inherit these properties.
Traversable is a utility class containing methods that facilitate access to Zope acquisition.
TempObjectManager is a class that provides functionality to create temporary objects, make them permanent and remove them. When new notes are written and have not yet been published, they are held in temporary storage so other users don't see them prematurely.
EventManager can respond to different events. Currently it responds to the "read" event, which happens when a user reads a note. It's used to keep track of who's read what and when.
This diagram shows the objects that are involved in a user's Webtop. The topmost object is the UserInfo object, which is the user's account. It contains one Webtop object, which represents the top folder of the webtop.
In this diagram, the webtop contains one Link ("myLink"), one File ("myFile"), one Memo ("myMemo"), one Folder ("subfolder") and "otherItems". The subfolder in turn contains "moreFiles".
The complex part of this diagram is the trash can functionality. Each folder (including the top folder) contains a hidden folder "temp_objects", which contains all items that have been removed from the folder. In this diagram, the temporary folder of "subfolder" contains two removed items and the temporary folder of the webtop contains one removed item.
The Webtop object contains also one instance of WebtopTrash, which is the trash can that the user can see. It doesn't really contain any objects, but rather builds its list of removed items by descending down the webtop folder structure and checking inside each folder's temporary storage. This way we have one list of removed files, so the user doesn't need to remember in which folder the files were removed from, and we can easily undelete the files when requested.
Starting from the lower left corner, UserInfo always contains exactly one Webtop. Webtop, in turn, contains one WebtopTrash. Webtop is also a subclass of WebtopFolder, so it functions in all other respects like a normal folder.
A WebtopFolder contains any number of WebtopItems, which in turn can be WebtopFiles, WebtopMemos, WebtopLinks or other WebtopFolders. Each WebtopFolder is also a subclass of TempObjectManager, meaning that they have one TWFolder for temporary object storage. In Webtop, this temporary storage is used for trashed items. The WebtopTrash inside Webtop recurses through the webtop folder structure and builds its list of removed items by looking at each TWFolder in turn. The TWFolders can contain any number of WebtopItems, which are removed from the containing WebtopFolder.
This diagram shows the inheritance tree for Webtop classes.
Traversable is used just like in knowledge building - for facilitating access to Zope's acquisition. It's inherited into TWFolder, WebtopTrash and WebtopItem.
WebtopItem is the abstract superclass that all objects stored in webtops inherit. These objects consist of WebtopFile, WebtopMemo, WebtopLink and WebtopFolder.
Cruft contains old methods being phased out of the system. It's inherited to whichever classes still need those functions.
TempObjectManager is inherited into WebtopFolder. All removed items are stored in the temporary storage (an instance of TWFolder).
Webtop is a subclass of WebtopFolder, meaning it has all the functionality of normal webtop folders in addition to its special features (like the WebtopTrash instance).
This diagram shows the class hierarchy of FLE Knowledge Building on the left and the type containment hierarchy of EML documents (Educational Modelling Language, an XML application, for more information, visit The Open University of the Netherlands), and the dependency graphs showing what element types each class corresponds to.
This diagram shows the same object instance example as the Knowledge Building object structure diagram shown before on this page. In this diagram, each object is shown as an EML document element type. The aggregation links show the containment of elements inside other elements. The association links depict id-refs to other elements by their unique identifiers. This example depicts the content portion of an EML unit-of-study, leaving other portions (like environment) out.
For more information, consult the source code. These diagrams should give you the overview you need to orient yourself to the code. It also helps to get acquainted with Zope and it's design philosophy.
For questions or other requests concerning the UML diagrams of FLE3, please contact Tarmo Toikkanen (home page).