Content Management System (Dokument- og Sagsstyringssystem)

Transcription

1 Content Management System (Dokument- og Sagsstyringssystem) Magloire Segeya Kongens Lyngby 2010 IMM-B.Eng

2 Technical University of Denmark DTU Informatics Building 321,DK-2800 Kongens Lyngby,Denmark Phone , Fax

3 Annexes All supporting documents are located on the enclosed CD: A zip file with source code A pdf file of this report A SQL script for creating the database

4 Table of Contents 1 Introduction Background Project scope Analysis Introduction Use cases Domain model Design Users and roles Students and registrations Messages Bachelor thesis and Internships Ruby and Rails what is ruby What is Rails Why Ruby and Rails Implementation RESTful architecture Controllers Models Views How to ext the application Notifications File Sharing Test Conclusion References...35

5 1 Introduction This report has been written in a 12-week project at DTU informatics under the supervision of Mads Nyborg and Stig Høgh. During the project, I developed a web based application to facilitate administration of student internships and thesis projects. This report describes the choices I made while designing and implementing the appplication. The report focuses on analysis and design. This report is divided into four main Sections. In the analysis section, I describe the functional requirements using use cases and a domain model. The design section describes possible ways to construct the program and justifies the choices I made. The program was implemented using the Ruby programming language and the Ruby on Rails web framework; the section titled Ruby and Rails introduces those technologies and describes the reasons why I choosed them. In the implementation section, I describe the program using small pieces of code. 1.1 Background The current administration of internships and thesis projects is conducted using campunnet and e- mails. Since campusnet is not suitable, DTU Informatics wants a web application which is especially developed for the those tasks. The system would serve as the main communication system between students and the institute. 1.2 Project scope Because I had only 12 weeks to complete the project, I had to limit the scope of the project. In the 12 weeks, I had to analyse the requirements, to design the application and implement it. And I had to learn the ruby language and rails framework in parallel with working on the project, because I didn't have any prior experience with them. In the report, I use the names PK in place of internship coordinnator and PA in place of internship assistant, because they were used in the business cases document I got from DTU.

6 2 Analysis This paragraph describes the system from the users point of view. Use cases are used to describe the system and they were also used to identify the functional requirements. 2.1 Introduction The system should automate most of the work that was done manually by the students and the DTU staff who have to administer internships and thesis projects. For students, the system should guide them through the process from when they request to be registered to when they finish writing the bachelor thesis. The system should show them in an intuitive way, what step is required from them, what form they need to fill and so on. Without this information, the students will need to check the DTU study handbook from time to time, to make sure they are following the rules. For the staff who administer the system, PA and PK, the system should help them to easily find the information they need about a given student, an internship, see where students are in the process and so on. Doing all this work manually requires a lot of attention and could be a source for mistakes. The system should keep them up to date about what case need their attention. If for example, a student fills a registration form, PA should automatically see that there is a registration that needs to be processed. A common need for all users will be to get notified when some important event occurs. For example, when students have finished business case 20, they need to s the thesis abstract in a delay of three weeks. The system should remind them to do that. The business case document provided by IMM was used for inspiration, when writing the use cases. 2.2 Use cases The use cases will deal primarily with the two first business cases; business case 10 specifies how the students register in the system and business case 20 specifies how internship companies get approved by DTU. I will briefly describe other use cases related to bachelor thesis too. I have chosen to focus on these two business cases because they represent the general way in which most cases are handled. For most cases, the process is triggered by a student filling some form and submitting it. The second action will be, PA or PK receiving the form and approving or rejecting the request. For an eventual rejection, PA or PK will write a comment to justify the rejection. The student will either agree with the justification and waits until he meets the requirements; or he will disagree and reply to PA's or PK's comments asking them to review the request. This can result in a long serie of comment-reply between the student and PA/PK. In case of approval, the case will be closed and the student will move on to the next case. This scenario can be generalised for almost all cases with small modifications. The exception is the cases that don't require the participation of the student, like business case 30 which is about assigning a supervisor to a bachelor project. These business cases show too, some important requirements that are common to all business cases:

7 1. The need of communication between the people concerned by a case 2. The need for showing users the next action to take 3. Traceability 4. Notifying a user when an important event occur Focusing on these business cases will allow to design an appropriate architecture, that will make it easy to integrate the other business cases Use Case 1:Register in the system scope : The internship management system Level : user goal Primary actor : student Preconditions : Student is authenticated Success Guarantee : Registration is saved Main Success Scenario : 1. Student starts a new registration. 2. Student enters the required data. 3. System saves the data. 4. System updates the student's status 5. System notifies PA Alternative flows: a*. The system fails at any step. 1. System does not save any data 2. System informs the student that there was an error 3. continues to step 1 2a. Student omits some required data. 1. System asks the student to enter all required data. 2. continues with step Use case 2: Process registration. scope : The internship management system Level : user goal Primary actor : PA Preconditions : User is authenticated Success Guarantee : Registration is saved and user status is updated Main Success Scenario: 1. PA asks the system to show unprocessed registrations 2. System shows the list of registrations

