Architecture for an Online Learning System

Transcription

1 Architecture for an Online Learning System Utrecht University Vincent Vonk Michel Wasmann Diana Sidharta January 14, 2008

2 Contents 1. Introduction Stakeholders and Concerns Stakeholders Concerns Requirements Functional Requirements Non-functional Requirements Constraints Architectural Description Framework Logical View Rationale View Of The System Process View Rationale Component Process Sequence Physical View Rationale Layered System Structure Development View Rationale The Different Interfaces Scenario View Use Case: Browse Use Case: Editing Use Case: Analysis Use Case: Documenting Use Case: Bug tracking Use Case: Feature Request Use Case: Meeting Use Case: Export Rational Architectural Description Specification View Rationale Hardware Implementation Proof Realization Proposition Costs Conclusion Contribution Of Team Members Reference List

3 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 criteria s. 3

4 Criteria Concern Stakeholder Functionality Code documentation, and other artefacts required for building the program are organized as a collection of text fragments (or chunks) and normal files. Programmers Code reviewers Designers Managers Researchers Analyze artefacts for properties. Programmers Code reviewers Allowing inspection of all artefacts of the project, exploiting the meaning of all formalisms used to encode sources. Code reviewers Managers Researchers Artefacts must be easily requested. Programmers Reliability A distributed environment which allows contributors to the project to participate independently of physical location. System needs to be fault tolerance. Programmers Code reviewers Designers Managers Researchers Programmers Code reviewers Designers Managers Researchers Usability A function to export files. Programmers Maintainability Portability Users are allowed to enter problems with the programs of the project. Artefacts must be documented. Modification of any artefact of the project, again exploiting the type of those artefacts. Addressing additional functionality to the program. Support the resolution of project related problems. Programmers Code reviewers Designers Managers Researchers Programmers Code reviewers Managers Researchers Programmers Managers Programmers Code reviewers Designers Managers Researchers Table 1: Stakeholders Concerns 4

5 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. 5

6 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 Each chunk resides in a normal file, tagged with a variant number, an optional name and a type Files themselves are also typed, e.g. based on the suffix of their name Types are used throughout the system to tailor functionality of system components Variant numbers are used to distinguish program variants 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 The hierarchy imposed by the explicit inclusion of other chunks can be inspected as if it were a file system Files can also be inspected in a type driven way: its rendering is dependent on its type Code editing may be partially or fully integrated with code browsing Name completion: suggest the completion of partially typed keywords and identifiers based upon the available definitions Language construct completion: suggest the completion of partially typed language constructs Check for syntax while typing Allow developers to work in the classical checkout + modify + commit cycle Simple properties of the type of an artefact have number of lines or number of words A simple property taking into account the type of an artefact partitions such properties into comment and code Complex properties like this identifier is referred to by are allowed Users must be able to add new analyses System must indicate the expected time an operation takes 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 Explanation can be browsed in different ways, the default being per artefact. 6

7 6.6. Explanation can also be browsed as specified by a user, e.g. a tutorial, a paper, or a thesis The process of solving a problem is tracked The connection to required modifications: design documents, additional documentation, chunks/files, etc is tracked Enter problems and address additional functionality 8.2. Track use of documents Track and allow connections between artefacts The system can be extended with new types requirements, by the user Offering a blackboard mechanism Support communication by means of audio/video/documents Make use of the bug tracking and feature request tools Source code distribution PDF documentation 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 Maintainability/ Managebility Portability/ conformance Efficiency/ Time behaviour Efficiency / Resource behaviour Table 4: Non-functional Requirements Description The system must either guarantee consistency between the various copies of artefacts. The system must be platform independent, but also Platform dependent available. All data is available as a database based repository, for fast access by analysis tools. The system must be responsive for common editing activities. Less frequently used functionality may take more time. 7

8 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 Reliability/ Availability Reliability/ Availability Reliability/ Fault tolerance Table 5: Constraints Description The system should make use of a SVN repository, as well as a database based repository. The system must guarantee consistency, it must indicate possible 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. The data needs to be redundant. 4. Architectural Description Framework The architecture will be structured according to ANSI/IEEE , 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. 8

9 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 9

10 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 system s 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

11 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, it s 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

12 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. It s 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

13 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 user s 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 user s browser or application. 13

14 Figure 4 shows the following steps for the Code editing feature: 1. The user s 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

15 Figure 5 shows the following steps for the manual Code analysis feature: 1. The user s 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 user s 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 user s 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

16 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 user s 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 bug s he submitted in the browsing tool. 16

17 Figure 6 shows the following steps for the submitting a feature request: 1. The user s 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 user s 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

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

19 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 Microsoft s.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

20 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

21 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

22 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

23 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 userfriendliness 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

24 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

25 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

26 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

27 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

28 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 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 euro Server: Database server General Function: Server for serving and handling the mysql requests. General Characteristics: Lot of memory General Costs: around euro Server: File server General Function: Serves as storage for user uploaded code and analysis General Characteristic: Multiple large hard drives. General Costs: around euro Server: Application server General Function: All tools run on this two servers General Characteristics: Fast processors General Costs: around euro Server: Application server General Function: All tools run on this two servers General Characteristics: Fast processors General Costs: around 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 euro 28

29 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 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 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 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

30 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 The total costs of the hardware are described in Table 16 Hardware Price Web server Database server File server Application server Application server SVN Repository Dal servers Back-up servers Total 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 * 160 hours (month) = 8000 monthly * 3 employees = monthly labour hours. 13 months * = for the total employment costs. The total costs are as follows. Project costs: Hardware Men-hours Total

31 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

32 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

33 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 IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. IEEE Software. [Dijkstra, 2008] Dijkstra, A. (2008). Course Assignments - Architecture project. [ ]. [Kruchten, 1995] Kruchten, P. (1995). Architectural Blueprints: The 4+1 View Model of Architecture. IEEE Software 12, pages [May, 2004] May, N. (2004). A Survey of Software Architecture Viewpoint Models. 33