Architecture for an Online Learning System

Utrecht University

Vincent Vonk
Michel Wasmann
Diana Sidharta

January 14, 2008

Contents
1. Introduction ......................................................................................................................................................... 3
2. Stakeholders and Concerns ................................................................................................................................. 3
2.1 Stakeholders ................................................................................................................................................. 3
2.2 Concerns ....................................................................................................................................................... 5
3. Requirements ...................................................................................................................................................... 5
3.1 Functional Requirements .............................................................................................................................. 5
3.2 Non-functional Requirements ...................................................................................................................... 7
3.3 Constraints.................................................................................................................................................... 8
4. Architectural Description Framework ................................................................................................................. 8
5. Logical View ..................................................................................................................................................... 10
5.1 Rationale .................................................................................................................................................... 10
5.2 View Of The System .................................................................................................................................. 10
6. Process View ..................................................................................................................................................... 13
6.1 Rationale .................................................................................................................................................... 13
6.2 Component Process Sequence .................................................................................................................... 13
7. Physical View ................................................................................................................................................... 19
7.1 Rationale .................................................................................................................................................... 19
7.2 Layered System Structure .......................................................................................................................... 20
8. Development View ........................................................................................................................................... 21
8.1 Rationale .................................................................................................................................................... 21
8.2 The Different Interfaces ............................................................................................................................. 22
9. Scenario View ................................................................................................................................................... 23
9.1 Use Case: Browse...................................................................................................................................... 23
9.2 Use Case: Editing ....................................................................................................................................... 24
9.3 Use Case: Analysis ..................................................................................................................................... 24
9.4 Use Case: Documenting ............................................................................................................................. 25
9.5 Use Case: Bug tracking .............................................................................................................................. 25
9.6 Use Case: Feature Request ......................................................................................................................... 25
9.7 Use Case: Meeting ..................................................................................................................................... 26
9.8 Use Case: Export ........................................................................................................................................ 26
10. Rational Architectural Description Specification View .................................................................................. 27
10.1 Rationale .................................................................................................................................................. 28
10.2 Hardware .................................................................................................................................................. 28
11. Implementation Proof...................................................................................................................................... 29
12. Realization Proposition ................................................................................................................................... 30
12.1 Costs ......................................................................................................................................................... 30
13. Conclusion ...................................................................................................................................................... 31
14. Contribution Of Team Members ..................................................................................................................... 32
15. Reference List ................................................................................................................................................. 33

1. Introduction
Online learning environments are used as supplement for teaching and learning, with the goal
to enhance this whole process. Users are able to create, change, delete, update and share
information. These actions are supported by tools which are implemented within the system.
Examples of well known e-learning environments are Blackboard and the Sakai Project.

This document will elaborate more on a distributed collaboration environment for large
programming projects. An online learning environment consists of complex pieces of
software. Therefore the development of well structured software architecture is crucial for an
adequate and successful implementation. This document will describe the software
architecture of the online learning system (hereinafter OLS). This document will provide a
description of the architecture, rationale for decisions, and an estimate for the development
effort required.

2. Stakeholders and Concerns

In this part all the stakeholders will be listed, which are involved in the development and
usage of the OLS system. A stakeholder represents one or more users or groups of users who
have certain interest / concerns about the system. Each stakeholder will be addressed in the
following part of this document and their concerns will be stated.

2.1 Stakeholders
Stakeholders are representatives from all stages of development, usage and support. They play
an important role in order to make a good architecture because each stakeholder has a certain
concern, which is supported by the system.

As described earlier, the focus is on an OLS. This is a collaboration environment for large
programming projects and consists of software tools to help programmers, code reviewers,
designers, managers and researchers to develop and maintain a program. Each group of users
can be defined as a stakeholder.

Each of the stakeholders has a certain concern, in terms of functionality, reliability, usability,
efficiency, maintainability and portability QUINT/ISO 9126 [Dijkstra, 2008]. The following
Table 1 resembles the concerns of the stakeholders in terms of these criterias.

Criteria Concern Stakeholder

Functionality Code documentation, and other Programmers
artefacts required for building the Code reviewers
program are organized as a Designers
collection of text fragments (or Managers
chunks) and normal files. Researchers
Analyze artefacts for properties. Programmers
Code reviewers

Allowing inspection of all artefacts Code reviewers

of the project, exploiting the Managers
meaning of all formalisms used to Researchers
encode sources.
Artefacts must be easily requested. Programmers

Reliability A distributed environment which Programmers

allows contributors to the project to Code reviewers
participate independently of Designers
physical location. Managers
Researchers
System needs to be fault tolerance. Programmers
Code reviewers
Designers
Managers
Researchers

Usability A function to export files. Programmers

Maintainability Users are allowed to enter Programmers

problems with the programs of the Code reviewers
project. Designers
Managers
Researchers
Artefacts must be documented. Programmers
Code reviewers
Managers
Researchers
Modification of any artefact of the Programmers
project, again exploiting the type of
those artefacts.
Addressing additional functionality Managers
to the program.

Portability Support the resolution of project Programmers