8 3. PA chooses one registration from a list 4. System shows the data entered for the registration 5. PA approves the registration 6. System record the registration as approved 7. System sets the student's status to ready to start business case System notifies the student PA repeats steps 3-7 until done Extensions : 5a. Student does not meet the requirements 1. PA rejects the registration and enters a comment 2. System records the registration as rejected 3. System sets the student status as not ready for business case System notifies the student continues with step Use Case 3: Register internship scope : The internship management system Level : user goal Primary actor : Student Preconditions : User is authenticated, Business case 10 is completed and in case of datamatician Business case 25 is completed Success Guarantee : Registration is saved Main Success Scenerio : 1. Student start a new internship registration 2. System shows a form to fill 3. Student enters internship's information 4. Student enters company's information 5. Student enters supervisor's information 6. System saves the data 7. System informs the student that data was saved 8. System notifies PK Extensions : 6a. Incomplete information 1. System tells the student that there is missing information 2. Student enters the missing information continues with step Use Case 4 : Process internship scope : The internship management system Level : user goal Primary actor : PK Preconditions : User is authenticated

9 Success Guarantee : Registration is saved Main Success Scenario : 1. PK chooses to see unprocessed internship registrations 2. System shows the list 3. PK chooses a registration from the list 4. System shows internship data 5. PK approves the internship 6. System saves the internship 7. System records the company and supervisor if they are new in the system 8. System removes the internship from the list 9. System updates student's status to business case 20 completed 10. System notifies the student of his new status PK repeats steps 3-10 until done Extensions : 5a. The company can not be approved 1. PK rejects the internship 2. PK writes in a comment why the company can not be approved 3. System records the internship as rejected 4. System notifies the student back to step 3 5b. The supervisor does't have the required education 1. PK rejects the internship 2. PK writes why the supervisor can not be approved 3. System records the internship as rejected 4. System notifies the student back to step Use Case 5 : Edit internship scope : The internship management system Level : user goal Primary actor : Student Preconditions : User is authenticated, internship was rejected Success Guarantee : Registration is saved Main Success Scenario : 1. Student sees that his internship was rejected 2. Student reads the comment from PK 3. Student chooses to edit the information he submitted 4. Student enters the data 5. System notifies PK that an internship registration was re-submitted

10 2.2.6 Other Use Cases In this section, I will briefly describe other use cases that are not important from an architectural point of view, but are important for the way the system will be used. The list is not a complete list of all ways the system will be used. S a private message A user can s a message to another user. This message should only be seen by the receiver. The user can search the name of the user he wants to s a message to. On the user's page, there should be a link to a page, where he can enter the message. An alternative solution could be, to allow a user to s a message without navigating to the receiver's page. The ser should just click on s a message and the system will present him a list of people to choose from. From a usability point of view, this would be a better solution. S an internship message It should be possible for a student to s a message to all people who have access to his internship. The student could click on internship and choose s a message. See my messages If a user receives a message, he can click on messages and click on the message to read a list of messages. It should not be possible to delete messages for traceability reasons. See users PA or PK should be able to see a list of all users in the system, they should be able to sort and filter the list of users. For example, ask the system to show all the students, to see the students who are in internship, search students by name, DTU id etc... See companies For administration purposes, the system should be able to show a list of companies in the system, show a list of students placed in a given company and so on. 2.3 Domain model In this section, I will use the use cases from the last section to identify the domain objects the system will have to deal with. The domain objects in this case are not software objects but conceptual objects. The domain objects and the relationships between them are shown in the

11 domain model below: The important relations shown by the domain model are, that a user submits a registration, the user here is a student. The registration is associated with zero or many courses. In Business case 10, the user has to write which courses he needs to take in order to have the 150 ECTS required by DTU in order to start an internship. The registration can then be approved, or rejected. The rejection can happen many times. That's why there is a many multiplicity on the rejection side. Another central domain concept here is Internship; It's associated with a student, a company and a supervisor. The multiplicity on the company and supervisor side is *, because a company can have many student working as interns. And many students can be assigned one supervisor. One can argue that there should be a relation between company and company supervisors, but this is not really an important concept that our system needs to deal with. The only relation that matters is the relation between the company supervisor and the internship, because we will need to validate whether the supervisor has the necessary educational background to be a supervisor. We will also need his contact informations. The relation between internships,rejections and approvals is the same as the one between registrations,rejections and approvals. The Role represents whether users are students or DTU staff. This does not have anything to do with which role a given user has on a particular internship. The name user is used in place of person to distinguish the users of the system from the company supervisors who won't be using the system.

