CC Software Architecture Document V.4.0

(1)

CC_Software Architecture Document_V4.0 6-th August 2013

6-TH AUGUST 2013

CC Software Architecture Document V.4.0

SC 2011 86 08 “Re-design, Re-branding and Re-development of the teachers’ corner of www.dolceta.eu.

(2)

Dissemination Level

(3)

- TABLE OF CONTENTS -

Contributors & Quality Control ... Error! Bookmark not defined.

Dissemination Level ... 2

1. INTRODUCTION ... 5

1.1. Purpose ... 5

1.2. Scope 5 1.3. Definitions, Acronyms and Abbreviations ... 5

1.4. References ... 5

1.5. Overview ... 5

2. ARCHITECTURAL REPRESENTATION ... 6

3. ARCHITECTURAL GOALS AND CONSTRAINTS ... 8

4. SECURITY ... 11

4.1 Security Overview ... 11

4.2 Philosophy ... 12

4.3 Scope ... 12

4.4 Assumptions ... 13

4.5 Trusted Computing Base ... 13

4.7 Mapping of Features to Requirements ... 14

5. USE-CASE VIEW ... 16

6. LOGICAL VIEW ... 16

6.1 Overview ... 16

6.2 Architecturally Significant Design Packages ... 17

6.3 Use-Case Realizations through Modules ... 20

6.4. Relationships between the packages and the modules ... 30

6.5. Cache module used on ConsumerClassroom DRUPAL CMS ... 37

6.6. Data access layer and concurency checker ... 38

7. PROCESS VIEW ... 40

8. DEPLOYMENT VIEW ... 42

8.1. Hardware overview ... 42

8.2. Hardware architecture map ... 42

9. IMPLEMENTATION VIEW ... 44

9.1 Overview ... 44

9.2 Layers ... 44

10. DATA VIEW ... 46

(4)

12. QUALITY ... 48

13. SOFTWARE CARTOGRAPHY AND BUSINESS FUNCTIONS

(5)

1. INTRODUCTION 1.1. Purpose

This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant security-related architectural decisions which have been made on the system.

1.2. Scope

The scope of this document is to describe the security domains, trust levels, infrastructure related security, and the relationships among them. This document describes the overall architecture of the Consumer Classroom solution and refers to the supportingelements needed for functionality, and the architecture refers to the cohesive designof the elements.

1.3. Definitions, Acronyms and Abbreviations

Acronyms and abbreviations are explained within context within this document.

1.4. References

Other reports and documents referenced within this document include:

• Consumer Classroom Business Use Case Model

• Dolceta 2.0 Technical Feasibility Report

• Consumer Classroom Supplementary Specifications

1.5. Overview

This document is organised as follows:

• Section 2 provides an overview of the architecture deployed as part of the solution.

• Section 3 provides an overview of the requirements that have an impact on the architecture aspects of the solution.

• Section 4 describes the security aspects of the software architecture.

(6)

• Sections 5, 6, 7, 8, 9 and 10 depict various views of the solution.

• Section 11 discusses the size and performance of the solution.

• Section 12 presents the software cartography of the solution.

2. ARCHITECTURAL REPRESENTATION

The architecture of the software solution can be considered as existing at different solution layers as depicted in the diagram below. It is consistent with standard architecture principles of Web 2.0 solutions.

Figure 1: Solution Layers & Interoperability

The communication layer provides protocols for exchanging processing

instructions that have been initiated by users of the website solution. The objective of interoperability at this layer is to achieve a seamless integration of communications relating to the instructions received and feedback given to the users of the website solution.

The content description layer provides a process to and organise the

information relating to a received instruction in such a way that it can be understood and used. For example if the solution receives a message that contains a document, it must determine what the document actually

(7)

represents, e.g. a photographic image, a text document, etc. Interoperability at this layer achieves a seamless integration of data formats.

The process layer is concerned with interaction. When initiating an

instruction on the website, agreement is needed on the procedures of the process, what a message may mean, what actions are allowed, what responses are expected, etc., such that there is no ambiguity surrounding the execution of the instruction and operation of the software solution.

The following diagram illustrates the logical deployment of the portal solution within its environment:

Figure 2: Logical Deployment Architecture

Clients can be teacher users known to the system through user ID's, or anonymous users from anywhere in the world. In this type of deployment, security is enforced at various points within the architecture. This is further described in the Technical Feasibility Report document.

(8)

The physical architecture deployment of the solution is the same as the existing Dolceta website solution that has been previously described in documents relating to RfS 1 and 2.

3. ARCHITECTURAL GOALS AND CONSTRAINTS

The simple configuration for the developed web application on PHP consists on three layers.

The Operating System (OS) could be a Windows server distribution or a Linux distribution. We will use Linux.

Over OS we must install the WEB server. The Apache HTTP Server is an open-source HTTP server for modern operating systems including UNIX, Microsoft Windows, Mac OS/X and Netware. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services observing the current HTTP standards. Apache has been the most popular web server on the Internet since April of 1996.

PHP, stands for PHP: Hypertext Preprocessor, is a server scripting language, and is a powerful tool for making dynamic and interactive Web pages.

(9)

The database used is MySQL. MySQL is the world's most popular open source database software, with over 100 million copies of its software downloaded or distributed throughout its history. With its superior speed, reliability, and ease of use, MySQL has become the preferred choice for Web, Web 2.0, SaaS, ISV, Telecom companies and forward-thinking corporate IT Managers because it eliminates the major problems associated with downtime, maintenance and administration for modern, online applications.

The Drupal layer comes over all of these layers and is the interface between user and system.

(10)

Drupal CMS accepts load balancing between application servers which use one MySQL database. Load balancing is the practice of evenly distributing work among multiple computers. This technique provides several important benefits. These include:

• Reducing the load on individual systems and minimizing response time • Increasing network utilization and maximizing throughput

• Improving reliability • Facilitating scaling

• Improving user satisfaction

To improve reliability of the MySQL, database, it can be scaled out using Master-Slave or Master-Master Replication.

(11)

4. SECURITY