related problems. Code reviewers
Designers
Managers
Researchers

Table 1: Stakeholders Concerns

The above Concerns are derived from the project documentation. It is remarkable that none of
the stakeholders have a concern regarding the criteria Efficiency. Even though this criteria is
not mentioned it does not mean that this does not have to be taken into account.

2.2 Concerns
In the previous paragraph the concerns were divided into the quality criteria regarding the
OLS. The concerns of the users need to be taken into account in order to create a supporting
system. That is why the concerns need to be translated into requirements for the system.

The concerns which exist regarding the system are shown in the following Table 2, which are
derived from the project description.

Nr. Description
1. A distributed environment which allows contributors to the project to participate
independently of physical location.
2. Code documentation, and other artefacts required for building the program are
organized as a collection of text fragments (or chunks) and normal files.
3. Allowing inspection of all artefacts of the project, exploiting the meaning of all
formalisms used to encode sources.
4. Modification of any artefact of the project, again exploiting the type of those
artefacts.
5. Analyze artefacts for properties.
6. Artefacts must be documented and easily be requested.
7. Users are allowed to enter problems with the programs of the project.
8. Addressing additional functionality to the program.
9. Support the resolution of project related problems.
10. Export files.
Table 2: System Concerns

3. Requirements
In this chapter we will list all the requirements that the system will feature, including the
functional, non-functional, and constraints.

3.1 Functional Requirements

The functional requirements of the system describe the features the system should have.
These requirements are derived from the concerns which are described in the previous
chapter. The requirements are related to certain tools within the system which need to be
supported by the final system.

The OLS consists of different tools, which can be divided into five specified tools:
Coding Tools;
o Code Browsing Tool
o Code Editing Tool
o Code Analysis Tool
o Code Documenting Tool
Bug Tracking Tool;
Feature Request Tool;
Meeting Tool;
Export Tool.

As shown in the list above, coding tools consists of four other tools. These tools are related to
the concerns of certain stakeholders and therefore need certain requirements.
The requirements related to the concerns are resembled in Table 3, whereas the full
requirements document can be found in [Dijkstra, 2008]:

Nr. Description
1.1. The users of the environment can be identified and have different access
rights to different tools.

2.1. Each chunk resides in a normal file, tagged with a variant number, an optional
name and a type.
2.2. Files themselves are also typed, e.g. based on the suffix of their name.
2.3. Types are used throughout the system to tailor functionality of system
components.
2.4. Variant numbers are used to distinguish program variants.

3.1. Files can be inspected for their raw content and their location in the SVN
repository
3.2. Chunks can be inspected for their raw or pretty printed content, the latter
according to its type. Location as well as remaining tagged information can
be inspected as well.
3.3. The hierarchy imposed by the explicit inclusion of other chunks can be
inspected as if it were a file system.
3.4. Files can also be inspected in a type driven way: its rendering is dependent on
its type.

4.1. Code editing may be partially or fully integrated with code browsing.
4.2. Name completion: suggest the completion of partially typed keywords and
identifiers based upon the available definitions.
4.3. Language construct completion: suggest the completion of partially typed
language constructs.
4.4. Check for syntax while typing.
4.5. Allow developers to work in the classical checkout + modify + commit
cycle.

5.1. Simple properties of the type of an artefact have number of lines or

number of words.
5.2. A simple property taking into account the type of an artefact partitions such
properties into comment and code.
5.3. Complex properties like this identifier is referred to by are allowed.
5.4. Users must be able to add new analyses.
5.5. System must indicate the expected time an operation takes.

6.1. All artefacts must be explained

6.2. Explanation may be for a single artefact
6.3. Explanation may be for a group of artefacts
6.4. Explanation may be for independent of artefacts.
6.5. Explanation can be browsed in different ways, the default being per artefact.

6.6. Explanation can also be browsed as specified by a user, e.g. a tutorial, a

paper, or a thesis.

7.1. The process of solving a problem is tracked.

7.2. The connection to required modifications: design documents, additional
documentation, chunks/files, etc is tracked.

8.1. Enter problems and address additional functionality

8.2. Track use of documents.
8.3. Track and allow connections between artefacts.
8.4. The system can be extended with new types requirements, by the user.

9.1. Offering a blackboard mechanism.

9.2. Support communication by means of audio/video/documents.
9.3. Make use of the bug tracking and feature request tools.

10.1. Source code distribution.

10.2. PDF documentation.
10.3. Describe how to construct the exported material.

Table 3: Functional Requirements

3.2 Non-functional Requirements

Non-functional requirements are not included in the features of the system, but can be seen as
the behavior which the system should have. Also the concerns of the stakeholders are related
to the non-functional requirements of the system.

We identify the following non-functional requirements in Table 4:

Type Description
Maintainability/ The system must either guarantee consistency between the various copies
Managebility of artefacts.
Portability/ The system must be platform independent, but also Platform dependent
conformance available.
Efficiency/ All data is available as a database based repository, for fast access by
Time behaviour analysis tools.
Efficiency / The system must be responsive for common editing activities. Less
Resource frequently used functionality may take more time.
behaviour
Table 4: Non-functional Requirements