12 3 Design In this section, I will present the design decisions made to implement the system. I want to emphasize that I did the database and application design in parallel in an iterative way. In designing the database, I also considered the way the database structure will influence the interaction with the application program. If at some point, I find a way of fetching more data in a single database query, I would make the appropriate changes in the database. Also the fact that, I was learning the Ruby on Rails framework and reading about the best practices in designing rails applications while designing the application, every time I learned a better technique, I would refactor the designs accordingly. An example is the choice of primary keys. Rails requires all tables to have a primary key called id. This led me to make changes in some tables. Because of this, I will talk about both database design and object design in the same section. 3.1 Users and roles Each user will be associated with one role: student for students, PA for the internship assistant, PK for the internship coordinators and staff for bachelor thesis supervisors. One alternative was to have a separate table for roles and to link the two tables by a foreign-key. But having a table with only four rows didn't sound like a good idea for a performance point of view, because we will often need to join the 2 tables. Another alternative would be to model the users in a hierarchical structure using inheritance,as illustrated below: But I think that this would be bad object-oriented design because inheritance should model an IS A relationship;it 's not the case here. PK does not represent a kind of user, it's just a role that can be assigned to a user. The decision was to represent the role as an attribute in the users table. An enum type could be used to make sure that users will always have one of these four roles. 3.2 Students and registrations A student will be associated with only one registration (Business case 10). Even though students can s a registration request many times and be rejected, we will record the registration only once and use a rejections table and an approvals table to track students history in the system. We can then use a single attribute in the registrations table to record the registration's status. This decision was made because the only thing the system needs to remember is when and why the registration was rejected. The why is solved by associating a comment with each rejection. So when PA rejects a registration she will need to write why she did so. If the requirement was to remember the data submitted at every request, then we would need to

13 create a new registration for every request. As mentionned in the analysis part of this report, the flow request - processing the request rejection/approval can be generalised for the other business cases. And having rejections and approvals tables could be used with the other use cases. We can use a type attribute to distinguish different forms of rejections or approvals. We can even go a step further and combine rejections and approvals in one table let's say status. 3.3 Messages Messages are the primary mean of communication in the system. A user can s a massage to another user and this message will be only visible by the receiver of the message. One can also s a message related to an internship or a project and that message will be seen by all users in that particular project or internship. Messages can be modelled using inheritance. An abstract parent class Message will have common attributes like author,title,content,date and so on. The descants of the Message class will implement their specific operations. For example a ProjectMessage object will have a reference to a Project object it's related to. The idea is illustrated below. But as we know, inheritance is not natively supported by relational databases. There are three common design patterns for modelling a hierarchie of classes: - Single Table Inheritance All classes are saved in the same table. The table will have a particular column called type which distinguishes the different types of classes. An example is shown below. Id author_id title content receiver_id internship_id project_id type 1 1 Title 1 Content 1 2 Null Null PrivateMessage 2 1 Title 2 Content 2 Null Null 1 ProjectMessage 3 2 Title 3 Content 3 Null 1 Null InternshipMessage Each message will have null values for the attributes that its corresponding class does not have. In this example, a message of type PrivateMessage will have a receiver_id referencing the person the message is sent to, but the other types of messages will have a null value for this attribute

14 because they are not sent to a particular person. The second message is of type ProjectMessage and belongs to a project with id = 1. The project_id attribute is foreign-key referencing that project. The receiver_id and internship_id are null for this message. The third message is of type InternshipMessage and belongs to a internship with id = 1. For this message type the receiver_id and project_id will be null. This solution works fine if the different types objects are not very different. In the case of messages we have only two null values for each type of message which is fine. This is the solution I have choosen to use, because of simplicity. This won't work very well for a deeper hierarchie of classes, because we will have to add one column to the table for each class in the hierarchy. The other reason why I choosed this approach is that, the ORM (Object-relational Mapping) library used by the rails framework supports single table inheritance. It takes care of the low level details of instantiating the right objects and persisting messages with the right type. - Class Table Inheritance Each class in the hierarchie corresponds to one table in the database. In this case we will have four tables: one for the Message class, one for the InternshipMessage class, one for the PrivateMessage class and one for the ProjectMessage class. The messages table corresponding to the Message class will have all common attributes for all messages. And the tables corresponding to subclasses will only have columns corresponding to the non-common fields. messages table: Id author_id Title content 1 1 Title 1 Content Title 2 Content Title 3 Content 3 private_messages table: id internship_messages table: project_messages table: 1 2 id 2 1 id 3 1 receiver_id internship_id project_id As shown in the tables above, we have 3 messages of different types. The common attributes are stored in the messages table corresponding to the parent class. The problem that can arise is how to