The content of this chapter concerns basically the security requirements and security design deliveries of the Consumer classroom website.

4.1 Security Overview

This section is intended to describe the boundaries and security purpose in terms of availability, confidentiality, privacy and trust. This section will consider each of these elements from a security perspective.

The usage of these terms in this context is intended to mean the following1:

• Security concerns regarding the confidentiality, availability and integrity of data or information. Security may also include authentication and non-repudiation.

• Privacyconcerns the expression of or adherence to various legal and non-legal norms regarding the right to private life. In the European context, this is often understood as compliance with European data protection regulations.

• Trustrevolves around assurance and confidence that, data, entities, information or processes will function or behave in expected ways.

1

Robinson et al., 2010, The Cloud: Understanding the Security, Privacy and Trust Challenges. (A report funded by the EU)

(12)

In general the software architecture is cognisant of achieving the following security related goals:

• Security. The solution can be accessed by any individual from anywhere in the world. As such in general usages terms (not administrator or privileged user terms) unauthorised access cannot be attributed to this software.

• Availability. The system is available for operation and use as

committed within the hosting environment service level agreement.

• Processing integrity. System processing is complete, accurate and timely.

• Confidentiality. Information designated as confidential is protected (e.g. user details and passwords).

• Privacy. Personal information is collected, used and retained, in accordance with EU data protection norms and guidelines.

4.2 Philosophy

The overall security philosophy is consistent with the security design and architecture principles of Web 2.0 systems. Security refers to the protection of the system from unauthorised access, both logical and physical. Limiting access to the system helps prevent potential abuse of the system, theft of resources, misuse of software, and improper access to, or the use, alteration, destruction, or disclosure of information. Key security elements for the protection of the system include permitting authorised access based on relevant needs and preventing unauthorised access to the system in all other instances.

However it should be noted, as this is a web-based solution, in this instance all potential users of the system are considered to be authorised users and the website and its associated resources exist to fulfil these users’ relevant needs relating to consumer education.

4.3 Scope

The intended scope of security within the system can be described in terms of the software solution on which the website is based and the infrastructure or environment within which this solution resides.

Section 7 of the Supplementary Specification document provides an overview of the security scope of the website solution.

Existing European Commission infrastructure is not considered as it is not expected to provide security services in the context of this solution.

(13)

4.4 Assumptions

No inherent or explicit assumptions relating to security are made within this document.

4.5 Trusted Computing Base

Trust levels specify the minimum requirements for authentication and authorisation based on the requested information or resource and the transport path from the user domain to the requested domain. The solution is a Web 2.0 solution that is open to general members of the public accessible from anywhere in the world. As such it can be described supporting levels two and three trust base.

Clarification of these trust levels as follows:

• Level three is typically considered not to be trusted in security terms. No authentication or authorisation is needed to gain access to the system. This layer relates to public information available on the website to all users who access the website.

• Level two is considered trusted within certain contexts and subject to certain conditions. In this level, user ID and password are required for authentication and authorisation. In certain website usage scenarios, users are requested to login to use certain website functions and access certain website data. Level two trust layer relates to the use of proprietary information.

The website in its design is capable of supporting a level one trust base. That is, it is capable of supporting strong authentication methods such as tokens with personal identification numbers or digital certificates for authentication and authorisation. However this level of security is not deemed as necessary at this point in the development and implementation of the website solution.

It should be noted the solution as it exists as a public accessible website domain, that the website domain itself has not been certified to determine a level of trust. Domain certification is the process of verifying that all elements of the domain meet the requirements of the certification process for the assigned trust level.

(14)

4.7 Mapping of Features to Requirements Security Requirement Security Feature

Procedures exist to restrict logical access to the solution. Including identification and

authentication of users.

A (teacher) user must establish their identity to the system when accessing non-public

resources on the website through the use of a valid user ID that is authenticated with a password.

Unique user ID's are assigned to individual users.

The solution does not support the use of shared user ID's.

Procedures exist to restrict logical access to the solution. Including registration and

authorisation of new users.

The software solution enables users to self-register under a secure session in which they provide specific user information and create a user ID and password.

Privileges and authorisations to the solution provide access to certain data and

functionality within the solution. Access privileges beyond the default

privileges assigned to users is not possible via the classical website interface.

Procedure exists to modify user access to the solution.

Including

Process to make

changes and updates to users.

The ability to create or modify users and user access privileges is limited to the system administrator.

Changes and updates to self registered users can be done at any time by the individual user. Unused users accounts (no activity over a defined period of time such as 12 months) can be purged by the website moderator.

Access of offline storage and backup data

Access to the solutions back up data is restricted to IT support personnel through the use of physical access controls on the facility in which the backups are held.

Restriction of access to solution supports and

Solution support software, hardware and the solution's operating environment are restricted to IT support personnel through physical

(15)

Security Requirement Security Feature

devices access controls, native operating system

security and add on server security software.

Restriction of access to solution access and usage logs

Usage statistical logs are maintained for the solution. Certain IT support personnel have access to the solution access logs. They are reviewed on a monthly basis and reported on to the DG SANCO/EAHC.

Protection of software against malicious attacks and threats

Firewalls are used and configured as part of the overall solution.

Within the solutions’ operating environment, antivirus software is in place and is updated on a regular basis.

Any viruses discovered are reported to IT support personnel and an alert is issued, warning users of the potential threat of the virus.

Procedure exists to identify, report and act on incidents relating to the software.

A detailed incident management plan has been prepared and is kept up to date.

The incident reporting and management tool, known as JIRA, is operable and will be used for managing and reporting on incidents relating to the software.

All incidents are tracked until they are closed out.

Requests for changes, system maintenance, etc are subject to documented change management procedures. Changes are categorised and ranked according to priority, and procedures are in place to handle urgent matters. Change requestors are kept informed about the status of their requests. JIRA is used to track and report on such elements.

Design, acquisition, implementation, configuration, modification, and

In the design and development of the solution, we have adopted a formal systems

development life cycle (SDLC) methodology that governs the development,

(16)

Security Requirement Security Feature

management of software is consistent with

standard security practices.

