The Fenixedu Project:: An Open-Source Academic Information Platform

Instituto Superior Tcnico
The FenixEdu
Project: an
Open-Source
Academic
Information
Platform
Copyright Instituto Superior Tcnico, March 2011
The FenixEdu Project:
an Open-Source Academic
Information Platform
Project Founder, Chief Architect
and Project Director (20022008)
Antnio Rito da Silva
Project Directors (20082011)
Fernando Mira da Silva, Carlos Ribeiro
Chief Architect
Joo Cachopo
Chief Developers
Joo Luz, Joo Mota, Lus Cruz
Software Developers
ngela Almeida, Anil Kassamali,
Artur Ventura, Cludio Gil, David Santos,
Diogo Simes, Fernanda Quitrio,
Gonalo Luiz, Hugo Querido, Ivo Brando,
Joo Antunes, Joo Figueiredo,
Joo Mota, Lus Cruz, Lus Egdio,
Manuel Pinto, Nadir Tarmahomed,
Nuno Ochoa, Paulo Abrantes,
Pedro Santos, Ricardo Rodrigues,
Ruben Carvalho, Shezad Anavarali,
Susana Fernandes, Tnia Pouso
Identity Management Subsystem
and e-ID Interoperability
Carlos Ribeiro, Daniel Almeida,
Fernando Mira da Silva, Jorge Matias,
Miguel Cabea
System Administrators
Bruno Fernandes, Cludio Martins,
Daniel Almeida, Filipe Almeida,
Jorge Matias, Jos Pereira,
Miguel Cabea, Paulo Andrade
User Support Team Lead
Jos Lus, Tnia Nunes
User Support
Alexandra Alves, Armando Almeida,
Carla Amado, Helder Leite, Jos Lus,
Rosa Barbosa
4
Web Designers
Bruno Monteiro, Carla Penedo,
Gustavo Pimenta, Joo Alfaiate
Grants
Artur Ventura, Bruno Santos,
Carlos Jacinto, Carlos Pereira,
Daniel Ribeiro, Diogo Figueiredo,
Francisco Paulo, Jaime Jorge,
Joo Marques, Joo Neves, Joo Pereira,
Lus Cruz, Lus Egdio, Nuno Diegues,
Pedro Amaral, Raquel Guimares,
Srgio Silva
External Cooperation
Gonalo Luiz, Joo Luz
Students
Amin Amirali, Ana Gouveia,
Andr Fernandes, Anil Kassamali,
Bruno Almeida, Carlos Pereira,
Catarina Simes, Ctia Martins,
Danilo Camargo, David Santos,
Fernanda Quitrio, Francisco Passos,
Francisco Paulo, Joana Mota, Joo Brito,
Joo Fialho, Joo Figueiredo, Joo Neves,
Joo S, Joo Simas, Joo Sitefane,
Leonor Almeida, Lus Cruz, Lus Egdio,
Manuel Pinto, Nadir Tarmahomed,
Nuno Anto, Nuno Barbosa, Nuno Correia,
Nuno Nunes, Nuno Ochoa,
Patrick Da Fonte, Paulo Abrantes,
Pedro Santos, Ricardo Lopes,
Ricardo Nortadas, Ricardo Oliveira,
Ricardo Rodrigues, Rita Carvalho,
Rita Ferreira, Rui Figueiredo, Sara Oliveira,
Sara Ribeiro, Srgio Montelobo,
Srgio Nunes, Srgio Patrcio,
Shezad Anavarali, Sofa Rodrigues,
Tnia Pouso, Telmo Frias,
Tiago Rodrigues, Ximena Gento
SOTIS Project Supervisor
Jos Lus Borbinha
SOTIS Developers
Miguel Coxo, Pedro Carloto, Pedro Santos
Contributions
Past and present
project staff
Text
Antnio Rito Silva, Artur Ventura, Carlos
Ribeiro, Fernando Mira da Silva, Joo
Cachopo, Lus Cruz, Susana Fernandes
Editor
Fernando Mira da Silva
Editorial Design
Tiago Machado
Infographics
Telma Baptista
The Fenix project started at Instituto
Superior Tcnico (IST), Lisbon, Portugal,
with the aim to develop an integrated
academic information system for higher
education. Today, that system is the
basis of all academic processes at IST,
from high-level scientifc and academic
management to daily communication
between students, teaching and
administrative staff. It provides a powerful
Content Management System (CMS),
Student Management System (SMS) and
Learning Management System (LMS),
control and archive of all academic
records, overall academic management
from degree design and approval to
room scheduling and many other related
academic tasks.
The Fenix project was developed using
an Object Oriented approach based
on a Rich Domain Model that attempts
to model all academic entities and
processes. The infrastructural level is
based on an innovative approach to
Software Transactional Memory (STM), in
order to enable large-scale concurrency
with minimal interlocking transactions.
5 The FenixEdu Project: an Open-Source Academic Information Platform
The platform is integrated with an
advanced identity management
subsystem, which provides single sign-on,
federation support, strong authentication
based on a national e-ID Card and
supports European e-ID interoperability.
The project was developed from scratch
adopting a Lesser General Public Licence
(LGPL). It is used today by several higher
education institutions, with maintenance
and support often being provided
by independent private companies.
This approach contributed to extend
technological support and increase the
long-term project sustainability.
Abstract
A
6
Contents Introduction
Project Overview
IST overview
Organization
The Fenix Strategy
IS Development Models
Integration of Business Goals
Fenix Features and Functionalities
Role based approach
Multi-language support
Course support
Academic management support
Administrative support
Scientifc support
Building and infrastructure management
Admissions and on-line application support
Website management
Other functionalities
Roles and associated functions
An Innovative Technological Approach
The original software architecture of Fenix
A software architecture for applications with a rich domain model
The Fenix Framework
The Bennu Framework
A visual representation of the Fenix domain model
Identity Management
Identifers
Global Perspective
LDAP
Kerberos
Single Sign-on
Portuguese National e-ID Card
European e-ID support
SAML 2.0 Federation Support
Project metrics
Code size and evolution
Development team size
Performance
Third party implementations
Conclusion
Discussion
Ongoing and future developments
References
8
8
10
13
14
14
15
18
18
21
22
23
24
25
26
26
27
27
28
36
37
38
39
40
42
44
44
45
46
46
47
47
49
49
50
50
52
52
52
54
54
55
56
1
1.1
1.2
1.3
2
2.1
2.2
3
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
4
4.1
4.2
4.3
4.4
4.5
5
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
6
6.1
6.2
6.3
6.4
7
7.1
7.2
8
The Fenix project
1
started in 2002 at IST,
Lisbon Portugal, with the aim to develop an
advanced academic information system for
Higher Education Institutions (HEI).
The system was designed from the start
to be fully web based, in order to provide
wide availability and easy user interaction,
independent of client software and
operating systems, while assuring the high
security standards, tight access control
and log action control required by a critical
information system.
Project Overview 1.1
The Fenix system is an integrated platform
that works at all levels of the academic
process. It implements a powerful Content
Management System (CMS), which can
be used at course, degree, department
or institution level, an advanced Student
Management System (SMS), a complete
Learning Management System (LMS) and
it also integrates all components required
by a standard academic management
platform.
This includes management and support
of all academic tasks, including on-line
student applications and admission
processes, on-line enrolment and
registration, evaluation and grade records,
degree planning, design and aproval, full
management of academic records (at
graduation and post-graduation level),
publication registration and archive of
grades and student curricula, room,
course and teacher scheduling and
distribution, fee and payment control,
quality control through on-line surveys
and many other tasks. At the course
level, the system provides an information
board and an easy to use CMS, planning
and scheduling tools, publication of class
summaries, publication of bibliographic
references, documents and exercises,
e-learning support and evaluation,
student management and communication
channels, RSS feeds, registration of the
number of attendents and many other
functionalities.
As stated before, the system also provides
full support to all academic back offce
and management, including the workfow
required by most processes. This
includes design, planning, and approval
of degrees and courses (including
contents, bibliography, structure and
planning), European Credit Transfer and
Accumulation System (ECTS) validation,
formal approval by the scientifc board
of courses, degrees and teaching staff,
issue of diplomas and certifcates, etc.
The platform also handles the publication
of thesis theme proposals, support for
applying for a thesis theme and supervisor
Introduction 1
Project Overview
IST overview
Organization
1
1 FenixEdu is the registered trademark of the Fenix project. For sake of simplicity, we will however keep
the simplifed designation Fenix Project through out the remainder of this document.
and academic tasks related with thesis
management and supervision. Moreover,
it integrates a complete curriculum
management platform for teaching and
research staff, enabling the assessment
of scientifc production at individual,
departmental and institutional level.
The current version of the system
encompasses a wide range of
functionalities related to almost every
component of the academic process.
The complexity of the business model
and of the underlying information system
poses signifcant challenges from a
software engineering perspective. As
such, the system is often used both
as a source of research problems
and as a testbed for validating new
research approaches that address
the development of highly complex
applications with rich domain models.
One result of this tight integration
between research and development was
the introduction of an innovative software
architecture for developing applications
with persistent and transactional rich
domain models. This new architecture
combines a Domain Specifc Language
(DSL) for implementing the structure
of the domain model with a Software
Transactional Memory (STM) to control
concurrent access to the applications
data. Both the DSL and the STM used in
this new architecture were designed and
developed from scratch to suit the needs
of the Fenix project. However, since they
are independent from the application layer,
they were already adopted by several
other applications in different contexts. In
this sense, the Fenix project turned out
to be one of those rare cases of software
systems that change the technological
environment surrounding them.
The Fenix academic platform is
integrated with an advanced identity
management subsystem, which provides
user authentication to all computer
and network services. The identity
management backend is powered by
Kerberos and Lightweight Directory
Access Protocol (LDAP), and provides
web single sign-on based on Yale Central
Authentication Service (CAS).
The identity management subsystem
also has full Security Assertion Markup
Language (SAML) 2.0 federation support
based on OpenSAML, which provides full
interoperability with standard SAML based
federations (namely Shibboleth based
federations).
This identity management subsystem also
supports strong authentication based
on the Portuguese National e-ID Card
(named Carto de Cidado or Citizen
Card) and, moreover, is fully integrated
with the European e-ID interoperability
subsystem, developed in the scope of the
European project STORK. Digital signature
of documents and actions is also possible
using the Portuguese National Identity
Card.
The overall system was developed
from scratch as an open source project
based on the LGPL, to offer a basis for
open contributions, free distribution,
free availability, and customization to
special requirements and needs at
different institutions. This distribution
model enabled several HEI to implement
the Fenix system with the support of
independent private companies and, at
the same time, to enlarge the technical
support of the platform, which does not
rely today only on internal IST resources,
given the wider implementation basis
and technical support. This strategy
also contributed to the long-term project
sustainability.
The Fenix logo is the iconic Portuguese
Galo de Barcelos (Barcelos rooster), an
old Portuguese symbol, representing
that truth always prevails. The Galo de
Barcelos legend describes how the
rooster interceded for a man to be hanged
for a crime he had not committed. The
Galo de Barcelos was chosen because
Fenix is a Portuguese project driven by the
belief that by doing good we will prevail.
The Fenix project code and
documentation is available at
https://fenix-ashes.ist.utl.pt/.
10
IST overview 1.2
As stated before, the Fenix project was
developed from scratch at IST. While
today the Fenix system is also deployed
at other institutions, IST remains both the
largest user base and the primary source
code contributor. As would be expected,
ISTs implementation is the only one that
makes full use of all platform features, as
most of them stem directly from internal
requirements.
IST is the largest school of engineering in
Portugal. It was founded in 1911 in the
city of Lisbon, with the aim of developing
top quality education and research in
the areas of engineering, science and
technology.
The mission of IST is to create and
disseminate knowledge and provide our
students the education and the knowledge
tools to improve, to change, and to shape
society through science, technology,
and entrepreneurship. We achieve
this by combining a top quality higher
education with Research, Development
and Innovation activities, according to the
highest international standards, immersing
our students, alumni, faculty and staff in
an exciting and global environment geared
towards solving the challenges of the XXIst
Century.
IST is a research-oriented school, home to
more than 6,000 undergraduate students
(BSc), 4,000 graduate students (MSc and
PhD) and around 1,100 faculty members
and researchers. IST is settled in two
campuses, one in central Lisbon and
another in Taguspark (a modern science
and technology complex, home to more
than 130 high-tech based companies,
located in the southwest coast of Lisbon).
Students can choose from a rich variety
of MSc and PhD programs offered at IST,
covering the classical engineering and
basic science felds as well as a number of
the emerging scientifc areas. A signifcant
number of international students
participate in ISTs Master and Doctoral
programs.
IST cooperates worldwide with some of
the best universities and Research and
Development (R&D) institutions, and is a
member of various European networks
of prestigious schools in Engineering,
Science and Technology, such as
CLUSTER, TIME, and CESAER, all
committed to provide technical education
at the highest international standards.
Currently, IST offers several master and
doctoral programs in collaboration with
international partners (including Erasmus
Mundus).
Being research a central activity at
IST, it spans several R&D units and
disciplines. Teaching and research are
closely connected. Research and external
consulting contribute to more than half of
the IST fnantial turnover.
Master and Doctoral students are regularly
involved in these research activities,
working together with IST faculty and
research staff, to face the challenges
posed by ambitious national and
international research projects. Figures 2A
and 2B summarizes main IST facts and
fgures.
Figure 1
Alameda Campus
Figure 2A
(next page)
IST facts and fgures
(July 2010)
FACTS & FIGURES A SNAPSHOT OF IST
Education
Graduate students per cycle
30%
10%
60%
10%
International
Students
14%
International
Students
10231
Students
PhD
1058
Students
28
PhD Programmes
110
PhD Thesis
Master
3319
Students
25
Master Programme
823
Master Dissertations
1rst
Cycle
1121
2nd
Cycle
824
3rd
Cycle
110
Employability
96%
Get a job within
6 months of
graduating
63%
Get a job
before
graduation
Bachelor
5854
Students
19
Courses
Research
Internationalization
M.Sc
Double
Degrees
2
5
Joint PhD
programs
MIT
CMU
UT Austin
EPFL
International
networks
CLUSTER
EIT-LIC InnoEnergy
TIME
CEASER
MAGALHES
ATHENS
Mobility
programmes
E
R
A
S
M
U
S
S
M
IL
E
B
R
A
S
IL
Traineeships
IAESTE
VULCAN
US
ERASMUS MUNDUS
(Msc, Phd) programmes
euSYSBIO
EMDC
IDS-FunMat
EU-Brazil StartUP
38
7
29
1186
1852
4538
PhD awards
Research centres and institutes
New patents applications
Associated laboratories
59%
Own resources
Funding
135M
Total funding
13
Organization 1.3
This document is structured as follows.
Chapter 2 presents the overall project
strategy and discusses the adopted
model and the in-house development
approach.
Chapter 3 describes the Fenix platform,
listing the overall system features and
model at a functional level.
Chapter 4 delves into the systems
software architecture, and provides a brief
overview of the innovative approach that
enabled us to simplify the development of
applications with a rich domain model.
Chapter 5 describes The identity
management subsystem, including
federation support, strong authentication
support and European e-ID compatibility.
Chapter 6 presents several project facts
and fgures.
Finally, chapter 7 concludes, discussing
the current state of the project, overall
features and on-going and foreseen
developments.
Figure 3
Taguspark Campus
Figure 2B
(previous page)
IST facts and fgures
(July 2010)
14
The design of the Fenix business strategy
took into account our previous experience
with the development of information
systems (IS) in the context of HEI.
IS Development Models 2.1
In terms of funding, we realised that HEI
funding is constantly changing and it is
heavily based on political decisions. In
terms of management, HEI management
boards change periodically.
In terms of technology, HEI information
systems are long living platforms which
very often become technologically
obsolete. In terms of human resources,
HEI have problems competing for the
best-qualifed human resources in the
market of software. Moreover, there is
usually a communication gap between
the HEI and external entities that it tries to
work with.
The approaches already taken for the
development of HEI IS do not provide a
complete solution to these problems:
Commercial off-the-shelf products are
usually not fexible enough to support the
differences each HEI has in regards to
its core processes. So they are usually
limited to standard resource management
(salaries, accounting, etc), which usually
depend on the accounting laws of the
country, and so thus less variation from
institution to institution. When they are
used in other contexts (for example a
LMS), usually the HEI has to change or
adapt its processes to conform to the
software.
Analysing the outsource approach reveals
two major problems. The frst is cost.
A dedicated application that covers all
needs of an institute with the size and
complexity of a medium sized HEI can
cost well above 2 Million Euros. But
the main problem with this approach is
that the rules and processes at the HEI
change very often, and are a priori very
diffcult to put on paper. In this case the
communication gap is evident and the
derived costs from constantly changing
the systems with new functionalities
increases the overall cost.
In-house Development is usually done by
technical HEI staff, in close connection
with management and academic offcers.
This technical staff usually has no research
or teaching functions besides some
introductory courses. When an inhouse
IS project starts, normally it begins as a
small project and it progressively grows
The Fenix Strategy 2
IS Development Models
Integration of Business Goals
2