15 link rows in the messages table, to the corresponding rows in the other tables. One solution is to use the same primary key for corresponding rows. As shown above the row with id=1 in messages table corresponds to the message with id = 1 in the private_messages table, message with id = 2 corresponds to the message with the same id in the internship_messages table. Another solution is to have different primary keys and use a foreign key that references the messages table. The problem with this pattern is that if you want a list of all messages, you will need to join all tables and this can cause a performance issue. In our application, we will probably need a list of recent messages and which internship the messages correspond to. - Concrete Table Inheritance Each concrete class in the hierarchy will correspond to a table. In the messages case, we will have three tables in the database; private_messages, internship_messages and project_messages tables. All tables will have the common columns like title,content. In addition to those common columns, each table will have its specific columns. For example the internship_messages will have internship_id column, the private_messages table will have a receiver column and so on. This pattern has the same disadvantages as the class table inheritance pattern. The advantage with concrete table inheritance is that, we don't need to do any join. Each table is self contained. If we need to show recent messages from all tables, we could use a union query.

16 3.4 Bachelor thesis and Internships Bachelor thesis are as important to the system as internships. They have some similar relations that could be modelled in the same way. For example the relation between internship and messages is the same for bachelor thesis. It is a one-to-many relation. A message belongs to only one thesis and one thesis can have many messages associated with it. What I mean here by a message belongs to a thesis is that, a message sent in the context of a thesis will be associated with that thesis, and will be seen by people who have access to that thesis. The relation between users and thesis on the other hand is different because two students write a thesis together and they can have one or many supervisors. So there is a many-to-many relations between users and thesis. The two relations can be combined in one table and we will use a role attribute to specify whether a user is a student or a supervisor on the thesis. This is illustrated in the diagram below. As shown in the diagram above, in the case of messages we will use single table inheritance, all type of messages will be saved in the same table. A foreign-key (thesis_id) can be used to reference the thesis table. The many-to-many relation between users is represented by the join-table thesis_users. Two foreign-keys, user_id and thesis_id, will be used to reference users and thesis respectively. The role attribute would take one value of either student or supervisor. We could use a compound key (user_id,thesis_id) as a primary-key but Rails requires the primary-key to be called id. We can fix this by using a unique index on (user_id,thesis_id). The relation between thesis and supervisors could also be thought of as a relation between students and supervisors. This is probably the natural way of thinking about this; In the natural language people say I have a supervisor and not my thesis is supervised by. The relation is shown in the diagram below :

17 But I prefer the first approach because I think that the central entity here is the thesis, and users have different roles. Let's suppose that we want to delete a thesis from our system; In the first approach where the thesis is associated with both supervisors and students, we will only need to delete the rows that reference the thesis in the join table (thesis_users). By using the ON DELETE CASCADE clause in mysql or something similar in another RDBMS, this can be done automatically. But in the second approach, where students are associated with thesis and students with supervisors, we will need to delete rows from two tables. 4 Ruby and Rails In this section, I will talk about how I implemented the part of the system that I have achieved to implement. I will start by a short introduction to the Ruby language and the Rails framework. I will sometimes compare Ruby to java in some examples. So I assume the readers of this report have some familiarity with the java language. I will also explain the motivations that led me to choose these technologies. 4.1 what is ruby Ruby is a dynamic object-oriented programming language with support for other programming paradigms like functional programming. In ruby, everything is an object; unlike languages like java which distinguish primitives from objects, in ruby, integers,chars or booleans are objects. So you can call methods directly on an number. 1.upto(5) do i print i, => output: The mathematical operations like addition and substraction are methods on numeric objects. print 1.+(2) => will print is just syntactic sugar for the +() method. You can call a method without parantheses, unlike other c-like languages where parantheses are required : print hello is equivalent to print( hello )

18 Methods are high order functions; you can pass a block of code to a function in a functional programming style.some examples with the array class : Return an array where each element of a is multiplied by 2: a = [1,2,3,4] b = a.map { x x*2} => b= [2,4,6,8] map() a block of code and binds the argument x to every element in the array in turn. add all the natural numbers below one tousand that are multiples of 3 or 5 (a problem from project Euler projecteuler.net) : a = (1..999).select { x x % 3 == 0 x % 5 == 0}.inject(0) { x,y x+y} => (1..999) generates an array containing all natural numbers between 1 and 999 select() selects from that array the multiples of 3 or 5.it uses a block of code for the selection. In many functional programming languages this function is called filter. Inject accumulates the result of applying the block of code to a initial value and all elements in the array in turn. We start with x = 0 and y = 3, because 3 is the first value in the array returned by select. For the next step we set x = 3+0, and y = 5 and so on. In most functional programming languages this function is called reduce. we can also return a block of code from a method: I define a lambda that takes two arguments and returns their product : times = lambda{ a,b a * b} we can now call the proc.curry method on our times object to create other methods: times_2 = times.curry.(2) times_2 is now a method that takes one argument and returns the product of that argument by 2. times_3 = times.curry.(3) times_3 takes one argument and returns the product of the argument and 3. Then we can use our methods like this: a = times_2.(5) # a has now the value 10 b = times_3.(5) # b has the value 15