3.3 Constraints
Constraints are requirements, which are beyond discussion. These requirements should be
guaranteed at the final release of the system. Some stakeholders have mentioned these in their
concerns and are depicted in Table 5.

Type Description
Reliability/ The system should make use of a SVN repository, as well as a database
Availability based repository.
Reliability/ The system must guarantee consistency, it must indicate possible
Availability inconsistency and indicate how long it takes until consistency can be
guaranteed, possibly offering the user a way to help by making necessary
choices between inconsistent parts.
Reliability/ The data needs to be redundant.
Fault tolerance
Table 5: Constraints

4. Architectural Description Framework

The architecture will be structured according to ANSI/IEEE 1471-2000, Recommended
Practice for Architecture Description of Software-Intensive Systems Framework. IEEE 1471
standardizes Conventions on Architectural Descriptions (ADs). IEEE 1471 standardizes a
basic framework for the content of an architectural description as depicted in figure 1, in
particular giving specific meaning to views and viewpoints. [APG, 2006]

The important definitions from this standard are as follows:

Architectural Description A set of views and additional architectural information.

Stakeholder An individual, group or organization that has at least one concern relating to the
system.
Concern A functional or non-functional requirement.
View A set of models representing a system from the perspective of a related set of concerns.
Viewpoint A viewpoint is a specification where relevant elements are described. An
architectural description exists of views, which are described in the next chapter. These views
conform to certain viewpoints.
Model A particular diagram or description constructed following the method defined in a
viewpoint.

Figure 1: IEEE 1471 Framework

In order to create the AD, the different views of the Kruchten 4+1 view model has been used.
[Kruchten, 1995]. And this description makes use of the new UML 2 notation. [Albin, 2003]

Figure 2: The Kruchten 4+1 Model

5. Logical View
This logical view primarily supports the functional requirements that were drawn earlier in
this document. They define the services that the system should provide to the users. The
system is decomposed into a set of key abstractions, taken mainly from the problem
document. These abstractions are objects or object classes that exploit the principles of
abstraction, encapsulation, and inheritance.

5.1 Rationale
All functionality in the OLS is split up into different packages. The Tools packages provide
the functionality as described in chapter 3. Splitting all the end-user functionality into
different classes is done to make a clear logical separation between different functions in the
OLS, and to avoid implementing redundant functionalities. In the most situations, a basic
system is installed which can be extended. A bottleneck in this situation is that the system will
be more complicated and unpredictable, which results into difficult maintenance of the
systems functionality.

Some basic functionality, e.g. storage, is also provided in a package to make sure all tools can
use the same storing and perform input and output tasks in a uniform way so that data can be
reused by multiple tools while using the same storage procedures on that data. This is to be
preferred over all tools implementing this functionality by itself, which may lead to severe
data overhead and consistency conflicts.

5.2 View Of The System

The Class diagram depicted in figure 3 shows the OLS classes and their attributes, methods,
and associations to other classes in the system that come with the required OLS
functionalities. The class diagram in Figure 2 shows an use case of an online learning system
(or part of one). The OLS have from one to several users. And the OLS has one to several
repositories / databases. The Repository has zero to several source files stored in the database.
In order to improve the readability, the links of all non essential packages (security module,
login module and the track ability of steps a user undertakes) to the OLS and repository have
been omitted.

Figure 3: Class Diagram - Classes of the OLS

10

Online Learning System is the class responsible for the main structure of the program and
associates with other classes. The class contains UserID, Tools, Repository and Database

- UserID has a aggregation with the class Users. This ID is needed to login to the OLS.
The ID function is used for session tracing later on.

- Tools has a realization with the class Tools. The tools are together the main core
functions of the OLS.

- Repository has a aggregation with the class Repository and Database. In the main
(SVN) repository function all the (source code) data is stored for further usages.

Database has a aggregation with the class Repository and Database. In the Database
is also project data stored, it is redundant with the Repository for requirement reasons
mentioned in the constraint section of this document.

User Is a class that contains the ID of the users of the OLS and also there username (password
is omitted in the class diagram, but should be present in the program for standard security
reasons). The User class is an instance contained class of the OLS.

ID is the login function the user can use to login on the system, with it he can use the
OLS for browsing, code editing and other tool functions.

Name is stored for information purposes only, its easier to see who for example edited
the code if there is a name with it, then when a number needs to be checked.

File is the class that is responsible for the file functions, the files and text files (chunks of
code) reside in the repository and database and is depicted in a class. Also in this class model
the security and the robustness (of the files) is omitted. The File class is a instance contained
class of Repository and Database.

Number, each file that resides in the repository has one for code analysis and ease of
code browsing. The file shuffle program needs a number and as suffix to generate
source code.

Name of the file is used for ease of use and for generation of source code by the code
analysis tool.

Type of file is important for the users and for exporting possibilities. Also the file
types can be added, edited and deleted.

11

Tools is the class that holds the main functions of the OLS, all the required tools are named in
this class. Tools is instance contained class of the OLS and has an association with the OLS
class and a link with the repository / database.