implementation, and maintenance of information systems.

The SDLC approach includes a framework for classifying data and the creation of user profiles that are established within the solution. Proposed user profiles are presented in the business use case documentation.

The IT team reviews and approves the

architecture and design specifications for new elements of functionality introduced into the solution to help ensure consistency with the solutions' existing security elements.

5. USE-CASE VIEW

The Use Case View has been presented in a comprehensive manner in the Business Use Case Model document, with further extensive explanations provided in the Supplementary Specifications document. Please refer to these documents for further reading.

6. LOGICAL VIEW

Effective Web design is driven by the need to balance flexibility and simplicity. If a system is too simple, it can only be used for a single purpose - but if it is too flexible, it may be too difficult for new users to learn.

Drupal strives to reconcile these conflicting goals by providing its users with the tools they need to make their own content management solution, while still providing some pre-built components to help them get started. Thus, it can be described both as a content management system (CMS) and a content management framework (CMF) - one system which strives to have the strengths of both, without their deficiencies.

6.1 Overview

Drupal core, and the thousands of contributed modules that build on it, require an initial investment to learn, but mastering the Drupal way is immensely

(17)

rewarding; the passionate community is a testament to its power to liberate site builders from the simplicity/flexibility dilemma.

6.2 Architecturally Significant Design Packages Entity types:

An entity type is an abstract data type in Drupal. Field table entities make Drupal

eminently flexible. An entity type is a useful abstraction to group together fields. Some example of entities types are:

• Nodes (content)

• Comments

• Taxonomy terms

• User profiles

a) Bundles

Bundles are an implementation of an entity type to which fields can be attached. It can be considered as subtypes of an entity.

Fields.

Bundles contain fields. They are content containers that can be attached to many, but not all, Drupal system entities. For example, if you wanted to add an Expiration Date value to all of your site's articles, you could define a new field called Expiration Date and then associate this field with the Article content type. The freedom to define new fields and associate them with content types gives you the power to store almost any type of content in Drupal.

a) Widgets

A field can have widgets. A widget is the UI element that allows a user to enter data into the field. Some example of widgets are text widgets and image widgets to show you how to upload an image and display it in different view modes.

b) Formatters

A field can have formatters. A formatter defines how a field's data gets displayed in a view mode.

c) Entity

An entity is one instance of a particular entity type such as a blog post, comment, or taxonomy term.

Nodes.

Nodes are content items. Drupal content types are all based upon nodes. When managing content in Drupal, you are managing nodes. For example, if you create and publish a blog post with Drupal, you have created and published a Drupal node. Nodes are composed of default elements (for example, a title and a body) and optionally, one or more associated Drupal Fields. By default, nodes are simple entities. The intention is that you, as the Web site owner, will extend the simple node when you define your own content types.

(18)

Comments

Drupal comments are native system entities that represent commentary or feedback from a user. Comments must be associated with a piece of content in the system—in technical terms, a node. It is not possible, for example, to comment on a user profile. Comments can optionally be associated with other comments. In other words, a user may reply to his own or another user's comment, and in this way Drupal comments can represent a conversation. This is also known as comment threading.

Taxonomies. Taxonomies are used to organize content in Drupal. The Drupal taxonomy functionality is defined in a core module that allows you to define what are calledvocabularies—groups of categories or labels—and then associate them with content types in the system. After a taxonomy is associated with a content type, you can use the taxonomy when creating or editing content of that type. Taxonomies can take different formats—they can be hierarchical, flat, or arbitrary, as in the case of ataggingsystem. For example, if you created a blog about sports, you may want to use a taxonomy to categorize each blog post by the sport that it's about. You may also want to label each post with the names of the players that it mentions. The first taxonomy would probably be a category system that you define in advance. The second taxonomy could be a tagging system, an arbitrary list of words or phrases, that is filled in as the content is authored.

User profile. A Drupal user is anyone who can sign in to the system and then perform an action. This includes editors, system administrators, and Web site users who might, for example, be interacting with each other via your Drupal Web site. Drupal also has a security concept called the anonymous user. All Web site visitors are considered anonymous users until they sign in. Users are a native entity in the system, and they come by default with a set of properties such as username, password, e-mail address, and so on. You can also customize user profiles by adding new elements to the profile. For example, you could add a new URL element for a user's Twitter address.

Modules

Drupal modules are software packages that add to or change existing Drupal functionality. There are two general categories of modules: core modules, which come with Drupal by default, and contributed modules, which are contributed by the community. If working with the base Drupal distribution, you must download and install contributed modules separately. If you work with other distributions, you will likely start off with a combination of core and contributed modules. The standard Drupal release includes a limited number of core modules, typically less than 50. In contrast, many thousands of contributed modules exist. You can download these from the official Drupal Web site here:

http://drupal.org/project/modules. Advanced administrators and developers can

(19)

Hooks

Hooks are an advanced programming concept appropriate for developers who want to create their own modules. Hooks represent the internal application programming interface (API) for all system and module functionality. They define the operations that can be performed by the system. When a module implements a hook, it enters into a contract with the system to perform the operation associated with that hook.

For example, if you have a node module called exampledefined in a file named example.module and in this file you define the functionexample_form(), then this module has entered into a contract with the system to display an editing form when the system calls that function.

Regions, blocks, and menus

Each page of your Drupal Web site is comprised of regions. For example, your page structure may contain regions called header, footer, left column, and main content. Blocks are chunks of content that are assigned to and displayed in one specific region. The menu system is generally responsible for displaying the navigational elements of your Web site. It also serves another function;

specifically it deals with mapping URL requests to the part of the Drupal system that will process the request. This is called request routing, and it's an advanced Drupal concept.

Themes

In Drupal, the theme layer is responsible for creating the HTML (or JSON, XML, etc.) that the browser will receive. The important thing to remember is that Drupal encourages separation of content and markup. Drupal allows several ways to customize and override the look and feel of your web site. Drupal’s template files consist of standard HTML and PHP. Additionally, each dynamic part of a Drupal page, such as a list or breadcrumb trail, can be overridden simply by declaring a function with an appropriate name. In Drupal-speak, themes are a collection of files that make up the look and feel of your site. Themes are made up of most of the things you’d expect to see: style sheets, images, JavaScript files, and so on. The difference between a Drupal theme and a plain HTML site is targeted