19 The Ruby language supports Metaprogramming, which means that you can write code that generates code dynamically. This facility can reduce the size of a program, and increase programmer productivity. I will show how this is done in the rails framework. To continue with the example above, lets suppose that we want to create 10 methods, times_1,times_2,times_3...times_10, which takes one argument and multiplies that argument by respectively 1,2,3, We can dynamically generate those methods like this : Class TimesExample def self.create_times(n) define_method("times_#{n}")do val val * n 1.upto(10){ i create_times(i)} Then we can use our class like this: c = TimesExample.new print times_1(5) #=> 5 print times_2(5) #=> 10 print times_3(5) #=> 15 This is of course a simple example, but metaprogramming can be used to solve more complicated problems making programmers more productive. An example is a built-in Ruby method called attr_accessor(). The method takes a list of symbols (a ruby string is kind of string constant) and generates a private attribute, a setter and a getter method for the class where the method was called. Class Person attr_accessor(:name,: ) the three lines above allow us to call methods like print person1.name() or person1. =('hello@example.com'). The convention for setter methods in Ruby is to concatenate the variable name and the equal sign. If you want read-only attributes, you will use attr_reader(). This is equivalent to the following java class :

20 Class Person{ private String name; private String ; public void setname(string name) this.name = name; } public String getname() return name; } public void set (string ){ this. = ; } public String get (){ return ; } } 4.2 What is Rails Ruby on rails is an MVC (Model-View-Controller) web application framework. In the MVC pattern, the Model is responsible for the application state and business rules; the View is responsible for showing the data from the model. Controllers receive request from the user, interact with the model and decide wich view to display. The controller will typically pass the model to the view or will store it in a variable where the view can access it. The diagram below shows this interaction between the three components: Browser 1 controller View Model Database 1. The browser ss a request to our application 2. The controller interacts with the model to find the data that will be sent back to the browser. The model might fetch data from the database.

21 3. The controller invoke the view; the view might fetch the data from a model object. 4. The View formats the response and ss it back to the browser (or any other client). In Rails, the main idea of MVC is the same but Rails introduces other components in the process. The request from the browser will be sent to a component called Routing; its job is to parse the url and extract from the url which controller to call. This process is shown in the diagram below : 1 Routing Browser userscontroller controller 3 View Show.html.erb ActiveRecord Model Database 1. Routing receives a request for this url : localhost/users/1/show. Routing saves in a hash table called params the value 1from the url, with the key user_id. (params['user_id'] = 1) 2. From this url, Routing knows that will invoke the controller userscontroller and it will call the show() from that controller. 3. In the show method, the controller will instatiate a model object called User. The model object inherits from ActiveRecord::Base (class Base in the ActiveRecord module). 4. We use a stitic finder method from User class to fetch the record corresponding to id = 1 from the users = User.find(1). An instance variable in ruby must start with a dollar sign.the find method will generate this sql statement: select * from users where users.id=1, create a User object from the record set and store it in variable. 5. When the show() in the controller returns, the controller passes control to the template file views/users/show.html.erb. Any instance variable sat in the controller will be accessible in the view. So the view can retrieve the model data stored in variable to s a response to the client. The main philosophy of rails is favouring convention over configuration. It means that, by following some naming conventions and other conventions like the directory structure, the rails framework will dispatch requests to the appropriate objects and methods, without requiring the programmer to edit any configuration file. In contrast to technologies like java servlets where the programmer needs to edit a deployment descriptor (web.xml) to map URLs to actions, in rails the programmer needs only to place class files in specific directories and to name URLs, methods and template files in some conventional way and the framework will know which action to invoke, what template to show and even whether to format the response in html,xml,json (javascript object notation) or as an rss feed.