Code browsing is one of the core functionalities of the OLS. The users can browse the
code in the database / repository by means of the code browsing tool.

Code editing is used for the creation, editing and deletion of code. It can be added in
text format or in file format, individually or in groups.

Code documenting is a function for the documenting of code, there is a field for
chunks of code and for the individual file to add tags and meta information about the
selected code.

Code analysis is a tool function that automatically analysis the code for consistency
and then places the code back in numeric order in the repository. Its also possible to
manually add analysis in the system.

Bug fixing is a function for the adding and tracking of founded bugs in the source
code. A user can add source code and then keep track of the possible solutions and
fixing of the problem / bug.

Feature request is a function for the adding requests and suggestions for new
functionalities within the source code.

Meeting is a tool function that makes it possible to discuss a certain source code, bug
or feature request by providing blackboard, or video / audio meeting with different
users.

Export function is for the exporting of source code to other file formats, like text or
PDF.

Repository and Database is the class responsible for the storage and distribution function of
the files within the OLS. The Repository is an instance contained class of the OLS. And is a
Composition of the Files class.

Files, text files, and source code are stored in the database and in a SVN repository for
further searching and processing.

12

6. Process View
The process viewpoint is a viewpoint which represents the processing model of the system.
Process views capture the concurrency, synchronization, and distribution aspects of the
design.

The process view explains in what way logical objects interact in order to meet the required
system behaviors. It has several levels of abstraction to address different sets of concerns. In
this chapter three diagrams are explained. The first diagram shows a representation of the
Code browsing & Code editing process. The second diagram shows a representation of the
code documenting, code analysis and exporting processes. Finally, the last sequence diagram
shows how bug tracking, feature request and meeting processes work. And shows that several
components subsequently work together.

6.1 Rationale
The communication between the users web browser / application and the OLS tools is done
via HTTPS, because this protocol allows to encrypt security-sensitive information. This
protocol is also understood by all modern main stream browsers, so that the accessibility
constraint can be fulfilled. The communication between the OLS and the repository is done
via RMI because this is the standard protocol used for communication between JSPs and
EJBs. The same arguments apply for using SQL for the communication with the database as
well as for using XML for parts of the communication with the shuffle application. RMI is
used for the remaining communication because it can easily be used for the EJB as well as for
the Java program to be developed for the different tools.

6.2 Component Process Sequence

In order to see a total process view in detail there are several sequence diagrams depicted,
which are represented in Figure 4, 5 and 6. The first figure shows the processes taking place
when an user uses the Code browsing & Code editing tool. The user will browse or edit a
source code file, that is e.g. produced by the system itself or a previous session.

Figure 4 shows the following steps for the Code browsing feature:

1. The users web browser / client application contact the code browsing tool with a
request to browse the source code files.
2. Then the Code browsing tool does a request in the OLS for available source code
(with the possible given search parameters).
3. The OLS browses trough the code in the repository for the selected criteria and
collects it.
4. The Repository and Database gives back the (search) requested data with the type of
code that is selected to the OLS.
5. The OLS then fires the data back in the Code browsing tool.
6. The Code browsing tool gives the requested source code file list back in the required
format and data representation to the users browser or application.

13

Figure 4 shows the following steps for the Code editing feature:

1. The users web browser / client application contact the code editing tool with a request
to edit a file, group or files or upload a new file.
2. Then the Code editing tool submits the file to the OLS and check for consistency and
redundancy.
3. When parameters check out, the file is submitted to the repository and database by the
OLS.
4. When the new / changed data is stored, the repository or database submits the code to
the analysis tool for further analysis and extracting of chunks.
5. The Code analysis tool creates automatically chunks of code when new or changed
code is submitted to the tool.
6. The Code Analysis tool then stores the chunks of code in a systematical way in the
Repository and Database.
7. The OLS then indexes these chunks of code so the code browsing tool can operate
faster when browsing and searching.

Figure 4: Sequence Diagram Code browsing & Code editing

The second figure shows the processes taking place when an user wants to upload his manual
code analysis or uses the Code documenting & exporting tool. The user will analyze,
document and export a source code file, that is e.g. produced by the system itself or a previous
session.

14

Figure 5 shows the following steps for the manual Code analysis feature:

1. The users web browser / client application contact the OLS with a request to submit a
manual made analysis.
2. The OLS checks for consistency, correctness and reliability with the current analysis
already in the Repository and Database.
3. If this all checks out, the manual made analysis is stored in the Repository and
Database.

Figure 5 shows the following steps for the Code documenting feature:

1. The users web browser / client application contact the code documenting tool with a
request to post the changed / new document (meta source code) data.
2. Then the Code document tool submits the document changes to the OLS and check
for consistency and redundancy.
3. When parameters check out, the file is submitted to the repository and database by the
OLS.
4. When the new / changed document data is stored, the repository or database submits
the code to the analysis tool for further analysis of the changes.

Figure 5 shows the following steps for the exporting feature:

1. The users web browser / client application contact the exporting tool with a request to
export a certain file, or group of files.
2. Then the exporting tool requests the data from the Repository and Database.
3. The Repository and Database returns the requested data to the exporting tool.
4. The exporting tool gives back the data to the client in the requested format. (XML,
PDF, Plain text, etc.)

15

Figure 5: Sequence Diagram Code Analysis, Code documenting & Code exporting

The third figure shows the processes taking place when an user wants to report a bug and use
the back tracking tool. It also shows the processes when a user wants to request a new feature
and want to have a meeting. The user that will report a bug, request a feature or held a
meeting, are about files that are already produced by the system itself or a previous session.

Figure 6 shows the following steps for submitting a bug:

1. The users web browser / client application contacts the bug Tracking tool with a
request to post the user founded code bug.
2. The Bug Tracking tool checks with a word / code recognition algorithm in the
Repository and Database the bug tracking fields to see if the bug has already been
posted before (by another user).
3. The Repository and Database gives back the data to the Bug Tracking tool. (If the bug
is already present, bug is not added and user gets a messages back.)
4. If the bug has not been posted, the Bug Tracking tool posts the bug information in to
the Repository and Database.
5. The Repository and Database confirms the storage of the bug in the system to the Bug
Reporting Tool.
6. The Bug Reporting tool gives back a confirmation to the user and also gives back a
bug tracking ID. This makes it possible for the user to trace the bugs he submitted in
the browsing tool.

16

Figure 6 shows the following steps for the submitting a feature request:

1. The users web browser / client application contacts the Feature Request tool with the
message to post a feature request.
2. The Feature Request tool checks with a word pattern algorithm in the Repository and
Database the Feature Request fields to see if the Feature Request has already been
posted before (by another user).
3. The Repository and Database gives back the data to the Feature Request tool. (If the
feature request is already present, feature is not added and user gets a message back.)
4. If the Feature Request has not been posted, the Feature Request tool posts the Feature
Request information into the Repository and Database.
5. The Repository and Database confirms the storage of the bug in the system to the Bug
Reporting Tool.
6. The Feature Request tool gives back a confirmation to the user and also gives back a
feature tracking ID. This makes it possible for the user to trace the Features they
requested in the browsing tool.

Figure 6 shows the following steps for submitting a meeting request:

1. The users web browser / client application contacts the Meeting tool with the message
to start a blackboard session, or a meeting by camera, sound or other means. (Optional
they can also do this from the Bug Tracking tool and Feature Tracking tool when the
users want to have this data available for the meeting).
2. The Meeting Tool contacts the OLS for initiation of the meeting with other users.
(There is checked, if the other users are also present and online in the system, when
they want to do a audio or voice chat).

17

Figure 6: Sequence Diagram Bug tracking, Feature request & Meeting tool

18

7. Physical View
The physical view takes the non-functional requirements of a system into account such as:
system availability, reliability (fault-tolerance), performance (throughput), and scalability.
The software executes on a network of computers (the processing nodes). The various
elements identified in the logical, process, and development views - networks, processes,
tasks, and objects - must be mapped onto the various nodes. Several different physical
configurations will be used - some for development and testing, others for system deployment
at various sites or for different customers. The mapping of the software to the nodes must
therefore be highly flexible and have a minimal impact on the source code itself.

7.1 Rationale
For developing an application with these specific tools and in this form there are two main
large scale alternatives on the market. First there is Microsofts .NET platform which only
works dependently on Windows based systems, so this is not really an option, because the
platform needs to be platform independent and the only tool they have for platform
independent multimedia tools, Silverlight is not suited for basic functionalities of the
program.

The second alternative is the Sun Java Enterprise Edition framework (Java EE). This platform
is open source and have been proven to be a stable implementation for most widely used
operating systems. Java Enterprise Edition is a very complex framework which offers divers
functionalities, this may however cause difficulties during development.

But of the two options, Java Enterprise Edition seems to be the best solution, as it allows a lot
of basic functionality and it suitable for developing large applications, at last it is platform
independent.

For the Repository and Database a form of Database Abstraction Layer (DAL) (for the
abstract working of DAL, see figure 7) will be implemented for maintaining consistency
between the database and repository. This Objective Database Abstraction Layer (ODAL) is
a high-performance multi-purpose database manipulation framework that supports Java so it
can be used in combination with the selected platform.

19

Figure 7: Abstract working of a DAL

7.2 Layered System Structure

The system will be structured as a three layer pattern system as depicted in Figure 8. The
physical framework used for implementing the three layer architecture of the OLS will be
Java EE.

Presentation Layer
The presentation layer will consist of the client side software, a platform independent browser
is used and the platform dependent program can be used to interact with the system by means
of HTTPS over TCP/IP. Also external files (programming code, and other kind of files) can
be coupled to the browser or program.

Logic Layer
The logic layer will consists of packages on Java EE servers which will mainly fulfill the core
functional requirement. It contains the tools that are mentioned earlier. There is also a API
interface present, so programmers can interface there plug-ins directly to the business logic
modules on the servers.

Data Layer
The third real layer is the data layer which consists in this case of the DAL components
server, which interact with the MySQL database server and the SVN repository server.