template files. Template files typically contain large sections of HTML and smaller special snippets that are replaced by dynamic content as Drupal

constructs the page. You can create targeted template files for just about every container of content in Drupal—such as the overall page, regions, blocks, nodes, comments, and even fields.

Menu System

Drupal’s menu system is complex but powerful. The term “menu system” is somewhat of a misnomer. It may be better to think of the menu system as having three primary responsibilities: callback mapping, access control, and menu

(20)

customization. Drupal's menu system follows a simple hierarchy defined by paths.

Form API

Drupal features an application programming interface (API) for generating, validating, and processing HTML forms. The form API abstracts forms into a nested array of properties and values. The array is then rendered as part of the process when Drupal renders the page that contains the form. There are several implications of this approach:

• Rather than output HTML, we create an array and let the engine generate the HTML.

• Since we are dealing with a representation of the form as

structured data, we can add, delete, reorder, and change forms. This is especially handy when you want to modify a form created by a different module in a clean and unobtrusive way.

• Any form element can be mapped to any theme function.

• Additional form validation or processing can be added to any form.

• Operations with forms are protected against form injection attacks, where a user modifies a form and then tries to submit it.

6.3 Use-Case Realizations through Modules

The Use Case realisation has been presented in a comprehensive manner in the Business Use Case Model document, with further extensive explanations

provided in the Supplementary Specifications document. In the later document, we have presented a collection of workflows that are illustrating the logical view of the features presented in the Business Use Case Model. Please refer these two documents for further reading.

6.3.1 Contrib Module

Administration language v. 7.x-1.x-dev

This module lets the administrator see all administration pages in his/her preferred language. You can use this to display the frontend of the site in one language and still keep most of the backend in English (or another language of your choice).You can use the standard Languages page to choose the language of the admin pages.

This module is used for administration only.

Administration menu v. 7.x-3.0-rc3

Provides a theme-independent administration interface (aka. "navigation", "back-end"). It's a helper for novice users coming from other CMS, a time-saver for site administrators, and useful for developers and site builders.

(21)

Administrative links are displayed in a CSS/JS-based menu at the top on all pages of your site. It not only contains regular menu items — tasks and actions are also included, enabling fast access to any administrative resource your Drupal site provides.

This module is used for administration only

Advanced Forum v. 7.x-2.x-dev

Advanced Forum builds on and enhances Drupal's core forum module. When used in combination with other Drupal contributed modules, many of which are automatically used by Advanced Forum, you can achieve much of what stand alone software provides. Because it uses the core forum module, it uses the node and comment system built into Drupal and is completely integrated, not a bridge. While it doesn't have all of the features of stand alone forum applications, being completely integrated into your site provides advantages that they don't.

The module is used for the forum section.

Advanced help v. 7.x-1.0

The advanced help module allows module developers to store their help outside the module system, in pure .html files. The files can be easily translated simply by copying them into the right translations directory. The entire system can appear in a popup or not as the module prefers (and by taking away access to view the popups, a site can force the popups to not exist).

The system ties into Drupal's search system and is fully indexed, so the entire contents can be searched for keywords. the help files can be placed in a hierarchy as well, allowing for top down navigation of the help.

By itself, this module doesn't do much; it requires another module to support it, but it does come with a nice little sample of text from Wikipedia to demonstrate the system.

Block Theme v. 7.x-1.1

BlockTheme allows an admin to define tpl files for standard block templates and provides a select box on the block configure form so the user can select a tpl file to use as opposed to having to override the templates by block ID

The module is used to overwrite the default theme for a block. It is used in all the blocks in the site.

(22)

This module will display any Views date field in calendar formats, including CCK date fields, node created or updated dates, etc. Switch between year, month, and day views. Back and next navigation is provided for all views.

This module is used in the “ My Calendar ” section. It represents the calendar in all states

Context v. 7.x-3.0-beta3

Context allows you to manage contextual conditions and reactions for different portions of your site. You can think of each context as

representing a "section" of your site. For each context, you can choose the conditions that trigger this context to be active and choose different aspects of Drupal that should react to this active context.

Think of conditions as a set of rules that are checked during page load to see what context is active. Any reactions that are associated with active contexts are then fired.

This module is not used directly but is needed by the “Mega tags” module in order to work correctly

Chaos tools v. 7.x-1.0

This suite is primarily a set of APIs and tools to improve the developer experience. It also contains a module called the Page Manager whose job is to manage pages. In particular it manages panel pages, but as it grows it will be able to manage far more than just Panels.

This module is not used directly but is needed by several modules (ex: Advanced Forum, Calendar).

Date v. 7.x-2.6

This package contains both a flexible date/time field type Date field and a Date API that other modules can use.

This module enables data fields that are used on any content type that require a date field.

For example, we use this field type on Inter School Project form.

Entity API v. 7.x-1.0-rc3+11-dev

This module extends the entity API of Drupal core in order to provide a unified way to deal with entities and their properties. Additionally, it

(23)

provides an entity CRUD controller, which helps simplifying the creation of new entity types.

This module is not used directly but is needed by the “Field collection” module in order to work correctly

Field collection v. 7.x-1.0-beta4+14-dev

Provides a field-collection field, to which any number of fields can be attached. A field collection is internally represented as an entity, which is embedded in the host entity. Thus, if desired field collections may be viewed and edited separately too. Some content type need to have groups of fields.

This module helps to work with fields. For example, a lesson from “Lesson Builder“ section can have multiple images but an image has a title, caption and the image . This three fields are grouped and stored as an entity.

Fivestar v. 7.x-2.0-alpha2+5-dev

The Fivestar voting module adds a clean, attractive voting widget to nodes.

We use this module to store the rating on any type of content that require rating. Ex : Resource , User comments.

Internationalization v. 7.x-1.5

This is a collection of modules to extend Drupal core multilingual