in size and complexity as more and

more functionalities are integrated. The
technology to be used is chosen at the
start of the project and it often becomes
out-dated with time. The project grows as
the years pass.
Technical staff spend more and more
time providing user support and
code maintenance and have an ever-
increasing diffculty getting new modules
implemented. On the other hand, time
and fnancial constrains work against any
change in technology.
By analysing the different approaches we
concluded that the diffculties exposed
above occur due to a fundamental faw.
The problem is that these approaches
do not integrate the development with
the HEI core business. The development
and maintenance of HEI IS is usually
regarded as an extraneous process, albeit
necessary, to the HEI core business.
Integration of Business Goals 2.2

In order to counter balance the above
weaknesses, we decided to fully
integrate the Fenix project with the HEI
business goals: knowledge transmission,
knowledge creation and knowledge
application. The Fenix project became an
added value for each one of these goals:
Knowledge Transmission Fenix is used
as a pedagogical content and tool in
software engineering courses. In this way,
students can have access to a large scale
real world application instead of working
with toy problems;
Knowledge Creation Fenix is used as
a research artefact. Researchers use
the HEI IS as a case study and as a
demonstration of new techniques;
Knowledge Application Fenix is also
seen as a software application. The
HEI computing services play the role of
industry and establish a contract with
research staff for knowledge transfer.
As an outcome of this strategy, the
following results are achieved:
Flexibility Research results can show
how new techniques may be applied
to Fenix and the associated cost may
be assessed and evaluated. With this
approach, technological changes are
possible with less risk.
Sustainability BSc or MSc students
can develop new components for Fenix,
in the context of a thesis or a grant from
the institution, increasing its functionality
at a low cost. Moreover, since software
engineering students learn about Fenix
in their regular courses, the problem
that often stems from staff mobility is
mitigated, since knowledge about the
system is spread among a large number
of professionals.
Knowledge
Application
Knowledge
Transmission
Pedagogical
Content
Knowledge
Creation
Research
Artefact
Open-Source
Product
Local Operation
Market support
Academic
Testbed
Human
Resources
Availability
Keep product
competitiveness
Multi-site
implementation
Keep technology
up to date
Fenix
Project
Sustainability
To solve the remaining objectives, namely
adaptation, management change and
government change, we integrated the
project with the software development
market. This was achieved following an
open-source market approach.
The main goal of integrating with
the market was to motivate external
institutions to use the Fenix application.
These external organizations can be other
HEI or software companies providing
installation and confguration services.
Since Fenix is published as open-source,
the clear advantage to other HEI is to
obtain a system without licensing costs,
which is independent of a single software
company, and where business rules and
encoded knowledge is open to external
assessment. HEI may choose to internally
follow the same integration with HEI
strategy or to outsource installation and
confguration.
Software companies also beneft
according to an open-source business
model. For instance, they can reduce
the high costs associated with code
regeneration when the technology starts
to become obsolete. Moreover, these
software companies take advantage
of a large number of human resources
that have know-how on the system,
since a large number of former software
engineering students were trained in
the platform), therefore reducing internal
training and development costs.
The adaptation objective is accomplished
because when Fenix started to be used
by different HEI it evolved to become more
fexible and adaptable.
In terms of management change,
since Fenix is used by different HEI,
it will be more resilient to changes of
management decisions made by a single
HEI management board. Moreover, since
the open source model enables several
software companies providing Fenix
services to compete in the market, there
is an implicit cost control, reducing the
impact of fuctuations on government
funding.