20

Figure 8: Deployment Diagram The different layers of the OLS

8. Development View
The development view focuses on the organization of the actual software modules in the
software-development environment. The software is packaged in small chunks program
libraries or subsystems that can be developed by one or more developers. The subsystems are
organized hierarchical, each layer providing a narrow and well-defined interface to the layers
above it. The development view takes internal requirements related to ease of development,
software management, reuse or commonality, and constraints imposed by the toolset or the
programming language into account. The development view is represented by a component
diagram [Kruchten, 1995].

8.1 Rationale
The OLS is besides layer also modular based, it consists of many tool modules and data
storages related modules which are all interconnected. Modular developing the OLS is in
contrast to tightly-coupled code, in which every unit may interface directly with any other,
composed of smaller, separated chunks of code that are well isolated. Those chunks can then
be developed by separate teams with their own life cycles and their own schedules. The
results can then be assembled together by a separate development team. Which may lead to a
faster development cycle.

21

8.2 The Different Interfaces

The system has a web interface for the connection with the independent client browser. There
is also a program interface for connection with the locally (dependent) installed client
programs. These interface directly with the main OLS interface. Which on his turn interfaces
with the different tools modules. The browse module has a separate connection with the DAL
interface to save redundancy cycle checks and improve overall system (latency) performance.
Also the Code analysis module has a separate connection to the DAL modules for fast
function calling, and it saves system tension on high load times. The Meeting module has a
separate connection with the OLS and bug tracking module and feature request module for
more freedom for external programmers who want to write their own plug-ins for
communication forms and support.

Figure 9: Component Diagram

22

9. Scenario View
The scenario view connects all the mentioned views together. This view provides a few
typical and realistic use cases for the system, connecting the logical view, process view,
physical view, and deployment view together. This view addresses, among others, the user-
friendliness concern. The use cases describe interests which are for all five user groups.

Figure 9: Use case diagram

9.1 Use Case: Browse

This Use Case in Table 6 will demonstrate one of the more general tasks a user will execute if
he browse the code in his application or from his web browser. He can see all the code that he
wants to edit or document. To receive this information, the user makes use of Code Browse
Tool.

23

Use case Browse

Description Inspection of all artefacts of the project
Actors Programmers, Code reviewers, Designers,
Managers and Researchers
Assumptions Artefacts are on hand
Steps Actor entered the OLS.
OLS connects to database and repository.
Actor browsing for files
Variations (optional) Actor has no access to the OLS and is not
authorized to browse
Issues Actor has inspected the files
Table 6: Use Case: Browse

9.2 Use Case: Editing

This Use Case in Table 7 will demonstrate one of the tasks, a must undertake if he wants to
modify code that is stored in the database / SVN repository.
Use case Editing
Description Modification of any artefact of the project
Actors Programmers, Code reviewers, Designers,
Managers and Researchers
Assumptions Artefacts are on hand
Steps Actor entered the OLS.
OLS connects to database and repository.
Actor can edit the files
Variations (optional) Actor has no access to the OLS and is not
authorized to edit
Issues Actor has edited the file
Table 7: Use Case: Editing

9.3 Use Case: Analysis

This Use Case in Table 8 will demonstrate the tasks an user must undertake when he wants to
upload or modify a code analysis he has made with the analysis tool within the OLS.
Use case Analysis
Description Code analysis scrutinizes artefacts for properties
Actors Programmers, Code reviewers, Designers,
Managers and Researchers
Assumptions Artefacts are on hand
Steps Actor entered the OLS.
OLS connects to database and repository.
Actor can analyze the files
Variations (optional) Actor has no access to the OLS and is not
authorized to analyze
Issues Actor analyzed the file
Table 8: Use Case: Analysis

24

9.4 Use Case: Documenting

This Use Case in Table 9 will demonstrate one of the tasks an user must undertake when he
wants to document code that is stored in the repository / database with the documenting tool
within the OLS.

Use case Documenting

Description Explanation of an artefact.
Actors Programmers, Code reviewers, Designers,
Managers and Researchers
Assumptions Artefacts are on hand
Steps Actor entered the OLS.
OLS connects to database and
repository.
Actor can add a documentation to a
project.
Variations (optional) Actor has no access to the OLS and is not
authorized to document
Issues Actor has documented the project
Table 9: Use Case: Documenting

9.5 Use Case: Bug tracking

This Use Case in Table 10 will demonstrate the tasks an user must undertake to post a bug in
the bug tracking system and then gets a bug tracking id to track his bug in the browsing tool
of the OLS application.

Use case Bug tracking

Description Enter problems with the programs of the
project.
Actors Programmers, Code reviewers, Designers,
Managers and Researchers
Assumptions Artefacts are on hand
Steps Actor entered the OLS.
OLS connects to database and
repository.
Actor can add a bug.
Variations (optional) Actor has no access to the OLS and is not
authorized to add bugs
Issues Actor entered a bug problem
Table 10: Use Case: Bug tracking

9.6 Use Case: Feature Request