22 If our application is called demo, the convention will be to structure the application files as follows: demo users_controller.rb app class UsersController <ApplicationController def = User.find(1) controllers... models user.rb views class User < ActiveRecord::Base users Show.html.erb public lib vor helpers rails <tr> <td>name</td> %></td> </tr> users_helper.rb Module UsersHelper def menu(user) The top directory is the name of the application, demo in this example case. app : that is where the application lives models : that is where models live. Models ext ActiveRecord::Base from which they inherit static methods like find() and many instance methods like save().business rules, validations are taken care of by models. The naming convention is, if the class is called User, it will be stored in a file called user.rb controllers : that is where the controller files will be stored. There is one-to-one relation between controllers and models. So we will have a UsersController class for the User model. The naming convention for controllers is, for a model class called User, the controller will be called UsersController and will be stored in a file called users_controller.rb. Views : for each controller we will have a corresponding directory in the views directory. And for each public method in the controller, we will have a corresponding view file. The naming convention is, for the UsersController, we will have a view directory called users, and for the show() method in the UsersController, we will have a show.html.erb file. Helpers : For each controller, we will have a helper module. This module will contain all functions that can be shared between many action in the controller or the view. I have a method called menu(user),i use to generate the links. Rails encourages a practice called DRY (Don't repeat yourself). This principle says that Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The advantage is that

23 if we want to add a link in the menu, we will need to change only one method. This principle was proposed by Andy Hunt and Dave Thomas in the book The progmatic programmer. public : This is the only directory accessible to the outside world. All public files will be stored her. This include javascript, css and image files. Lib : external libraries will be stored her. Vor : this is where the rails directory containing the framework libraries is stored. 4.3 Why Ruby and Rails The requirements for building this application was to use the.net or java platform. The technologies I am most confident with are Linux-Apache-Mysql-PHP commonly called the LAMPstack, but a php web application can not be deployed on those platforms. I have some experience with ASP.NET and Servlet/Jsp but I think that they are too complicated for simple applications. I looked at many java and.net based web frameworks like ASP.NET MVC, Apache Wicket, Groovy and Grails. I ed up choosing rails because it provides the best tools to implement this application. 1. Database access is taken care by ActiveRecord, the Object-Relational Mapping library shipped with rails. The programmer can retrieve and save records from the database without writing any sql code. ActiveRecord provides even advanced features like validations and transaction. And it does this in RDBMS-indepant manner. I have developped the application using the mysql database, but it can be deployed on another RDBMS just by changing a few lines in the database configuration file (config/database.yaml). 2. Versioning of the database schema. As many developers have experienced, when using a version control system like svn or Git, it is some times difficult to keep the database schema synchronised with the application code. Because many people use a graprical tool when they want to add a column or a table in the database, and when they commit code in the repository, the database change does not get committed. Rails solves this problem by using migration files to make changes in the database. This is the migration file used to create the first version of the users table : File name: _create_users.rb class CreateUsers < ActiveRecord::Migration def self.up create_table :users do t t.string :dtu_id t.string :name t.string :password t.string :role t.timestamps def self.down drop_table :users

24 to add a status column in the users table, I use this migration _add_status_column.rb class AddStatusColumn < ActiveRecord::Migration def self.up add_column :users, :status, :string def self.down remove_column :users, :status The name of the migration file starts with the the date+time where this migration were run;this is used as the migration version. Each migration has a up() to manipulate the database and a down() to restore the table in previous version. To restore the database to a specific version, you run this command on the command line: rake db:migrate VERSION= Rails can be deployed on the.net and Java platforms. The Ruby language has been implemented on those platforms under the names Jruby for the JVM and IronRuby for the.net platform. This requires that the application does not use any extension library implemented in C. The Netbeans IDE comes even with a tool called Warbler that can package a rails application into a.war file that can be deployed on any servlet container like Tomcat. 4. The requirements for this application include features like file sharing. File processing librairies in Ruby are much easier to use than those provided by java. 5 Implementation The system was implemented using RESTful-like architecure. I will start this section by describing how I followed the rails practices for implementing a RESTful application, and then I will describe how responsabilities were assigned to controllers and models. Finally, I will briefly talk about the views. 5.1 RESTful architecture The recommed way of building rails applications is following a RESTful approach. REST means Representational State Transfer. The ideas behind REST can be read in chapeter 5.2 of Roy Fielding's Phd thesis on

25 In summary, the application implements a way of manipulating a set of resources kept on the server. The resources are identified by well known resource identifiers,in the case of a web application identifiers are URLs. To manipulate these resources, clients use HTTP methods. The GET method is used to list the resources identified by a given URL, POST is used to create a new resource, PUT is used to modify or edit a existing resource and DELETE is used to destroy a resource. If we want to add a user, we s a POST request to /users, the same URL we used to retrieve a list of users. Resources can also be nested; in our application private messages can be associated with a user. To retrieve the list of private messages associated with user 1, we use the URL users/1/private_messages. The nested resources are manipulated using the same HTTP methods. In the case of our system, the model objects are treated as resources and are identified by urls. In the example of users, we have to different resources; an individual user and a collection of users. The collection of all users is identified by the URL /users. You can s a GET request to retrieve this resource. The user identified by id 1 is identified by the URL users/1. If we want to retrieve that user, we s a GET request; if we want to delete the user we s a DELETE request; and we s a PUT request to edit that user. The URL will be the same, the only thing that changes is the HTTP method used. All strong entities in the database are treated as REST resources, and weak entities are modelled as nested resources. For example registrations in business case 10 are resources and rejections are nested resources. In Rails, you specify the models you want to be treated as resources like this: ActionController::Routing::Routes.draw() do map map.resources(:registrations,:has_many => :rejections) map.resources(:internships) The resources are specified in config/routes.rb file; The method map.resources() is used to specify the resources. The second parameter is a hash of options. :has_many => :rejections tells Rails and particulary the Routing module that registrations are resources and a registration has nested resources called rejections. This will make URLs such as registrations/, registrations/1, registrations/1/rejections... recognizable and routed to the right controller. The convention is to that, even though we can s POST,GET,DELETE and PUT requests to the same URL, we need to have one method in the controller for each HTTP method. For example,with map.resources(:internships), requests will be routed as follows : GET /internships to InternshipsController, method index() GET /internships/1 to InternshipsController, method show() POST /internships to InternshipsController, method create() PUT /internships to InternshipsController, method update() DELETE /internships/1 to InternshipsController, method destroy()

26 5.2 Controllers To assign responsabilities to different classes, I have tried to follow the GRASP principles (General Responsability Assignment Software Principles), proposed by Graig Larman in his book Applying Uml and Patterns:An introduction to object-oriented analysis and design and iterative development. These principles provide guidelines on how to assign responsabilities to objects in order to make software systems that are easier to maintain and ext. The architecture imposed by Rails helps to maintain some of the principles like high cohesion and low coupling. By specifying what methods should do, communicating with the database, rails ensures that models are high focused and have well known and understood responsabilities. This is high cohesion. High cohesion introduces low coupling too, or low depency between classes, because a modification in the database won't affect the controllers for example. All controllers ext the the ApplicationController class, which in turn exts ActionController::Base, the base controller class provided by rails. ActionController::Base ApplicationController UsersController MessagesController InternshipsController The application controller implements the logic that needs to run in many actions across controllers. For example authentication is placed in this class. ActionController::Base implements a event mechanism, that allows the developer to write methods which will be called when specific events events occur. For example, we want to authenticate users before running any action. We can do this using a method called before_filter(); and because all controllers inherit from the same controller this action will be performed before processing any request. class ApplicationController < ActionController::Base before_filter( :current_user, :except =>:login) def authenticate() unless User.find_by_id(session[:user_id]) flash[:notice]='please log in' redirect_to( :controller => 'login',:action=>'login')...

27 In the example above, we declare method called authenticate(), and we tell the controller to call it in the before_filter. This will be done for all actions except login. All other controllers are responsible for one model each. The exception is the course model used in business case 10. Because courses are only used in relation with the registration model, there is no need for having a separate controller for courses. 5.3 Models There is one-to-one relation between models and tables in the database. The exception is for tables used to join other tables in the case of many-to-many relations. Those join tables don't have associated models. All models ext ActiveRecord::Base and inherit methods to save and retrieve data from the database. ActiveRecord::Base find() save() User Internship ActiveRecord implements the Active record design pattern described by Martin Fowler in chapter 10 of his book Patterns of Enterprise Application Architecture. The active record pattern specifies that there is one class for each table we have in the database and an instance of a class will correspond to a row in the table. In addition to the simple find() method and other finder methods inherited from ActiveRecord::Base, models get generated accessors methods corresponding to rows in the database. Models can also perform validations, specify relations with other models in a declarative way. For example, to specify the relation between users and messages, I used this code in the User and Message classes: class User < ActiveRecord::Base class Message < ActiveRecord::Base has_many(:messages) belongs_to(:user) This specifies the many-to-one relation between an author and messages. In the user controller when I want to retrieve the messages sent by a user, I used this code => 10,:order =>'ORDER BY created_at DESC'})

28 The messages() method is generated dynamically when we call it, because of the has_many(:messages), we used in the User model. And when we want to print the author of a message, a method to access the user is dynamically generated by ActiveRecord. <% for message %> <tr> <td style="width:250px;"><%= message.user().name() %></td> </tr> <%%> The user() method on a message object returns the author of the message, because of the belongs_to(:user) we called in the Message class. Validations are done almost automatically, we just need to tell ActiveRecord what to validate. Class Internship < ActiveRecord::Base belongs_to(:company) belongs_to(:company_supervisor) validates_uniqueness_of(:user_id,:message => 'you are already registered') validates_associated(:company) validates_associated(:company_supervisor)... The code above is taken from Internship class; The first two lines specify the relation between internship and companies on one side and internship and company supervisors on the other side. And then the three other lines do the validations; validates_uniqueness_of() verifies that users ids are unique in the internship table. It does this check before inserting a new internship in the table; validates_associated() does the validations specified in the associated models when we want to insert a new internship in the database. If the company or company models don't validate, rails won't save the internship either. 5.4 Views Views are template files containing HTML and Ruby code. There is one template per controller method. Templates can include other templates, to reduce code duplication. In our application, I have used one layout file for all views. The layout files then specifies where in the page, the other actions should be rered. The component of Rails that take care of rering the views is called ActionView; ActionView provides many helper methods that deal with html tags. <head> <%= javascript_include_tag(:all,:cache => true) %> </head>

29 For example, the javascript_include_tage() method will include all javascript files stored in the public/javascript directory. The :cache => true option will merge all those files into one compressed file named all.js. Studies done by Yahoo! show ways to improve web applications performance. Those guidelines are published on the following link Among other things, this study shows that most of the -user response time is spent downloading all components in a page because there will be one HTTP request for every object in the page. One proposal to minimize HTTP requests is to combine javascript files into one. 6 How to ext the application In this section, I will propose how to implement the rest of the application. I will talk as well, about how I would remodel some parts of the application using the experience I gained under the project and the better understanding of the requirements. 6.1 Notifications Users need to be notified when a interesting thing happens in the system. There two categories of notifications; the first category is a notification that happens as a response to an event triggeres by a user. For example, when PA or PK reject a request sent by a student, the student should be informed. This notification will be triggered by the rejection. The other category is a notification triggered by a time event. For example, when a student submits starts an internship, he needs to s an abstract for his bachelor thesis in a delay of three weeks. The system should remind him to do so one or two days before the delay terminates. The first category is relatively easy to deal with, but need some careful thought because there is a risk of introducing low cohesion in the system. We need to encapsulate the notifications in such a way that, we don't need to refactor all methods that deal with inserting records in the database. I would introduce these concepts: event_types Every kind of event we are interested to be notified of, would be recorded as an EventType and given a ID. For example a student submits a form in business case 10, we will give the submission of form in BC 10 an ID of 1, and if PA rejects the form we will give the rejection of BC 10 an ID of 2, and so. We will identify all events types in the system and give them an ID. events An event is anything of importance that happens in the system that has an EventType. All events will be recorded in the events table. We will need to record the event type and the timestamp.this relation is shown in the diagram below:

30 The eventsourceid will help to find the specific record that triggered the event. Let us suppose that a form in business case 10 and a form in business case 20 are submitted. If those event types submission_of_form_in_bc_10 and submission_of_form_in_bc_20 are given ID 1 and 2, and the first form is recorded in registrations table with ID 10 and the second is recorded in internships table with ID 21, then the two events will be created with the following data: first record : (eventtypeid = 1,eventSourceID=10) second record: (eventtypeid = 1,eventSourceID=20) The eventid could be auto-incremented and the time will correspond to when the event is created. The combination of eventtypeid and eventsourceid will be unique in this table. If we need to notify people, we will need to look in only one table. By using the eventsourceid we will be able to find what user to notify. Another advantage is that the system will be able to show PA or PK recent events, by looking in the events table. On the application level we will need to encapsulate the notifications logic in an Event model. By encapsulating this in one place, it will be easy in the feature to add and remove new events. The problem that would remain is how will this event model be notified. We could do this in all controllers. We know that inserting new records is done in create() methods in controllers. So we could edit all create() methods. But a better approach will be to take advantage of the event system provided by Rails. As mentionned earlier, rails has an before_filter() that is called before any action and an after_filter() that is called after every action. We could then place this logic in the ApplicationController class because it's exted by all controllers. By using the after_filter() of the ApplicationController, this method will be called after all actions. The other category of events is probably system depent. We will need a background service to be run, maybe once a day. If the application is deployed on Unix server, a cronjob could be used. 6.2 File Sharing Users will need to upload file. For example, in relation with business case 40, students need to upload a document signed by the company supervisor. There are two alternatives to implement this. Files can be stored in a directory on the file system or they can be stored in the database as BLOB (binary large object). The requirements in our case are that a document can have multiple versions. It means that when a user edits a document and upload the new edition of the document, the system should store both the old and the new version. We can store the documents on the file system and the versions in a database. The advantage of storing files as blobs in rails applications is that, files can then be trated as ActiveRecord models. So we can specify relations between files, users and the other models using ActiveRecord's methods. By treating files as models we can access them using the same REST urls as all other resources. 7 Test Rails generates a lot of test files when you create a new project. For each model, there is a corresponding unit test file. For example the User class will correspond to a UserTest class stored in test/unit/user_test.rb. There is a functional test for each controller. There is also possibility to use integration test; intergration tests in rails test the flow between controllers. Unfortunately, there was a bug in my test setup and I was unable to find the cause of the bugs. I ed up doing only manual tests. The test strategy was to use to enter data using the web forms and check if I get the expected results. I could for example fill a form and check, if the form data get saved in the database or if I get an error as expected. An example of tests is given below.

31 Test Expected results Pass/Fail 1)requesting /registrations with out logging in. 2)requesting /registrations when logged in as a student 3)posting a new registration when the user is already registered 4)sing a message to a user Should be redirected to /login Should be redirected to users/1 The system should inform the student that the registration failed The message type should set to PrivateMessage and internship_id should be NULL Pass Pass Pass Pass To test the flow of the application, I inserted a new user in the database and set his status to inactive. This the status of students who have not yet started business case 10. When the newly created user logs into the application, he will be presented with a link to start business case 10: Registration in the system He will be presented with a form to fill when he clicks on the link:

32 In a new browser window, I log in as PA. I would see that a new form has been submitted: PA can then click on show to see the submitted data and to approve or reject it : After an eventual approval, the student should be shown a link to start business case 20 : Rails comes with a console program that can be used to interact with the application. I used it extensively while developing the aplication to test how models change in response to user actions. The console is started by executing this command from the top level directory of the application: ruby script/console The I can check if the student's status changes when PA approves the registration: u = User.find_by_dtu_id('s999999') print u.status() # active I can check if the student's registration was approved : print u.registration().approved?() # prints true