Figure 4
(previous page)
Fenix strategy model.
18
As stated before, the implementation of
the Fenix system at IST integrates on
a single platform all academic activities
and related administrative support. In this
chapter we present a high level tour of the
system and an overview of the system at
the functional and operational levels.
As usual, in all HEI, the academic reality
is a continually ever-changing process,
due to changes in regulation, procedures
and new challenges of the academic
environment. The Fenix system refects
this reality and is continuously adapting to
new requirements and feature requests.
Given the dimension of the system, the
description contained in this chapter does
not attempt to provide a detailed view of
all system functionalities, but tries to offer
a systemic and structured view of the
main features at the operational level and
of the related academic processes.
Fenix Features
and Functionalities 3
Role based approach
Multi-language support
Course support
Academic management support
Administrative support
Scientifc support
Building and infrastructure management
Admissions and on-line application
support
Website management
Other functionalities
Roles and associated functions
Role based approach 3.1
Being a critical IS that keeps track of all
institutional academic records, security
plays a critical role at the core of the Fenix
system. At the infrastructural level, security
is handled using conventional approaches,
including authenticated access for
all management and confguration
tasks, authenticated access requiring
mandatory encryption by Secure Sockets
Layer (SSL), action logging, encrypted
backups, and tight control on operating
system access and management. At the
application level, security is handled by
an advanced Access Control List (ACL)
process, which implements a tight control
on data access.
At the operational level, this ACL process
translates to a role based approach.
Each operational role has a different set
of privileges regarding data access and
manipulation. Each authenticated user of
the Fenix system has one or more roles, in
the institution (see Figure 5).
When assigned to a user, each role grants
access to a different application portal,
where the user has access to different
types of information and process control.
Such roles include, for example, Student,
Teacher, Researcher, Degree Coordinator
or Space Manager. Each portal appears
as a different menu in the web application
(see Figure 6).

3
Figure 5
(next page)
Role based access
control model.
User x User y User z
Role 1 Role 2 Role 3 Role 4 Role 5
Functionality 2 Functionality

3
Functionality 4 Functionality