capabilities and be able to build real life multilingual sites. Some features:

• Taxonomy translation (both, per language terms and translatable terms)

• Multilingual variables

• Multilingual blocks (control visibility per language and translate title and content)

• Language selection (when you switch the site language you'll see only the content for that language)

This module is used for the translation of the portal.

Views translation v. 7.x-3.x-dev

This module is used for translation of views strings and content selection for views.

On the portal, this module gives the possibility to translate the views action and controls.

(24)

Libraries v. 7.x-1.0

The common denominator for all Drupal modules/profiles/themes that integrate with external libraries.

This module introduces a common repository for libraries in

“sites/all/libraries” resp. “sites/<domain>/libraries” for contributed modules. It used to load/include libraries more easy.

Link v. 7.x-1.0

The link module can be count to the top 50 modules in Drupal installations and provides a standard custom content field for links. With this module links can be added easily to any content types and profiles and include advanced validating and different ways of storing internal or external links and URLs. It also supports additional link text title, site wide tokens for titles and title attributes, target attributes, css class attribution, static repeating values, input conversion, and many more.

This module is used by some content-type that require a link type field . Example: A resource.

Mail headers v.7.x-1.0

Control and modify any (almost any) mail header. Mail Headers allows you to:

• Limit the allowed domains for the sender e-mail address used on any e-mail sent through Drupal.

• Customize almost any mail header with the use of tokens (Version 2.x).

• Allow HTML to be sent from any module using drupal_mail. This module is used by Drupal when email messages are sent from the Portal.

Module filter v. 7.x-1.6

The modules list page can become quite big when dealing with a fairly large site or even just a development site meant for testing new and various modules being considered. What this module aims to accomplish is the ability to quickly find the module you are looking for without having to rely on the browsers search feature which more times than not shows you the module name in the 'Required by' or 'Depends on' sections of the various modules or even some other location on the page like a menu item.

(25)

When tabs are enabled via the Module Filter's settings page, a new module layout theme is implemented. This tab layout provides a tab for each package as well as a tab that will show every module alphabetically. The filter text field is available on each tab but currently doesn't support autocomplete.

On the portal this module is used for administration-purposes only.

Pathauto V.7.x-1.0

The Pathauto module automatically generates URL/path aliases for various kinds of content (nodes, taxonomy terms, users) without requiring the user to manually specify the path alias. This allows you to have URL aliases like /category/my-node-title instead of /node/123. The aliases are based upon a "pattern" system that uses tokens which the administrator can change.

This module is used in all content type and help a content editor to edit/change the alias of url.

Private messages v. 7.x-1.3

Privatemsg module allows your site's visitors to send private messages to each other.

This module is used in the “Private messages” section

Remember me v. 7.x-1.0

Adds a ''Remember me'' checkbox to login forms.

This module is used to remember a user login session at the user request,

Token v. 7.x-1.0

Tokens are small bits of text that can be placed into larger documents via simple placeholders, like %site-name or [user]. The Token module

provides a central API for modules to use these tokens, and expose their own token values.

Transliteration v. 7.x-3.0

Provides one-way string transliteration (romanization) and cleans file names during upload by replacing unwanted characters.

Generally spoken, it takes Unicode text and tries to represent it in US-ASCII characters (universally displayable, unaccented characters) by

(26)

attempting to transliterate the pronunciation expressed by the text in some other writing system to Roman letters.

This module is used internally by Drupal, not visible by users.

Variable v. 7.x-1.2

Variable module provides a registry for meta-data about Drupal variables and some extended Variable API and administration interface.

This module is not used directly but is needed by several modules (ex: Internationalization.)

Views v.7.x-3.3

Create customized lists and queries from your database.

This module is used on all the sections where a need to list records from database is encountered (Ex: Research result of the resources).

Voting API v. 7.x-2.9

VotingAPI helps developers who want to use a standardized API and schema for storing, retrieving, and tabulating votes for Drupal content.

This module is not used directly but is needed by the “ Fivestar” module in order to work correctly

Weight v.7.x-2.1

This module adds a weight option to enabled node types. Nodes with lower weight will float to the top of lists, while heavier items will sink. It uses the node table's 'sticky' column to store weights as well as sticky information (so that feature is not lost).

This module is used on all content types that need a certain order. Example: News content type

Wysiwyg v.7.x-2.1

This module allows using client-side editors to edit content. It simplifies the installation and integration of the editor of your choice. This module replaces all other editor integration modules. No other Drupal module is required.

Wysiwyg module is capable to support any kind of client-side editor. It can be a HTML-editor (a.k.a. WYSIWYG), a pseudo-editor (buttons to insert

(27)

markup into a text area), or even Flash-based applications. The editor library needs to be downloaded separately. Various editors are supported (see below).

Wysiwyg module also provides an abstraction layer for other Drupal modules to integrate with any editor. This means that other Drupal modules can expose content-editing functionality, regardless of which editor you have installed.

On the portal, this module is needed in the Administration panel, for a very large number of editing-sections, such as for example when you edit a text page and enter/change the content.

Browscap v.7.x-2.0

Browscap provides an improved version of PHP's get_browser() function. This module has a database with all models of mobile devices.

Based on this module, on the Portal we can identify a mobile device and redirect the user to the site specific version of that device.

Campaign Monitor

This module integrates the Campaign Monitor API into Drupal so you can give users the ability to subscribe and unsubscribe for your Campaign Monitor manage lists through a block on your Drupal site.

Security Kit

Module provides Drupal installation with various security hardening options. This lets your mitigate the risks of exploitation of different web application vulnerabilities.

6.3.2 Contrib libraries

Campaign monitor v. 2.5.2

Used by Campaign monitor module. Is the official wrapper provided by the Campaign monitor service

Ckeditor v.3.6.2

Is a wysiwyg editor , is used on all content types.

(28)

Used by Siv captcha to generate and check the security image code.

Tcpdf v.5.9.202

TCPDF is a PHP class for generating PDF files on-the-fly without requiring external extensions.

6.3.3 Custom Modules

ConsumerClassroom v. 7.x-1.0

This module implements almost all logical function and url calls need it by the system to work properly

User collection v. 7.x-1.0

Allow user to make collection of resource Handle :

• CRUD – Functions

• « Add to User collection » functions and hooks

Siv captcha v. 7.x-1.0

Is a simple module that implements captcha images (Ex. on Contact us page)

Share v. 7.x-1.0

Implements a share mechanism for Lessons, Inter school projects. Gives the possibility to share a certain node by link, email or social networks

Resources v. 7.x-1.0

Allows users to Add a resource, Interact with Lesson Builder module Handle :

(29)

Recent Activity v. 7.x-1.0

Is an observer that stores in the data base all actions made by users. It can be used for audit purposes whenever necessary.

My class v. 7.x-1.0

Allows an user to create classes with students and then send emails to the class. It also allows to Share lessons and inter school projects and interacts with Share, Inter School Project and lesson builder modules

Handle :

• CRUD – Functions for a class, students and notification board

Lesson builder v. 7.x-1.0

Allows an user to create lessons for students and more. Provides a control page with lesson published, draft and archived. Interact with Share, My Class and Resource modules

Handle :

• CRUD – Functions for a lesson,

• Download a lesson in pdf formats

• Print a lesson

Inter school Project v. 7.x-1.0

Allows a user to create an Inter school project. Provides a control page with personal projects or projects involved in and a board page of each project in a collaborative mode.

This module interacts with Share and My Class modules. Handle:

• CRUD – Functions for a Project,

• Manage users who are involved in the project

Inter school Project Competition v. 7.x-1.0

Allows a user to create an Inter school competition.

Provides a control page with personal projects or projects involved in and a board page of each project in a collaborative mode.

(30)

This module interacts with Share and My Class Handle:

• CRUD – Functions for a Project,

• Manages users who are involved in the project

6.4. Relationships between the packages and the modules

In order to present the relationships between the different packages and modules presented in previous chapters, we will detail their linking structure based on the main menus from ConsumerClassroom website.

- Resources menu is based on the modules: - Contrib: o Views  Chaos tools o Private messages - Custom o Resource  Views ( Contrib )

 CC Manager ( Custom module )

o User collection

 Views ( Contrib )

 Favorite ( Custom module ) - Drupal Core

- Forum menu is based on the modules:

o Contrib:

 Views

(31)

 Advanced Forum

• Forum ( Drupal core )

• Taxonomy ( Contrib )

• Options ( Drupal core )

• Field ( Drupal core )

• Field SQL storage ( Drupal core )

• Comment ( Drupal core )

• Text ( Drupal core )

• Chaos tools ( Contrib )

• Views ( Contrib )

o Drupal Core

- User Collections menu is based on the modules:

o Contrib:

 Views

 Star Rating

o Custom

 User collection

• CC Manager ( Custom module )

• Favorite ( Custom module )

o Drupal Core

(32)

o Contrib:

 Views

 Private messages

o Custom

 Interschool Projects

 InterSchool Competition

o Drupal Core

- Teacher's Directory menu is based on the modules:

o Contrib:

 Views

o Custom

 CC Manager

o Drupal Core

- Experts menu is based on the modules:

o Drupal Core

- My profile menu is based on the modules: o Contrib:

(33)

 Views

o Custom

 CC Users

• CC Tools

o Drupal Core

- My Calendar menu is based on the modules:

o Contrib:

 Views

 Calendar

• Date API ( Contrib )

• Date Views ( Contrib )

o Custom

 CC Manager

o Drupal Core

- My class menu is based on the modules: - Contrib:

o Views

 Chaos tools ( Contrib )

- Custom

(34)

CC_Software Architecture Document_V4.0 6-th August 2013  CC Manager o Share  CC Manager o Resource  Views ( Contrib )

o Interschool Projects

 Views ( Contrib )

 Favorite ( Custom module ) - Drupal Core

- My Lessons menu is based on the modules:

o Contrib:

 Views

o Custom  My Class • CC Manager  Share • CC Manager  Lesson_builder • CC Manager o Drupal Core

- My Collections menu is based on the modules:

(35)

 Views

 Star Rating

o Custom

 User collection

• Favorite ( Custom module

o Drupal Core

- My Favourites menu is based on the modules:

o Contrib:

 Views

 Star Rating

o Custom

 Favorite

 User collection

(36)

o Drupal Core

- My Posts menu is based on the modules:

o Contrib:

 Views

 Advanced Forum

• Forum ( Drupal core )

• Taxonomy ( Contrib )

• Options ( Drupal core )

• Comment ( Drupal core )

• Text ( Drupal core )

o Drupal Core

- My Blog menu is based on the modules:

o Contrib:

 Views

o Custom

 Siv Blog

o Drupal Core

(37)

o Contrib:

 Views

o Custom

 CC Images

• CC Tools ( Custom module )

• Lesson Builder ( Custom module )

o Drupal Core

- Advanced Lesson Builder menu is based on the modules:

o Contrib:

 Views

o Custom

 ALB

• My Class

• Share

o Drupal Core

6.5. Cache module used on ConsumerClassroom DRUPAL CMS

The DRUPAL CMS that is currently implemented for the Consumer Classroom website, uses a Cache mechanism in order to temporarily store most frequently accessed data and deliver it faster to another visitor/user of the website.

As such, each DRUPAL module manages the cache by its own. The DRUPAL cache system allows two main actions:

cache_get – which returns a serialized object from the Database cache_set – which sets a serialized object into the Database

(38)

The practical way in which an object is added into the cache is different from one module to another and from one use to another.

While adding an entity into the cache, the system will first identify its type and then serializes it. PHP allows the serialization of any type of entity and then returning it to its original status. For example, if an entity has been an object, after de-serialization the entity will become an instance or if the entity has been a HTML block, after de-serialization the HTML object may be reused.

By default, caching may be used for:

- Pages can be stored into cache. This is done for anonymous users (standard visitors) of the website and it just means that the HTML-generated pages are stored into the database

- Blocks can be stored into cache. This is done for both anonymous users, but also for logged-in users if the Pages cache is not activated.

The rest of the cache system is built by different contributor-modules, but the principle is the same.

Each cache element is stored in a binary format and is identified by an unique alphanumeric id so that it might be loaded at anytime. This id is defined by the software developer and if another one with the same id exists, it will override the previous one.

In order to reset the cache, there are two options:

- an expiration date may be setup-ed, which means that an automatic refresh is done after that time

- most of the times, the software developer will reset the values from cache when changing the values of a module that uses a cache or even reset the whole cache if necessary.

6.6. Data access layer and concurency checker

The Drupal 7 Database API provides a standard abstraction layer for accessing database servers. The API is designed to preserve the syntax and power of SQL as much as possible, but also:

- to support multiple database servers easily;

- to allow developers to leverage more complex functionality, such as transactions;

(39)

- to enforce security checks and other good practices;

- to provide modules with a clean interface for intercepting and modifying a site's queries.

The Database API was built with object-oriented design concepts, most common operations have a procedural front-end as well, and developers may choose to use the procedural style for a more readable code.

The Drupal database layer is built on top of the PHP's PDO library. PDO provides a unified, object-oriented API for accessing different databases but it does not provide an abstraction for the different dialects of SQL used by different databases.

Drivers

Because different databases require different sorts of interaction, the Drupal database layer requires a driver for each database type. A driver consists of a series of files located in includes/database/driver, where driver is a string representing the unique key for that driver. In most cases the driver key is the lowercased version of the database name, such as "mysql", "pgsql", or "mycustomdriver".

Each driver consists of several classes derived from parent classes in the core database system. These driver-specific classes may override whatever behavior is needed to properly support that database type. Driver-specific classes are always named for their parent class followed by an underscore followed by the driver name. For example, the MySQL specific version of InsertQuery is named InsertQuery_mysql.

Connections

A connection is an object of class DatabaseConnection, which inherits from the PDO class. Every database to which Drupal connects has a single connection object associated with it. That connection object must be subclassed for each individual driver.

Queries

A query is an SQL statement that will be sent to a database connection. There are six types of queries supported by the database system: Static, Dynamic, Insert, Update, Delete, and Merge. Some queries are written as SQL string templates (prepared statements) while others use object-oriented query builders. A "query object" refers to an instance of a query builder for one of the various query types.

(40)

Statements

A statement object is the result of a Select query. It will always be of type DatabaseStatement, or possibly a subclass of DatabaseStatement. DatabaseStatement extends the PDOStatement class.

Drupal uses prepared statements for all queries. A prepared statement is a template for a query into which values will be inserted for execution. Like of a prepared statement as the SQL equivalent of a function, which is then called with parameters to use.

In normal PDO, one must explicitly prepare a statement object and then execute it with certain values bound to placeholders in the query. The statement can then be iterated as a result set. Effectively a statement and a result set are synonymous, but only after a statement has been executed.

Drupal does not expose the prepared statement directly. Instead, a module developer will use a query object or a one-off SQL string to execute a query and the statement object for that query is returned. The terms "statement object" and "result set object" are therefore more or less synonymous.

PHP Data Objects (PDO)

The PHP Data Objects (PDO) extension defines a lightweight, consistent

interface for accessing databases in PHP. Each database driver that implements the PDO interface can expose database-specific features as regular extension functions.

PDO provides a data-access abstraction layer, which means that, regardless of which database you're using, you use the same functions to issue queries and fetch data. PDO does not provide a database abstraction; it doesn't rewrite SQL or emulate missing features.

7. PROCESS VIEW

For the Consumer Classroom website, the LAMP architecture is used. The LAMP platform consists of four components that are structured in a layered way. Each layer provides a critical part of the entire software stack:

Linux. Linux is the lowest-level layer and provides the operating system. Linux actually runs each of the other components..

Apache. The next layer is Apache, the Web server. Apache provides the mechanics for getting a Web page to a user. Apache is a stable, mission-critical-capable server, and it runs more than 65 percent of all Web sites on the Internet. The PHP component actually sits inside Apache, and you use Apache and PHP together to create the dynamic pages from the Consumer Classroom website.

(41)

MySQL. MySQL provides the data-storage side of the LAMP system. With MySQL, you have access to a very capable database suitable for running large and complex sites. Within the Web application, all the data, content, accounts, and other types of information will reside in this database in a format that can be easily queried with the SQL language.

PHP. PHP is a simple and efficient programming language that provides the glue for all the other parts of the LAMP system. PHP is used to write the dynamic content, capable of accessing the data in the MySQL database and some of the features that Linux provides.

The main reasons for using this architecture are:

1. Lower Cost of Ownership: Open source products typically not only have lower

license costs, but also significantly reduce the operational costs that make up the total cost of ownership.

2. Reliability and Performance: A large community of users try and test open

source software across a range of platforms before it is certified for production. When bugs are found, they are fixed quickly. Extensive public review as well as

(42)

rapid development iteration has made open source software more reliable than closed source software.

3. Security: Open source software is out there in the open, a large community of

users try it and pinpoint security issues. As a result, open source software is more secure and suffer fewer vulnerability attacks then proprietary software.

8. DEPLOYMENT VIEW 8.1. Hardware overview

The infrastructure supporting the website has been configured for maximum availability. It is a configuration that allows easy horizontal scalability if website usage and / or traffic to the website increases in the future.

System architectures can vary and can make the difference between available systems and those that constantly reach bottlenecks and have frequent downtimes and become unavailable. Based on the availability requirements presented in the tender, on the performance metrics and benchmarks available for Drupal, and last but not least on our experience with implementing similar solutions, we determined the current configuration as one that will manage to be up to the task and deliver necessary performance.

The entry point of the server configuration is a load balancer. Load balancers are hardware devices running special software designed for balancing traffic to website. The load balancer is connected to the application server.

At present two servers have been brought online to deal with the initial performance requirements. This setup allows for easy extensibility of the configuration allowing linear increase in concurrent user load support. As stated before, this setup allows for easy updates and upgrades to the software platform by taking each server offline for applying the new versions of the software while still keeping the website available to the users.

The availability and traffic usage of the servers are monitored using Munin and Webalizer software packages. Using this software the infrastructure health is regularly monitored and actions can be taken even proactively when possible slowdowns are noticed.

The web server is a single server and runs Linux and Apache and is connected to the database server. The database server is also a single instance and runs Linux and Mysql.

The current configuration represents a failover configuration. What this means is that should any of the hardware devices fail for some reason an identical hardware device can be brought online immediately and with minimal disruption to service.

8.2. Hardware architecture map

(43)

- A web server which hosts the Apache web server and the Drupal web framework;

- A database server which hosts a MySQL database;

- A backup server which stores backups of both the web site and the database

- The website CMS software (installed on the web server) is based on Drupal v7.14.

- The systemware is Linux and Apache based and deployed in a standard LAMP configuration. This LAMP configuration consists of:

• Operating System: Debian GNU/Linux release 6.0.6

• Server http: Apache/2.2.16 (Debian) PHP/5.3.3-7+squeeze14 with Suhosin-Patch mod_watch/4.3

• MySQL: Version 5.1.66-0+squeeze1-log

• PHP: Version 5.3.3-7+squeeze14

The hardware architecture and relations between the entities is presented in the next figure that represents the deployment:

(44)

9. IMPLEMENTATION VIEW

9.1 Overview

The Drupal architecture is based on layers. This create a fine granularity in the development of the features and also make it easy scalable.

9.2 Layers

(45)

1. At the base of the system are Entity types.

2. The next level is the data saved in the system. .Before anything can be displayed on site it must be imput as data.

3. The next layer up is where modules live. Modules are functional plugins that are either part of the Drupal core (they ship with Drupal) or they are contributed items that have been created by members of the Drupal community. Modules build on Drupal's core functionality, allowing to customize the data items (fields) on node types; programmatically sorting and display of content (custom output controlled by filters), etc. There are thousands of different options within the fast-growing repository of

contributed Drupal modules. They represent the innovation and collaborative effort of everyone from individuals to large corporations.

(46)

4. At the next layer, we find blocks and menus. Blocks often provide the output from a module or can be created to display whatever you want, and then can be placed in various spots in your template (theme) layout.

Blocks can be configured to output in various ways, as well as only showing on certain defined pages, or only for certain defined users. 5. Next are user permissions. This is where settings are configured to determine what different kinds of users are allowed to do and see.

Permissions are defined for various roles, and in turn, users are assigned to these roles in order to grant them the defined permissions.

6. On the top layer is the site theme (the "skin"). This is made up

predominantly of XHTML and CSS, with some PHP variables intermixed, so Drupal-generated content can go in the appropriate spots. Also

included with each theme is a set of functions that can be used to override standard functions in the modules in order to provide complete control over how the modules generate their markup at output time. Templates can also be assigned on-the-fly based on user permissions.

10. DATA VIEW

The Drupal instance uses MySQL database to store the content.

The basic Drupal unit is the 'node' - a single record or an entry in a table of the database. A page, a story, an article, a blog post, a photo, etc. are all examples of nodes. Nodes are entries in the so called Content Types. Content Types are the Drupal categorizations of information. A content type is a container for a specific category of information. Nodes stored in content types can be linked in one-to-many or many-to-many fashion. For example, a person may have authored several data sets, and a data set may have many contributors. Nodes contains are displayed using blocks.

The users main information are stored in the 'users'. The extended user information are stored in nodes.

This clearly is relational database design which can be directly inspected in the underlying MySQL database (RDBMS). And because it is a RDBMS, the data can be manipulated outside of Drupal via third party administrative applications or custom code. However, access through third party applications will not be used on this website.

(47)

The customized modules are described in the section 6.3.3 Custom Modules of this document and also their relation to other modules.

The current database structure has 385 entities (tables) at the time of writing this document. It is the way that Drupal works that for each type of content it will automatically create a table in the database. Also each change on a field structure will determine changes into the database structure. Nevertheless, the “core” tables of the Portal from the database are already presented into this document and the rest of them are “administrative” tables created/updated by Drupal built-in framework so that they are not “stable” tables that need a description.

(48)

11. SIZE AND PERFORMANCE

Refer to the Supplementary Specification document for solution performance details and benchmarks.

12. QUALITY

The extensibility of the Drupal is given by the Module Architecture.

A module is a bundle of PHP code and supporting files that use Drupal's APIs and architecture to integrate new functional components into the Drupal framework. Drupal's module mechanism is designed to provide a uniform method of extending Drupal's capabilities. The purpose of a module is to extend Drupal's capabilities. Before a module can be used, it must be enabled by a Drupal administrator.

Core Modules are some modules that are important - disabling them would disable Drupal essential operation - and provide features needed by a wide variety of systems. These two batches of modules, both of which are maintained by the Drupal development team, are collectively referred to as the Drupal Core Modules. These modules are included by default in the Drupal distribution. There is little to architecturally distinguish the Drupal Core Modules from any other module. They follow the same guidelines and use the same APIs.

Drupal proceeds through a series of steps when it handles a request from a user. For example, the Drupal core first bootstraps the application, defining critical variables and often-used functions. Next, it loads critical libraries, themes, and modules and so on. Finally, it returns this output to the user's browser. At predefined moments in this step-by-step process, Drupal executes hooks. In short, it means that Drupal examines some or all of the currently enabled modules, looking for functions that follow specific, predefined patterns. This process is similar to the "callback" method often used in event handling models. but it is more dynamic here.

A theme is a bundle of resources, including PHP templates, CSS, JavaScript, and images, that provides layout and style information for some or all of the Drupal content. Everyone can customize templates. It is usually written in the PHP template language and can specify the details of the HTML structure. Special PHP files can be written to override theme engine behaviours. Complex configurations of JavaScript and CSS files are supported as well. Even modules can be used to interact with the theme-ing system.

(49)

13. SOFTWARE CARTOGRAPHY AND BUSINESS FUNCTIONS MATRIX

The business functions of the Consumer Classroom website have been described in the Business Use Cases and Supplementary specifications documents.