This Use Case in Table 11 will demonstrate the tasks an user must undertake to fill in a
feature request form in the OLS feature request application and how he can track the possible
development / communication about this feature in the OLS.

25

Use case Feature request

Description Address additional functionality to existing
programs of the project
Actors Programmers, Code reviewers, Designers,
Managers and Researchers
Assumptions Artefacts are on hand
Steps Actor entered the OLS.
OLS connects to database and repository.
Actor can add a feature request
Variations (optional) Actor has no access to the OLS and is not
authorized to add a feature request
Issues Actor added a feature
Table 11: Use Case: Feature Request

9.7 Use Case: Meeting

This Use Case in Table 12 will demonstrate one of the more general tasks an user will do if he
wants to have a project meeting with the project meeting tool that is within the OLS system.
And wants to support this with the bug tracking and feature request tool.

Use case Meeting

Description Communicate with about project related problems
Actors Programmers, Code reviewers, Designers,
Managers and Researchers
Assumptions Other persons to communicate with
Steps Actor entered the OLS.
Actor set-up a meeting
Variations (optional) Actor has no access to the OLS and is not
authorized to set-up a meeting
Issues A meeting is started
Table 12: Use Case: Meeting

9.8 Use Case: Export

This Use Case in Table 13 will demonstrate the tasks an user must undertake to export code
from the repository / database in to source code in other data formats.

Use case Export

Description Export project related artefacts
Actors Programmers, Code reviewers, Designers,
Managers and Researchers
Assumptions Connection to the system
Steps Actor entered the OLS.
OLS connects to database and repository.
Actor export a file.
Variations (optional) Actor has no access to the OLS and is not
authorized to export a file
Issues Actor exported the file
Table 13: Use Case: Export

26

10. Rational Architectural Description Specification View

The Rational Architectural Description Specification (ADS) is a viewpoint that is an
expansion that is build on the 4+1 model described in chapter two of this document. It
enables the description of more complex architectures, it defines mappings between the
different views. ADS features a formal definition of requirements evolution and architecture
testability, and utilizes UML notation where possible. The rationale for the architecture must
still be documented separately. The views of the 4+1 model have been partially renamed
and four new views have been defined. The Scenario view has become the Use Case view, the
Development view has become the Implementation view, and the Physical view has become
the Deployment view. The nine views have been grouped into four viewpoints, see Figure 11.
[May, 2004]

The views of each viewpoint corresponds to the models of the IEEE 1471 framework in the
Rational ADS. The consistency of elements in different views is maintained by explicit
mappings between the views. The context of lower viewpoints are provided by the mappings
to higher viewpoints. As can be seen from the explicit mappings between views shown in
Figure 11, the Non-Functional Requirements View is only loosely coupled to the other views.
Usually it is depicted as a list of requirements and their properties, such as priority or
category. As it is not linked to any of the structural views of software architecture it has been
omitted when determining the concerns addressed by this model.

Figure 11: The Rational ADS: Viewpoints and Views

27

10.1 Rationale
In this document only one of the four ADS views will be written out. In this case it is the
deployment view. This view is particularly aimed at the stakeholders (managers) who are
going to pay for the OLS and its maintenance. These stakeholders are a little underexposed in
this paper, hence this particular viewpoint. The deployment viewpoint is a viewpoint for
specifying the mapping of the software onto hardware and for specifying its distribution. Most
information of what is needed at the software level for the deployment of the OLS is given in
the Physical View mentioned in chapter seven. The actual hardware information in addition to
this information, information about the physical hardware for deployment, will be given
below.

10.2 Hardware
Servers of any major hardware vendor (Dell, HP, IBM, etc) will do in this project, specific
cost and specs about the servers are omitted.

Servers needed:

Server: Web server

General Function: Servering the content / interface to users who are using their browser.
General Characteristics: Multiple LAN interfaces
General Costs: around 5.000 euro

Server: Database server

General Function: Server for serving and handling the mySQL requests.
General Characteristics: Lot of memory
General Costs: around 7.000 euro

Server: File server

General Function: Serves as storage for user uploaded code and analysis
General Characteristic: Multiple large hard drives.
General Costs: around 6.000 euro

Server: Application server

General Function: All tools run on this two servers
General Characteristics: Fast processors
General Costs: around 7.000 euro

Server: Application server

General Function: All tools run on this two servers
General Characteristics: Fast processors
General Costs: around 7.000 euro

Server: SVN repository server

General Function: The SVN repository resides on this server
General Characteristics: A lot of disk space and memory
General Costs: around 9.000 euro

28

Server: Two DAL servers

General Function: Providing DAL services to web servers and also serve as direct interface
for dependent client software
General Characteristics: A lot of disk space and memory
General Costs: around 10.000 euro

Server: Two Backup servers

General Function: Backing up databases and file servers and also serve as backup server
when one of the servers above fail.
General Characteristics: A lot of disk space and fast LAN interfaces
General Costs: around 15.000 euro

11. Implementation Proof

This chapter describing two similar OLS compared with the OLS used in this document. The
Blackboard and the Sakai project are compared based on Open Source comparison models.