1
(...)
Access Control
Layer
(...)
Domain
20
All Fenix users have access to two basics
portals: the communication portal and
the personal portal. The communication
portal is the frst one and grants access to
the internal information board, as well as
to search queries over the user directory,
providing access to user identifcation,
location and contacts. The communication
portal also provides a basis for e-mail
communication at any institutional unit
Figure 6
Login screen. Each menu on the top of the screen maps a specifc user role in the scope of the institution and
provides access to a different set of data objects and management processes.
level (subject, course, department, or
institutional level). However, the role of
the user within the system imposes strict
restrictions on the available recipients (for
example, only higher level management
has access to institution wide e-mail
distribution, while regular teaching staff
may have access to e-mail distribution
at the subject and course level). The
personal portal provides access to a
users personal information, as well as
password management and the users
institutional web page management.
A non-exhaustive list of roles and
associated functions is summarized in
section 3.11.
Multi-language support 3.2
The fow of knowledge in a society
directly infuences its progress in all areas,
from its social-economic status to its
technological capability. Nowadays, the
success of higher education institutions
largely depends on their capability for
communicating at an international level.
The Fenix application infrastructure offers
fexible multi-language support that
potentially enables the simultaneous use
of multiple languages, both for application
features and user generated content.
Of course, the consistent maintenance
of content in several languages is not
practical, but users are encouraged to
provide content at least in Portuguese and
English (see fgure 8). Most Fenix features
and static content are available both in
Portuguese and English. However, as
stated before, the adopted model could
easily support more than two languages
simultaneously. The default language is
automatically selected by the locale (which
can be derived from the default language
set by the users web browser).
In spite of this multi-language support and
effort, some content and even some static
labels may lack English or Portuguese
translation. In these cases, the content or
feature is shown in the available language,
regardless of the locale, sometimes
providing a mixed and less consistent
result. This is a slight shortcoming of this
approach.
Fnix
PT
EN
...
Figure 7 (left)
Multilanguage support
Figure 8 (top)
CMS multilanguage support
22
Course support 3.3
Among the wide range of tools that
the Fenix application provides, there
are several tools for transmission of
knowledge from teachers to students.
Every single course is linked to a
dedicated site managed by the teaching
staff that includes:
News, information and announcements
regarding the course;
A powerful, easy to use, web based
content management system;
A forum which may be shared and used
by teaching staff and students;
A planning board and summary board;
Class schedule and timetable;
Evaluation schedules and grades;
On-line tests;
Curricular information.
One of the main benefts of this approach
is to enable users to have a standard
interface for accessing information on
all courses. While the teaching staff may
customize the course page creating
additional sections and content, most
of the basic structure remains invariant
between courses, enabling a consistent
user experience. This shortens the time
required to fnd information, since it is
organized very similarly for all courses.
Teachers can also import content from
sites of the same course in previous years,
providing a frst draft of the page at the
start of a new academic year, reducing the
time required to setup the course page
each year.
On-line test features can be used for
surveys, for self-evaluation and for
evaluation of students. Questions to be
used on on-line tests can be imported,
from fles formatted under the IMS
Question & Test Interoperability (QTI)
version 1.2 specifcations (IMS Global
Learning Consortium, Inc., 2002). There
are many available tools such as the IMS
Asset Designer, which support creation
of content in this format. One such tool,
named LEIA, was developed in IST to
generate variations of questions from a
single model question. QTI is one of the
bases considered in the development of
the Sharable Content Object Reference
Model (Model (Jesukiewicz, 2009)
standard for web-based e-learning.
Figure 9
Typical course page.
Figure 10
Creating an
on-line quiz.
Academic management support 3.4
Designing the course structure for each
degree is a complex process requiring the
participation of different members. While
such a structure is designed from scratch
only once in time, it is successively
redesigned every year for reasons that
include changes in scientifc knowledge,
technological development or regulatory
changes. All areas of degree design are
evaluated and monitored by the Fenix
application, providing an automatic check
that most regulatory conditions are verifed
(namely ECTS number, course pre-
conditions, distribution by scientifc groups
and areas, etc).
Once approved by the scientifc board,
the plan and structure of each degree is
automatically mapped into the academic
administrative back-offce. During
student enrolment, which happens at the
beginning of each term, each student
chooses on-line the courses that he/her
wants to attend. During this process, the
students choice is automatically validated
against his/hers degree curricular plan and
historical academic record.
Another driving force for changes in
the curricular structure of a course is
academic quality control provided by
feedback from students and faculty.
At the end of the term, students,
teachers, student representatives and
degree supervisors fll out on-line surveys
regarding several areas of the learning
process. The result of these surveys
is subject to a deep statistical analysis
and is correlated with other academic
information, such as student workload,
assessment results and attendance
levels. This analysis provides the schools
management and department executive
boards with relevant information that is
taken into account when reviewing or
adjusting academic courses, degrees,
class schedules and it is the main tool for
quality control of academic performance.
Figure 11
Degree plan interface
(partial view).
This entire process is fully monitored

and checked with the help of the Fenix
platform, including the analysis of class
overlap, room allocation, schedule
consistency, etc.
During the enrolment period,
administrative staff monitor the overall
process and check for issues that rise
such as:
classes that fll up, preventing more
students from enrolling in them;
un-submitted grades from the previous
term, preventing students from enrolling
in subsequent courses (due to pre-
conditions in enrolment rules or other
regulatory restrictions);
Once the term is under way, administrative
staff work on the examination period
that occurs near term end, allocating
classrooms, as well as meeting rooms and
event halls for one time activities, and also
scheduling classes and classrooms for the
next upcoming term. All these activities
are performed using the Fenix application.
The Fenix application also supports the
assignment of a tutor to each student.
If assigned, the tutor takes care of the
students enrolment process on his/her
behalf and he/she has access to some
interfaces to supervise the students
progress during the class period.
24
Administrative support 3.5
In our information age, one expects
to be able to do almost any activity
provided that an internet connection is
available. The Fenix user interface is fully
web based and, as would be expected,
it allows students to enrol in courses,
pick their class schedules, request
documentation and certifcates, access
course documentation and do many other
activities over the Internet. It is clear that
the availability of such services, twenty
four hours a day, seven days a week,
allow users to self organize their schedule,
reducing the time and energy required to
take care of administrative details.
Activity at IST is mostly structured in
two terms: winter term and spring term.
The winter term typically spans from
September to February, while the spring
term spans from March to July. Most
curricular units are lectured on a single
term each year. As in most HEI, each
term at IST starts with an enrolment
period, followed by a class period and an
examination period (see fgure 13).

Figure 12
Class schedule - room
view
IST
Life Cycle
Class
period
Exam
period
Enrolment
period
Figure 13
Typical HEI life-cycle.
Schedule preparation and classroom
allocation is a crucial activity that is
developed well before each enrolment
period begins.

Scientifc support 3.6
A common asset of any HEI is to have
a centralized database containing
the curriculum of both teachers and
researchers and an institutional repository.
The Fenix application provides each
teacher and researcher with a portal for
managing ones curriculum in a structured
way. Having this module fully integrated
with Fenix means that part of the curricular
information is automatically flled out with
data retrieved from the academic modules
and from the human resource database,
namely title and career evolution, lectured
classes, supervised students, participation
in evaluation committees and so-on.
Moreover, it enables each researcher
to record more specialized data, as
publications, participation in projects
and other information that cannot be
automatically retrieved from the basic
academic database.
This curricular module enables the
automatic evaluation of scientifc
production at global faculty level, and also
at all intermediate levels (Department,
Scientifc area, research group unit, and
so-on). This is a powerful tool that helps
a complete management, analysis and
evaluation of scientifc production.
Experience shows that keeping a
structured scientifc curriculum is a
laborious and time-consuming task.
Moreover, researchers often have to keep
their curriculum records updated in several
different platforms. Most researchers
would like to see a better integration
between these different platforms,
simplifying curriculum maintenance.
IST is currently developing a new module
that will be combined with the Fenix
platform (the SOTIS project) that will
integrate the curriculum management
platform with a repository database and
that will signifcantly ease the task of
curriculum maintenance. Since most
publications are already described in some
meta-format somewhere in the web, the
SOTIS system will actively harvest public
databases and other bibliographic sources
and it will attempt to identify bibliographic
entries that may have been authored by
registered Fenix users. Each time the
platform fnds a candidate bibliographic
entry, it is submitted to the corresponding
user, who just have to validate if he/she
authored or co-authored the publication.
In affrmative case, the bibliographic
information is automatically added to the
user curriculum and, when the content is
available, to the institutional repository.
This spin-off project is being developed
in cooperation with IST researchers who
are tackling several challenging issues,
such as:
how to extract meta-data from data
sources available in different formats;
how to cross-reference publication
authors with registered users based
on the short names often used in the
publications;
other complex issues related with meta-
data harvesting and processing.
Figure 14
SOTIS harvesting
model.
Collection
and processing
Contents
Metadata
Harvesting
External Sources
Validation
IST
Repository
26
Admissions and on-line
application support 3.8
To capture a greater number of students
and to boost student mobility, on-line
applications are another relevant feature
provided by the Fenix application. The
platform currently supports on-line
applications for most courses. In each
case, any potential student may apply
from anywhere in the world, by flling
out forms and uploading any required
documentation.
Building and infrastructure
management 3.7
Another feature provided by the Fenix
application is the space management
module. This module allows registration
of every space managed by the school,
including campuses, buildings and rooms.
Several attributes can be associated
with each space, such as area, capacity,
available multimedia equipment and
furniture and associated quality attributes.
Blueprints can be uploaded for each
campus and for each building level (see
Figure 15). Searching for spaces can be
achieved either by navigating through the
blueprints, or by submitting a search form.
When spaces are classrooms or meeting
rooms, scheduling and reservation is
provided by the system. Any user can
check room availability at anytime.
Figure 15
Example of the space
management interface.
One of the challenges in on-line
applications is how to validate a users
identity. Since the Fenix application is fully
integrated with national authentication
services, Portuguese citizens can identify
themselves providing strong authentication
using their National e-ID Card. Recent
developments include the extension of
this strong authentication method to an
international level, through the European
e-ID interoperability platform developed
in the scope of the pan-European project
STORK. This topic is discussed in more
detail in Chapter 5.
Website management 3.9
Since the Fenix application integrates a
powerful CMS system, the application
includes the required tools to easily create
websites that are fully integrated with
the core faculty database and provides a
high level of customization. This includes
support for creating menus, sections,
sub-sections, announcement pages,
and so forth. These websites are usually
Other functionalities 3.10
As a system that encodes all
organizational structure and user
information, Fenix includes several
auxiliary modules and add-ons that assist
administrative support and workfow
management for several processes
that are not provided by the existing
ERP platforms. This includes several
auxiliary tasks, as student residence
management, parking management, on-
line access to fnancial data of scientifc
and development projects, management
of institutional websites, research staff
evaluation, several supervision and
authorization activities related with the
management, scientifc and pedagogical
boards.
Another add-on module to the Fenix
system is the Bennu framework and
associated applications, also developed
at IST, briefy described in section 4.4.
While not strictly part of the academic
platform, it integrates the organizational
and user information of the Fenix platform,
and is currently the basis for several IST
workfow processes. This include the
management of several administrative
tasks, namely acquisition processes,
travel authorizations, administrative
staff evaluation, internal staff transfers,
document management, etc.
Figure 16
Typical CMS
management interface

associated to a generic faculty unit,
which can range from a full academic
department to a small research group.
Since users can be easily associated to
any of these units, such websites may
provide an automatic user directory
with contacts and personal information,
associated scientifc production and
related information, at unit level.

28
Main functions available:
student admission, enrolment and
management;
degree transfer;
management of tuition, insurance and
fees;
issue of documents and certifcates;
registration and validation of grades and
mark sheets;
production of academic reports on a year
and degree basis;
processing and validation of applications;
Confguration of access permission to
each offce personel by the academic
offce supervisor.
confguration and monitoring options of
the overall application.

curriculum access;
self update of employment, professional
and academic information for
dissemination purposes;
request of documents and certifcates;
search for alumni;
access to institutional news, events and
publications;
subscription of institutionale-mailing lists;
access to a personel homepage;
access to an e-mail account.
Main functions avilable:
monitoring of the application status;
personal information update;
upload of requested or optional
documentation.
Roles and associated functions 3.11
A non-exhaustive list of roles and
associated functions is depicted int the
following list.
Academic Administrative Offce
School staff who are in charge of student
registration, enrolment and academic
administrative processes.
Administrator
Technical staff that are in charge of the
Fenix application.
Alumni
Former students.
Candidate
Any potential student who applies to a
program or degree offered by the school.
On the left we have the role being
described and who it is attributted to.
On the right we have the functions
associated with each role.
access to news;
access to forums;
e-mail delivery;
fle sharing;
search for system users;
access to school directory and
organizational structure;
assignment of additional team members;
assignment of scientifc commission
members;
management of the degree website;
access to the degree plan and curriculum;
access to degree students curriculum;
management of degree applications;
access to quality control reports;
mail distribution to degree students and
teachers;
management of thesis themes, distribution
and control (if the degree includes a
thesis);
management of PhD processes (if the
degree pertains to a doctoral program).
Creation and management of a course
requires the following information:
name, level (1st cycle, 2nd cycle, etc) and
type;
scientifc area;
term and associated time span (dates, etc);
student workload;
ECTS credits;
objectives, program and evaluation
method;
bibliographic references.
The creation and management of a
full degree curriculum is based on the
defniton of curricular groups. Each
curricular group includes a set of
mandatory or optional courses.
For each course, the following information
must also be provided:
prerequisites for the course;
curricular year and term;
rules that students must verify to enroll in
the course.
Communication
Any user of the system.
Coordinator
Teaching and administrative staff who
are in charge of the supervision and
management of a degree.
Curriculum Manager
Staff members that manage and confgure
the curricular plan of each academic
degree.
30
e-mail communication to students;
assessment of student schedules;
access to quality control reports.
Main functions available
access to curricular course data;
manage teaching staff allocation and
workload;
access to class abstracts;
generation of reports related with degrees
and courses;
confguration of privileges regarding
degree coordination and scheduling;
management of department thesis;
management of the department website;
sending e-mails to department members,
coordinators, students and delegates;
sharing of fles and documents with
department members.
view the scientifc curriculum of
department members (teaching and
research staff);
access statistics of department courses;
manage teaching staff service and
schedule distribution;
coordination, evaluation and scheduling of
department courses and degrees;
view and manage the department forums;
send e-mail to department members;
share fles and documents with
department members.
access to own time cards (self);
access to time cards of supervised staff;
access to reports regarding payment of
tuition and fees;
student statistics for each academic year
and degree;
tools for supervision of class abstracts
and evaluation methods;
assignment of external supervisors;
management of applications to career
workshops.
Delegate
Students nominated by their peers and
have a liaison role between students and
the instituion. Delegates are distributed by
degree and academic year.
Department Administrative Offce
Administrative staff at academic
department level.
Department Member
Teaching staff who are in charge of the
academic department executive board.
Employee
This role is attributed to the instituion staff
who are neither teachers nor researchers.
Executive Board
The executive board is the institutions top
management unit. It is usually composed
by teaching staff and administrative
executive offcers.

management of contract information;
management of personal information of
grant recipients;
generation of reports and statistics.
user and password management;
photo ID management, supervision and
approval;
other operational tasks.
managemt of ID cards for students,
teachers, researchers and employees.
Special assistance to foreign students
during the enrollment process.
Management and supervision of the
number of users.
Management and confguration of access
to the car park.
Analysis of student weekly work load (by
degree, curricular year and/or course);
Supervision of course information and
curriculum;
e-mail distribution to all academic user
groups;
fle sharing with specifc user groups;
manage the election process of student
delegates;
supervision of course progression, reports
and evaluation methods;
supervision of quality control surveys;
Main fucntions available:
manage and update personal and contact
information;
change their password;
request access to the schools parking lot;
manage their institutional homepage;
Grant
Manager Administrative staff who
manage scholarships awarded to students
and researchers.
Help desk portal
Help desk staff.
ID Card Manager
Administrative staff who participate in the
issuing of institutional identifcation cards.
International Relation Offce
International liasion offce.
Library
Administrtaive staff in charge of school
libraries.
Parking Manager
Administrative staff who supervise the car
park.
Pedagogical Board
Teaching staff in charge of supervision
of pedagogical subjects and academic
quality control.
Person
Any valid user of the system.
32
Access to project fnantial data.
managing news and information in the
instituional site;
e-mail distribution to students, alumni,
teachers and researchers;
management of simple user surveys
related with public events;
access to a restricted set of student and
alumni information.
Main function:
acess to documents pending rectorate
processing.
registration of sicentifc and other
activities that make part of the offcial
user professional curriculum (including
publications, conferences, patents and
prizes;
e-mail distribution to reserachers of the
same research unit.
management and control of residence
registration and fees.
management of academic periods;
management of class schedules;
management of tests and exam dates;
room allocation for classes, evaluations
and other events.
Project Manager
Teaching and research staff who are
in charge of a scientifc or institutional
projects.
Public Relations Offce
Public relations staff.
Rectorate Administrative Support
Administrative staff of the rectorate.
Researcher
Teachers and researchers.
Residence Manager
Staff who manage student residences.
Resource Manager
This role is attributed to administrative staff
who support institutional schedules and
resources, including degree and course
schedules and room allocation.

Scientifc Board
Administrative staff of the schools
scientifc board.
supervision and management of course
information and degree curricula;
management of equivalence plans;
management of degree coordinators and
degree coordination teams;
supervision of student applications and
student transfers.
management of the 2nd and 3rd cycle
thesis processes;
management of teaching staff workload;
support of scientifc activities;
management of protocols established with
3rd party institutions;
e-mail distribution to all user groups;
fles and document sharing with specifc
user groups.
Registration of data related with buildings
and infrastrutcuture, including campus,
space geographic division and structure,
rooms, etc.
Registration of attributes of each space,
including area, capacity, available
multimedia devices and general
equipment.
Main functions available
generation of statistics and reports
regarding academic processes;
computation and management of ECTS
classifcation;
management of quality control surveys to
students and teaching staff;
alumni data statistical analysis.
Space Manager
Administrative staff in charge of
supervisition of buildings and related
infrastructure.
Statistic Offce
Administrative staff who are in charge of
overall statistics, reports and academic
quality control.
34
view his/her curriculum and status;
view his/her class schedule and
evaluation calendar;
view his/her tutor (should one have been
appointed);
view his/her delegate;
access administrative services, including
document and certifcate requests;
access course forums;
flling out inquires regarding academic
quality control;
vote for student representatives
(delegates);
subscribe to ad-hoc events and
workshops;
perform on-line tests;
access course excercises and projects;
manage his/her thesis (if it applies);
course enrollment;
select his/her class schedule;
exame enrollent.
manage his/her course;
manage his/her course webpage;
Student supervision;
access student grades;
request room reservation for non regular
classes;
manage thesis processes;
Student
All students.
Teacher
All teaching staff.

Tutorship
Administrative staff who support tutorship.
Website Manager
Users who manage an institutional
website hosted on Fenix CMS (does not
include regular course websites).
assignment of tutors to students;
evaluate performance of tutored students;
reports on students regarding overall
performance;
reports on tutors.
Website content structuring and
management.
36
The development of Fenix started in 2002
with a well-defned software architecture
that was based on the best practices
for web application development at that
time (Fowler, 2002; Singh, Stearns, &
Johnson, 2002; Alur, Malks, & Crupi,
2001). That software architecture was
the basis of the project infrastructure
during its frst years of rapid growth,
but proved to be inadequate as the
complexity of the application increased.
Thus, as the problems of the original
software architecture started to surface,
the Fenix team began the development
of a new software architecture that went
into production for the frst time in the
late summer of 2005. Since then, the
architecture was further developed and
evolved into a set of additional frameworks
that are independent of the Fenix web
application and that are, in fact, being
used in the development of several other
applications, proving the success of this
new approach.
This section presents a high-level
description of the newly developed
software architecture for Fenix,
emphasizing some of its innovative
aspects, which are still pioneering in the
area of web application development.
This presentation starts with a brief
overview of the original software
architecture of Fenix, which is still one
of the most common architectures for
web applications, and identify some of its
problems. Then, the key ideas underlying
the new software architecture of Fenix
are introduced. In sections 4.3 and 4.4,
we briefy describe two of the major
frameworks that emerged from the Fenix
project.
An Innovative
Technological Approach 4
The original software architecture of Fenix
A software architecture for applications
with a rich domain model
The Fenix Framework
The Bennu Framework
A visual representation of the Fenix
domain model
4
The original software
architecture of Fenix 4.1
Originally, Fenix was developed using the
typical 3-tiered software architecture for
web applications, where the three tiers
are a web browser, an application server,
and a relational database server. In this
architecture, a user interacts with the web
browser, which makes HTTP requests to
the application server (as a result of the
user actions) and renders the HTML page
that is returned by the application server.
The application server, on the other hand,
receives HTTP requests from the web
browser and is responsible for processing
those requests, typically by requesting
data from the database server, processing
that data according to the applications
business logic, and eventually writing
some data back into the database (if the
request involved changing some of the
applications data). In Fenix, the database
tier is supported by the MySQL relational
database management system, and the
application server is implemented using
the Java platform.
The architecture of web applications
evolved into this standard structure, where
the application server is separate from the
database server (effectively moving from a
2-tier architecture to a 3-tier architecture),
because it allows programmers to use
different technologies for two crucial
aspects of a web application: (1) the
implementation of the applications
business logic, and (2) the persistent
storage of the applications data.
Whereas managing persistent data that
may be accessed concurrently has
been the realm of relational database
management systems (RDBMS) for
decades, these systems often lack the
expressiveness of modern object-oriented
programming languages to implement the
complexities of an applications business
logic. Thus, the separation of these two
tiers seeks to combine the best of both
worlds: the database tier continues to do
what it does best to manage persistent
data , and the application tier is free to
implement all of the business logic using
whatever programming language fts best
its needs. This is of special relevance
when we are dealing with applications with
a rich domain model.
We say that an application has a rich
domain model when its domain is
composed of many different entity
types, often with subtle variations and
intricate relationships among them.
Moreover, besides having a complex
structure, such domains typically exhibit
complex behaviours that involve many
different entity types at the same time.
Given the scope and range of the Fenix
functionalities already summarized in
chapter 3, it should be clear by now that
Fenix fts well within this category: the
Fenix domain model currently consists of
more than 1200 different entity types with
more than 1700 bidirectional relationships
among them.
Developing such a complex domain model
poses serious development challenges,
and requires highly disciplined use of
the best software engineering practices
and design principles. This is where the
object-oriented design and programming
may make a difference, if properly used,
suggesting that the 3-tier architecture
described above is a good solution, so
that the applications domain may be
implemented in the application server
using a language such as Java.
Yet, implementing the applications domain
logic using an object-oriented model is
at odds with the relational nature of the
data stored in the database tier, because
it is not easy to map one model into the
other. To tackle this diffcult problem, it is
common practice to rely on an Object/
Relational Mapping (ORM) framework
that implements most of the heavy-lifting
needed to bridge the gap between the
two worlds. So did Fenix, which used the
Apache ObJectRelationalBridge

(OJB)
2
as an ORM, hidden behind a
layer implementing the Data Access
Object (DAO) design pattern (Alur,
Malks, & Crupi, 2001). With todays
technologies, the equivalent solution is
to use an implementation of the Java
Persistence API (JPA) specifcation to play
the role of ORM.
Still, regardless of which ORM
implementation is used, a key aspect
of this architecture, and one where the
new architecture of Fenix departs from
standard practice as we shall see, is that
all of the ACID (atomicity, consistency,
isolation, and durability) properties of the
applications transactions are ensured
by the database tier, rather than by the
application server. And in here lies one of
the problems of this architecture for an
application such as Fenix - an application
with a rich domain model.
To ensure that the database tier detects
conficting accesses to the applications
data, all of the data accessed by a
business operation must be directed to
the database by the application server.
The problem, however, is that being the
database a separate component from
the application server, such accesses
are expensive, because they incur into
remote calls and data marshalling.
When the data needed to process a
users request may be fetched from the
database in few requests, that is not
a big problem, because the latency of
the connection between the users web
browser and the application server is
typically much larger than the latency of
the connection between the application
server and the database server, thereby
hiding the cost of the round-trips to the
database. Unfortunately, for applications
with a rich domain model, such as Fenix,
it is not uncommon to have business
operations that involve fetching hundreds
to thousands, or even millions, of different
pieces of data from the database in a
sequential fashion.
2 See http://db.apache.org/ojb/.
38
A software architecture for applications
with a rich domain model 4.2
In late 2003 Fenix was starting to face
some of the problems described in
the previous section. Having a domain
model with close to 200 different entity
types and implementing more than 1000
different services of varying complexity,
some of the services were taking too long
because of the excessive round-trips to
the database. The need to solve those
performance problems led developers
to add more responsibilities to the data
access layer, by creating Data Access
Objects that implemented complex
SQL-like queries to the database tier.
This, however, resulted in poor use of the
object-oriented programming paradigm,
with little opportunity for reuse and with
the proliferation of duplicate code.
Moreover, the transactional semantics
provided by the persistence mechanisms
(including the database tier) were
not strong enough, resulting often in
the violation of the applications data
consistency. In fact, most RDBMS do not
provide strict serializability semantics to
their transactions, falling back to weaker
consistency guarantees such as snapshot
isolation or repeatable read isolation levels.
The new software architecture for Fenix
was designed to address both the
performance problems and the software
development problems that resulted
from its original, and still common today,
software architecture. The goals for
the new architecture were to facilitate
the development of a persistent, fully-
transactional, object-oriented rich domain
model, while at the same time improving
the applications performance.
The key, and pioneering, element of
the new architecture is the use of a
Software Transactional Memory (STM)
in the application server tier to ensure
the atomicity, consistency, and isolation
properties of transactions, without relying
on the database tier. Thus, in this new
architecture the database tier is used
to ensure only the durability property of
transactions.
STMs have been the subject of intense
research since 2003 (even though
they were proposed earlier), as an
alternative to lock-based mechanisms to
synchronize access to shared memory
in parallel programming. Using an STM,
programmers developing a concurrent
program for a shared-memory system
do not need to obtain locks to access a
shared object. Instead, they just have to
identify which operations are supposed
to run atomically, and the STM runtime
system ensures that the operations run
with the intended semantics, eventually by
aborting and restarting conficting atomic
operations that run concurrently.
Unlike relational databases, STMs typically
provide strict serializability semantics for
their transactions, but have no support
for durability. Moreover, STMs are usually
embedded in a programming language,
providing atomic actions at the language
level over the languages objects.
For the new architecture of Fenix,
we developed an STM for the Java
programming language the Java
Versioned Software Transactional Memory
(JVSTM) library
3
. This STM was the
frst multi-version STM, and was the frst
STM to be used in a real-world production
environment.
The design of JVSTM and of the new
architecture for Fenix was based on the
assumption that many web applications,
including Fenix, have a very high read/
write ratio, meaning that they do many
more operations that only read data than
operations that read and write data.
In such cases, the combined latency of
all the round-trips to the database may
add up to a long response time to a users
request, from many seconds to several
minutes.
In such cases, programmers have
to resort to one or more of several
approaches to get acceptable
performance for their applications, from
caching data on the application server
to carefully crafting complex queries
that fetch more data with each round-
trip to the database. These solutions,
however, either interfere with the semantic
properties of transactions, in the former
case, or make the development much
more complex, error-prone, and brittle,
in the latter case. Often, this leads to a
programming approach that precludes
the use of a natural object-oriented
programming model, thereby defeating
one of the purposes of the architecture in
the frst place.
3 Available at
http://web.ist.utl.pt/~joao.cachopo/jvstm/.
Since the development of the new
architecture, this has been confrmed
for Fenix, where only 2% to 4% of its
transactions write (Carvalho, Cachopo,
Rodrigues, & Rito-Silva, 2008).
Thus, using the JVSTM to ensure the
proper transactional properties of the
operations removes the need to access
the data from the database in the vast
majority of cases, provided that the data
is already in memory. Given the generous
amount of memory that is possible to
fnd in modern hardware, this assumption
proves to be easily satisfed for an
application with moderate memory needs,
such as Fenix, which has a database of
approximately 20 Gb. Note, however, that
this architecture does not need to have
all of the applications data in memory, as
in the more recent approaches based on
in-memory databases. It just performs
better if the data that it needs is already in
memory.
Whereas the use of an STM was a
key enabling technology in the new
architecture of Fenix, there are several
other aspects of the new architecture
that contribute to its success, such as
the use of a domain specifc language
to implement the structural aspects of a
rich domain model, or the mechanisms
supporting the development of modules of
a system. In the next sections, we briefy
introduce the Fenix Framework and the
Bennu Framework that embody some of
these new aspects.
Both of these frameworks were originally,
and more recently, extracted from the
Fenix code base to make them reusable
for other applications. Both have already
been used in several other projects, both
at IST and by other software development
teams implementing products for their
own companies.
The Fenix Framework 4.3
One of the major design goals
underlying the development of the
Fenix Framework
4
is that it should
provide a natural programming model for
programmers used to develop plain Java
programs without persistence.
Typically, a domain model is programmed
in Java by using Java classes to
implement the domain models entity
types. Relationships between entity types,
however, do not map that easily into Java
constructs. Instead, they are typically
implemented in each of the participating
entities classes, either as references to
other objects, or as collections of objects,
or both.
Moreover, classes corresponding to
a domain models entities have other
requirements that are not common to
classes implementing other types of
objects in the application. For instance,
their objects need to be persistent and are
typically shared among many concurrent
threads. So, these classes need to be
implemented specially, taking these
requirements in consideration.
Given the special nature and needs of the
domain model, in the Fenix Framework
the domain model is defned using a new
language that was specifcally created
to allow the defnition of the structural
aspects of a domain model. This language
is the Domain Modeling Language (DML),
which is a micro-language designed
specifcally to implement the structure
of a domain model; it has constructs
for specifying both entity types and
associations between entity types. A
domain model defned in the DML is then
compiled into the corresponding Java
classes that correctly implement that
domain model structure in such a way
that allows the programmer to further
defne the entities behaviours in plain Java
(Cachopo e Rito-Silva, 2006b).
The current version of the Fenix
Framework stores the applications
entities in a MySQL database, but does
so automatically and transparently to
the programmer, relying on the JVSTM
to ensure the correct strict serializability
semantics. Therefore, the database is
completely hidden from the programmer.
This has two outcomes: (1) the
programmer cannot control the mapping
of objects to the database, and (2) there
is no way to take advantage of database
facilities such as joins or aggregate
functions. In return, programmers may
use all of the normal object-oriented
programming coding patterns, and are
encouraged to do so.
The Fenix Framework is also an excellent
example of the Fenix strategy described
in chapter 2. First, because it is a result
of research work that was done in the
context of the Fenix project. Second,
because it is used in the ISTs degree
on Information Systems and Computer
Engineering as a tool that students use to
develop new applications. Third, because
it serves as a basis for further research
done by MSc and PhD students, as
well as by senior researchers on several
research projects.
4 The Fenix Framework is available at
https://fenix-ashes.ist.utl.pt/trac/fenix-framework.
40
The Bennu Framework 4.4
The FenixEdu application is ISTs
solution to model its academic business
processes. The success of this
implementation made the applications
source code to grow on average 138000
lines of code per year, since 2003. The
application has been developed as a
single module, having only a few borders
delimiting how objects interact in the
application. Albeit the applications domain
model is well defned, and domain entities
encapsulate well their responsibilities,
there are no barriers between domain
objects. Consequently, developers are
unencumbered when programming
domain object interactions. While this
strategy allows for rapid development,
it greatly increases the applications
overall complexity and is more prone to
programming errors.
With a well-established presence in faculty
academic processes, in mid 2008 the
Fenix development team began to focus
more attention on the support provided
to other administrative processes. This
requirement to develop functionalities in
new business processes, coupled with
the teams desire to contain complexity led
to the creation of the Bennu Framework,
which is worth referencing in this scope
since it can be seen as a byproduct and
outcome of the Fenix project.
Figure 17
(next page)
Bennu architecture
model and example of
modules.
When developers model a business
problem using modules, they are
establishing well defned boundaries
for how objects may interact with that
module. Besides reducing complexity, this
strategy also promotes reuse. With the
compartmentalization modules introduce,
code is much easier to manage and
refactor.
Using the Bennu Framework, a web-
application is simply a set of modules
joined together. Developers can limit their
view to the modules they are working
on. Multiple applications can be created
deploying different sets of modules. At IST
we currently have fve distinct Bennu-
based applications deployed, all of which
share some modules.
Out of the box, the Bennu framework is
a fully functioning web-application and it
provides modules with:
the concept of a user;
the concept of a group;
security features and access control flters;
a task scheduler and automation of task
execution;
transparent and consistent persistence
of data.
Not all modules have to provide business
logic. They can simply be used to provide
other modules with more abstractions,
to hide infrastructure not provided by the
Bennu framework. Such modules already
developed include:
e-mail communication support;
fle repository support module;
web-service communication module;
organizational structure module;
personal and contact information module;
geographic information module;
IST is currently working on the transfer
and decomposition of the Fenix
application into modules. However with
over 1200 domain classes and more than
1250000 lines of code, this is not an easy
task. Finding the appropriate boundaries
will take some time. But this effort will
be worth it as it will reduce maintenance
costs in the long run.
Simply put, the Bennu Framework
is an empty web-application, void of
business logic, containing all the technical
abstractions extracted from Fenix on
which business processes are developed.
Note that having this infrastructure
separate from the application also allows it
to be reused in other applications.
Another signifcant improvement
introduced by the Bennu Framework is
the concept of a module. Functionalities
are added to the Bennu Framework
with modules. A module is a coherent
set of domain entities, domain logic and
interfaces for manipulating that domain.
Mission Module
UI Component
Domain Module
Expenditure
Tracking Module
UI Component
Domain Module
Document
Manag. Module
UI Component
Domain Module
Web- Service
Module
REST Servlet
UI Component
Domain Module
Geographic
Module
Domain Module
Personal & Contact
Inform. Module
UI Component
Domain Module
Email Module
Domain Module
SMTP Adapter
Organizational
Module
UI Component
Domain Module
File Module
UI Component
Domain Model
File System Adapter
Bennu Framework
User
Interface
Data
Persistence
Security &
Acess Control
Task
Scheduler
42
A visual representation
of the Fenix domain model 4.5
The Fenix domain is a large complex
domain that includes several thousand
object classes. In order to develop a visual
representation of Fenix entities and their
relations, we used a design tool to data
mine gigantic graphs (see fgure 18).
In this representation, each dot (graph
node) is a class and each line (graph edge)
is a relation. Colors encode the relation
type. Pink lines represent inheritance, in
which one entity is the specialization of
another, while the remaining are a relation
between two entities (e.g. Person has
a Card, Student has a grade). The fnal
representation results from an optimization
algorithm which attempts to distribute nodes
and edges in such a way that graph nodes
fll the overall graphic area and graph edges
are minimized. Note that optimization usually
stops at a local minimum and, therefore, the
fnal representation is not unique.
This graph visually encodes some
interesting components of the faculty
structure. The colours are separation
of important parts of the system. For
example:
cyan: Person;
red: Teacher;
ligher green: Student;
orange: Accounting;
blue: Personnel Section;
darker green: PhD;
yellow: organizational structure.
The most important entity is Person. This
entity represents the concept of a person
with which the college has a relation
with, either being a student, teacher or
employee. This is at the heart of the graph
because it is the most connected entity
(see zoomed area in fgure 18).
Figure 18(next page)
The Fenix domain
model. The zoomed
area corresponds to the
area around the person
object class.
Project Fnix Domain Model

Relational graph of Instituto Superior Tcnico Academic Administration System Domain
Legend:
Entity
Relation
Inheritance
Person
student
teacher
accounting
personnelSection
assiduousness
phd
Project Fnix Domain Model
Relational graph of Instituto Superior TcnicoAcademic Administration SystemDomain
Legend:
Entity
Relation
Inheritance
Person
student
teacher
accounting
personnelSection
assiduousness
phd
44
As previously described, the Fenix
academic information system is
integrated with an advanced identity
management subsystem, which is
the basis of an Identity Provider (IdP)
service. This subsystem is the basis for
user authentication and management,
not only in the academic information
system, but also in all IST on-line services,
including all web based services, shell
login and desktop access, e-mail
services, WiFi wireless authentication,
Andrew Distributed File System (AFS)
access, Virtual Private Network (VPN)
and Voice over IP (VoIP) services. The
identity management subsystem is the
glue that links all these services together
and provides a coherent view of all IST
services.
Identifers 5.1
The defning characteristic of The identity
management system is the unique
identifer that every user of IST services
possesse. In order to access any
electronic IST service each user has an
identifer comprised of the three letters
ist and a sequential unique number, for
example ist10010.
An IST identifer never expires and is
never reused. It is decoupled from both
roles and credentials. The decoupling of
roles means that there is only one type
of identifer regardeless of the user i.e.
students, teachers, researchers, guest
researchers. The actual roles performed
by each user are stored in application
specifc storages.
The IST identifer is also decoupled from
authentication credentials. In fact, a user
may authenticate:
Using a password stored in the IST
system;
Using the Portuguese National e-ID Card;
Using a credential from a federated
system;
Using a federated European national
identity provider.
Identity Management 5
Identifers
Global Perspective
LDAP
Kerberos
Single Sign-on
Portuguese National e-ID Card
European e-ID support
SAML 2.0 Federation Support
5
Windows
Desktops
Web Applications
Email
CIFS
RT
Proxy
WiFi
VoIP
VPN
AFS,
Cluster
Radius
Active
Directory
Kerberos
CAS
SAML 2.0
Federation
National
ID card/
European
eID
LDAP
Global Perspective 5.2
Whenever a user wants to access an
electronic service he must provide his
IST identifer, and authenticate using one
of the authentication protocols available
at that service. Although most services
support some Single Sign On (SSO)
system, the supported systems differ from
service to service. The solution was to
develop a forest of SSO systems with trust
relationships among them, so to the end
user it looks like a Single Source Sign On
(SSSO) system.
Each trust relationship (fgure 19) maps
users credentials from one e-ID system to
another. However, not every e-ID system
has a trust relationship with every other
e-ID system. The LDAP and Kerberos
e-ID systems are at the core of most trust
relationships. Every other system either
has a direct trust relationship with one of
them or an indirect one (transitive trust).

Figure 19
Global perspective
of the identity
management system
46
LDAP 5.3
The OpenLDAP service (OpenLdap
Foundation, 2011) implements the
Lightweight Directory Access Protocol
(LDAP) (Zeilenga, 2006) and it is the
primary storage of user personal
information. Each user has a LDAP record
containing a set of attributes according to
9 different attribute schemas:
Core Schema
Cosine Schema
Nis Schema
InetPerson Schema
utlPerson Schema
istPerson Schema
Samba Schema
EduPerson Schema
Kerberos Schema
Each schema defnes a number of
attributes. Not all attributes are flled for
every user, but several attributes are
flled for most users. One of the core
attributes is the uid attribute. Each user
may have multiple uid attributes, in other
words, a user may be known by several
different identifers. However, one of them
must be the IST identifer (for example
ist10010). Other uids may represent
legacy identifers or identifers for special
applications. Besides uids, every other
personal information like full name, photo,
e-mail address, phone number, password
and home directory in the Distributed
Files System, etc. is stored and accessed
through LDAP.
Upon registration every user gets an
entry in the LDAP storage with all the
mandatory attributes. There are several
methods to register a new user. All but
two (see sections 5.6 and 5.7) require the
execution of a privileged operation by a
system administrator on the Fenix system,
which flls in the user attributes, generates
a temporary password and creates a
LDAP user register. Some of the attributes
may only be changed by the system
administrator, others may be updated by
the user himself through a web interface
provided by the Fenix system.
In order to prevent that one single
system, generating too many LDAP
queries, hinders the performance of every
other system dependent on LDAP, the
LDAP service is replicated by 6 different
mirrors, each one handling on average
50 queries per second. This way, if one of
the services is overloaded with requests
almost only the service generating the
excess of queries gets affected.
The LDAP protocol is used both to
query for attributes and to perform user
authentication. Some applications use
LDAP directly for authentication through
a SASL module (Simple Authentication
and Security Layer), but most use it
as backend storage for other identity
systems, e.g. Kerberos and RADIUS,
thus creating a sort of trust relationship
between them.
Kerberos 5.4
Kerberos (Neuman, 2002) is one of
the most well known Single Sign On
distributed authentication protocols. At
IST, Kerberos is used directly by many
different applications, like the AFS and the
computer cluster, and indirectly through
the Active Directory (AD) identity system,
the CAS and LDAP.
Kerberos uses the LDAP service
as storage for user authentication
information, and LDAP uses Kerberos
for authentication, thus creating a trust
relationship between them.

Single Sign-on 5.5
Although every user authenticates
within the global SSSO system with
the same credentials to access any
kind of application, they often need to
authenticate once for every application,
because The identity management
systems comprising the SSSO only share
authentication offine credentials, not on-
line credentials.
However, web applications like Fenix,
Bennu and several others share one SSO
system, the CAS (JASIG, 2011). With
CAS, users only have to login once to
access every kind of web application.
Whenever a user accesses a web
application, with CAS support, without
being previously authenticated, his
browser is redirected to a login service
where the authentication takes place.
After being successfully authenticated
the user is redirected back to the original
service together with an authentication
token. While valid this token may be used
on every web application linked with the
CAS service.
The classical CAS authentication method
is the basic user/password method over
an https secure channel. However at
IST (fgure 20) the user may also use a
Kerberos ticket, the Portuguese National
e-ID Card, or the European e-ID.
Portuguese National e-ID Card 5.6
Authentication with the National e-ID
Card or with another European e-ID is
fundamentally different from the other
authentication methods because the
credentials used are not stored in a central
storage; instead credentials are stored in
the card itself.
The National e-ID Card has a digital
certifcate signed by a National Authority
that can be used on an https client-
certifcation authentication. The card
requires the insertion of a PIN to use
the correspondent private secret key
to establish the secure authenticated
channel. Thus, whenever a user wishes
to login with his national card the https
protocol requests a client certifcate to
establish a secure session.
Upon choosing the certifcate in the card
the user is asked for a PIN and the https
protocol creates an authenticated https
connection between the users browser
and the identify service.
The national identity number performs the
link between the citizen using the card for
authentication and a user enrolled in the
system, which is present in both the cards
certifcate and in the user LDAP attributes.
After authentication using the National
e-ID Card, the IST e-ID system generates
a CAS token that may be used on any IST
web-application until it expires.
Authentication with the National e-ID
Card is especially suitable for enrolment
purposes and whenever its necessary to
recover a lost password.
Usually the enrolment process in
academic management systems is a
manual assisted process because the
user does not exist in the system. In most
systems the initial enrolment process
must be performed in the presence
of an administrative offcer, in order
to authenticate the user against their
personal ID documents. However, at
IST, the enrolment may be accomplished
automatically using the National e-ID
Card, provided that a list of authorized
national identifcation numbers is available.
The National e-ID Card provides a
strong authentication system that is
able to authenticate the citizen and link
it with a new user, through the national
identifcation number, without requiring the
physical presence of the user and third
party authentication.
A user that has lost his/her password
may also initiate the recovery process by
identifying him/herself using the strong
authentication provided by the National
e-ID Card.
48
Figure 21
Authentication page -
National ID Card
Figure 22
Authentication page -
European e-ID
Figure 20
The CAS login screen,
with 4 authentication
methods.
European e-ID support 5.7
The CAS service at IST also allows
authentication with National e-ID European
systems from 17 member states (fgure
23), through a specifc CAS plug-in
developed as part of the European Project
Stork (http://www.e-ID-stork.eu/).
The developed plug-in allows every citizen
from any of the 17 member states to
authenticate to IST CAS service using his/
her National e-ID Card or system. This
feature is already available to perform the
enrolment of Erasmus students prior to
their arrival to IST, greatly simplifying and
speeding up the overall process.
The European Stork project is also
about attribute sharing. Having a source
of certifed personal attributes greatly
simplifes any kind of user registration,
in particular in the scope of a student
enrolment process. In order to beneft
from that feature, IST has developed a
module to link the Fenix application with
the European e-ID infrastructure.
Given the critical nature of personal
attribute sharing, the developed
infrastructure takes special care with
privacy regulations of the participating
countries. In particular, no personal
attribute is recorded or transmitted cross-
borders without explicit consent from the
user and from his National e-ID system.
SAML 2.0 Federation Support 5.8
SAML is an open standard for exchanging
authentication and authorization data
between security domains. From an
authentication perspective, SAML
provides the same service as CAS but
between different administrative domains,
i.e. the identity provider and the service
using the identity service does not need to
belong to the same administrative domain.
The Fenix ID subsystem supports
SAML 2.0 federations. Most local web
applications at IST use just CAS for local
authentication, because they are offered
just for local IST users. However, there
are several national services provided
and managed by Fundao para o
Clculo Cientfco Nacional (FCCN), the
Portuguese National Research Network
(NREN), which are based on SAML
federated login. These web-applications
authenticate to a National Scientifc
Research Federation of Authentication and
Authorization Infrastructure (RCTSaai) of
which IST is a full member. All these NREN
services are fully supported by IST IdP.
The IST federation support service acts as
a proxy between the SAML 2.0 federation
and the SSSO service of IST, thus allowing
any person enrolled with IST the use of
federated web applications.
Figure 23
European e-ID
participating Member
States
14 Original Partners
12 in Reference Group
Enlargement: 3 Additional Members
50
Code size and evolution 6.1
Number of code lines: 1 194 573;
Number of classes: 8 382;
Number of functions: 1 360;
Number of different screen pages: 3 653.
The evolution of the number of code lines
since the start of the project is depicted in
fgure 24.
The evolution of the number of classes
and relations since the start of the project
is depicted in fgure 25.
Project metrics 6
Code size and evolution
Development team size
Performance
Third party implementations
6
This chapter presents a set of metrics
that contribute to the overall project
assessment.
Figure 24
(next page, top)
Evolution of the
number of code lines
between 2003 and
2011. Discontinuities
correspond to major
refactoring of the
source code.
Figure 25
(next page, bottom)
Evolution of the number
of domain classes,
relations and slots
between 2005 and
2011. Discontinuities
correspond to major
refactoring of the
source code.
0
500
1000
1500
2000
2500
3000
3500
4000
Classes
Slots
Relations
2005 2006 2007 2008 2009 2010 2011
0
200000
400000
600000
800000
1000000
1200000
1400000
jsp
java
java
jsp
Other
Cong. Files
Total Line Count
Conguration Files
Total Line Count
Other
2003 2004 2005 2006 2007 2008 2009 2010 2011
52
Development team size 6.2
As of 2011, the development team is
composed by:
Full time developers: 9;
Grants: 7;
Students: 1.
The evolution of the development team is
depicted in fgure 26. It clearly shows that
when the project started the permanent
staff were few and there was a large
contribution on behalf of students, by
means of thesis and projects. As the
project matured, the permanent staff
had to be increased in order to provide
maintenance and regular project support.
At the same time, as the complexity of the
project increased, selected student with
grants gradually replaced regular thesis
students.

Performance 6.3
Average daily number of transactions:
731 296/day;
Peak number of transactions
(during enrolment period): 3 785 121/day;
The number of transactions in 2010 is
represented in fgure 28. Note that there
is a ratio of 10 to 1 between the scales of
reads (left axis) and writes (right axis).
Third party implementations 6.4
Beyond IST, the Fenix platform was
deployed in seven higher education
institutions in Portugal. Deployment in
these institutions was developed by third
party independent software companies,
some of wich were created with the
participation of former IST development
staff.
Each Fenix implementation has different
maturity levels and, depending on the
institution, the number and type of
modules that were implemented. Besides
IST, major implementations of the project
are available at ISEG (Instituto Superior
de Economia e Gesto, http://www.iseg.
utl.pt/) and at ISCTE (Instituto Superior
de Cincias do Trabalho e da Empresa,
http://www.iscte.pt/).
At least three software companies
currently support installation and
development services of the Fenix
application.
Figure 26
(next page, top)
Development team
evolution.
Figure 28
(next page, bottom)
Number of transactions
in 2010.
Figure 27
(next page, center)
Evolution of the number
of methods and
functionalities.
2001/02 2002/03 2003/04 2004/05 2005/06 2006/07 2007/08 2008/09 2009/10 2010/11
0
5
10
15
20
25
30
Developer
Grants
Student
Total
Methods
Functions
0
1000
2000
3000
4000
5000
6000
2003 2004 2005 2006 2007 2008 2009 2010 2011
0
100000
200000
300000
400000
500000
600000
700000
800000
0
10000
20000
70000
80000
Reads
Writes
R
e
a
d
s
W
r
i
t
e
s
Jan. Feb. Mar. April May June July Aug. Sep. Oct. Nov. Dec.
30000
40000
50000
60000
54
Being an integrated system that models
and encodes all areas of academic
activity, the Fenix platform had a huge
impact on IST activity. From the improved
communication between students and
teachers to the optimization of several
areas of administrative support, the Fenix
project was the basis for a revolution and
renewal of several traditional procedures.
Discussion 7.1
Today, all academic information is
available in a structured way to students,
teachers, staff and management board,
enabling many instantaneous decisions
and actions to be taken from any place in
the world where an Internet connection
is available. Several procedures that
often took several days or even weeks to
accomplish can today be performed from
any where, at any time. Student enrolment
at the beginning of each term, that was
before a one week long procedure, is
now accomplished in about one hour,
providing students on-line with accurate
data regarding available classes and
schedules, optional courses and all related
information. The instantaneous availability
to students of all teaching material, class
summaries and other documentation
enables an optimization of the learning
process and a closer connection between
all actors of the academic process.
On-line access to schedules, evaluation
data and all administrative information
turned the information system into an
integral part of the academic management
process. Moreover, given the consistent
and integrated model of all entities and
academic processes, the Fenix platform
enables to easily assess the effect of many
administrative and academic decisions.
As stated before, quality control was
another area that was deeply improved
with the Fenix platform through systematic
on-line surveys. This tight quality control
and its correlation with grades, student
and teacher performance and class on-
line content, provide invaluable assistance
to the fast identifcation of troubled areas
and enable the continuous improvement
of the learning process.
Conclusion 7
Discussion
Ongoing and future developments
7
Ongoing and future developments 7.2
The continuous development of the Fenix
project poses several challenges. As
stated before, dealing with increased code
complexity and maintenance requirements
is one major issue in any software project.
The Fenix project is no exception. The
ever-increasing number of integrated
business cases, the complexity of the
underlying processes and the dynamic
of a modern research institution requires
daily new approaches and solutions.
In order to solve this trend between new
developments and existing complexity,
continuous technological innovation is
required. The Fenix project will attempt
to keep this trend, by combining new
requirements with the availability of
advanced research on information
systems at IST in order to generate
new technological solutions. The
combination of business requirements and
research offers the basis for innovation,
sustainability and the continuous
improvement of the project.
This project evolution raises not only
technological challenges on the software
engineering front, but it also requires
improving application usability and an
easier, more transparent user interface.
With the increased complexity of business
processes, user-friendly interfaces are a
key component of an effcient information
system. This goal requires both
technological innovation and advanced
user research techniques to achieve
improved user experience and system
effciency.
The improvement of the Fenix platform
is a permanent process. The list of
on-going and planned developments
is vast. A non exhaustive list includes
the generalization of support for digital
signatures, the automatic bibliographic
harvesting and repository provided by the
SOTIS project, full dematerialization of all
academic processes, improved workfow
management, generalization of document
management to all faculty areas,
integration with the national repository of
certifcates and diplomas, avoiding the
requirement to issue physical documents,
refactoring of older parts of the Fenix
code and the decomposition of the Fenix
application into modules.
Thanks to this ever-evolving process, the
Fenix application will be tomorrow a better
and renewed platform than it is today.
56
References
Alur, D., Malks, D., & Crupi, J. (2001).
Core J2EE Patterns: Best Practices and
Design Strategies. Prentice Hall PTR.
Cachopo, J. (2007). Development of Rich
Domain Models with Atomic Actions.
PhD Thesis, Instituto Superior Tcnico,
Technical University of Lisbon.
Cachopo, J., & Rito-Silva, A. (2006).
Versioned Boxes as the Basis for Memory
Transactions. Science of Computer
Programming , 63 (2), 172-185.
Cachopo, J., & Rito-Silva, A. (2006).
Combining software transactional memory
with a domain modeling language to
simplify web application development.
6th International Conference on Web
Engineering (pp. 297-304). ACM.
Carvalho, N., Cachopo, J., Rodrigues,
L., & Rito-Silva, A. (2008). Versioned
Transactional Shared Memory for
the FenixEDU Web Application. 2nd
Workshop on Dependable Distributed
Data Management. Glasgow: Springer.
Fowler, M. (2002). Patterns of Enterprise
Application Architecture. Addison Wesley.
IMS Global Learning Consortium,
Inc. . (2002). IMS Question & Test
Interoperability QTILite Specifcation. (I.
MS Global Learning Consortium, Ed.)
JASIG. (2011). Central Authentication
Service. Retrieved 3 2011, from www.
jasig.org: http://www.jasig.org/cas
Jesukiewicz, P. (2009). SCORM 2004, 4th
Edition (Advanced Distributed Learning
Initiative ed.).
Neuman, B. a. (2002). Kerberos: An
authentication service for computer
networks. Communications Magazine , 32
(9), 33--38.
OpenLdap Foundation. (2011). OpenLdap.
Retrieved 3 2011, from www.openldap.
org: http://www.openldap.org
Singh, I., Stearns, B., & Johnson, M.
(2002). Designing enterprise applications
with the J2EE platform (2nd Edition ed.).
Addison-Wesley Longman Publishing Co.,
Inc.
Zeilenga, K. et al (2006). Lightweight
Directory Access Protocol (LDAP):
Technical Specifcation Road Map. IETF.
Copyright Instituto Superior Tcnico, March 2011

The Fenixedu Project:: An Open-Source Academic Information Platform

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

The Fenixedu Project:: An Open-Source Academic Information Platform

Hochgeladen von

Copyright:

Verfügbare Formate

Instituto Superior Tcnico

in size and complexity as more and

Integration of Business Goals 2.2

This entire process is fully monitored

25 The FenixEdu Project: an Open-Source Academic Information Platform

31 The FenixEdu Project: an Open-Source Academic Information Platform

33 The FenixEdu Project: an Open-Source Academic Information Platform

35 The FenixEdu Project: an Open-Source Academic Information Platform

Project Fnix Domain Model

47 The FenixEdu Project: an Open-Source Academic Information Platform

Das könnte Ihnen auch gefallen