In Table 14, two e-learning systems which are comparable towards the OLS are rated, based
on their functionalities and their specifications.

Blackboard Sakai
Functionality ++ ++
similarity
Price -- --
Open Source - +
Implementation + +
Programming Java Java
language
Data backend MySQL MySQL
First release 1997 2005
Table 14: Impact Matrix

In order to conclude whether the OLS can be implemented, an analysis towards other
programs has been conducted. Therefore the systems blackboard and Sakai have been
analyzed in comparison with the OLS in terms of functionalities and specifications of the
different systems.

The OLS cannot really be compared towards these systems, because the OLS has more
functionality in terms of modifying and collaboration between different user groups. But in
terms of other functionalities like file sharing, the comparison between the OLS, blackboard
and Sakai system can be made.

The conclusion which can be drawn from this table is that the pricing of these systems are
high. When one compares the price of the OLS with the prices of blackboard/Sakai, one can
see that the price of the OLS will be lower because this system is created by the stakeholders,
where the other products have to be bought.

29

12. Realization Proposition

This chapter describes the realization of the proposed project. Only processes, activities and
hardware are taken into account as mentioned before in this document. The calculation is an
estimation based on experience of the authors. The three employees are the authors of this
document. A total overview is described in Table 15

Task Time planning Personnel/Equipment

Setting up database/ 1-2 months 3 Employees

repository
Setting up DAL 1 month 3 Employees
Programming Tools 3 5 months 3 Employees
Create OLS 2 -3 months 3 Employees
Hardware 1 month 3 Employees
Implementation 1 month 3 Employees
Total 9 - 13 months 3 Employees
Table 15: Time Planning

12.1 Costs
In this section the costs of the whole project are described. These costs are also based on an
estimation made by the authors. First costs considering the hardware which are based on the
hardware that is described in chapter 10.2. The total costs of the hardware are described in
Table 16

Hardware Price
Web server 5.000
Database server 7.000
File server 6.000
Application server 1 7.000
Application server 2 7.000
SVN Repository 9.000
2 Dal servers 10.000
2 Back-up servers 15.000
Total 66.000
Table 16: Costs

The other costs that are needed for the calculation are the men-hour costs. The cost for a
labour hour for each employee are estimated on 50.

50 * 160 hours (month) = 8000 monthly * 3 employees = 24.000 monthly labour hours.

13 months * 24.000 = 312.000 for the total employment costs.

The total costs are as follows.

Project costs:
Hardware 66.000
Men-hours 312.000 +
Total 378.000
30

13. Conclusion
It has been shown that the architecture proposed in this document meets all the requirements
requested by the stakeholders. The structure of the software as well as the chosen hardware
configuration, allows it to easily scale the system when it is needed. The separation of the
presentation layer, logic layer, and the data layer makes the architecture well structured and
understandable.

A pattern is a structure, which is set up in order to solve highly prevalent software problems.
The pattern does not give a concrete solution, but provides a sort of template which supports
the design problem.
After analyzing the concerns and the requirements, an appropriate pattern has been chosen.
An Architectural pattern like the layer pattern supports the OLS the best, because this pattern
supports the concerns and the associated requirements of the different stakeholders the most.

The cost of the hardware are within reasonable boundaries for a project with the features and
requests. Since only open source software will be used as system software, the latter will be
available at very low cost, but still has professional support available.

Developing the packages will not exceed an acceptable amount of developing time, although
it is suspected that the calculated numbers are underestimated. Before releasing the final
system to the public, benchmarking, testing, etc will have to be carried out to ensure that the
OLS works as desired and expected. However, the use cases demonstrates the overall
feasibility of the proposed architecture.

31

14. Contribution Of Team Members

The software architecture described in this document has been analyzed, discussed, and
agreed upon by all members of team 9. The division of work listed below concerns mainly the
written contributions.

1. Introduction Diana

2. Stakeholders and Concerns Diana

3. Requirements Diana

4. Architectural Description Framework Vincent

5. Logical View Michel / Vincent

6. Process View Michel / Vincent

7. Physical View Michel / Vincent

8. Development View Michel / Vincent

9. Scenario View Michel

10. Rational Architectural Description Specification View Vincent

11. Implementation Proof Diana / Michel

12. Realization Proposition Michel

13. Conclusion Vincent / Diana

32

15. Reference List

[Albin, 2003] Albin, S. T. (2003). The Art of Software Architecture - Design
Methods and Techniques. Wiley Publishing, Inc.

[APG, 2006] IEEE Architecture Planning Group. (2006). IEEE Std 1471-2000 IEEE
Recommended Practice for Architectural Description of Software-Intensive Systems. IEEE
Software.

[Dijkstra, 2008] Dijkstra, A. (2008). Course Assignments - Architecture project.

http://www.cs.uu.nl/wiki/Swa/CourseAssignments [2008-01-09].

[Kruchten, 1995] Kruchten, P. (1995). Architectural Blueprints: The 4+1 View

Model of Architecture. IEEE Software 12, pages 4250.

[May, 2004] May, N. (2004). A Survey of Software Architecture Viewpoint Models.

33