We will introduce the main architecture of OpenUSS in several point of views.

Layered Architecture

This architecture (figure 1) shows the components of OpenUSS. Figure 2 shows the same architecture in detail.

Figure 1: Layered Architecture of OpenUSS

Figure 2: Detail Architecture of OpenUSS

As you can see in figure 2 there are two layers within OpenUSS:

Foundation Component Layer.
These components are a must for OpenUSS.

• Student component covers all properties and activities of a student at the portal. This component holds e.g. the name and e-mail address of the student. It also supports the student with for example "apply for a login at the portal" activity. We will come to detail with all the properties and activities later in use case diagrams.
• Assistant component actually covers professors, assistants and secretaries. The role of these actors will be summarized as assistant component. It holds for example the name and title. Such an activity like "manage students' login" should be implemented in this component.
• Administrator component administrates the whole OpenUSS. The administrator can build a new university, faculty or institute. Besides it can give an access to the certain professors, assistants at the first time.
• Faculty component takes care all the things about universities, faculties or institutes.
• Semester component gives every faculty a time zone. This could be half a year or one year and so on. You can define this by yourself.
• Subject component covers the subject within the faculty at the given semester.
• Security component takes care e.g. the login for the students, assistants and administrators.

Plugable Component Layer (Extension Component).
These components can be installed into the foundation layer. All the functionalities of OpenUSS are put in this plugable layer. It is important to know that you can always extend the components in this layer. To be designed and implemented are the following components:

• Lecture component gives an opportunity for assistants to publish their lectures' materials. Also students that already registered can download them easily.
• Exercise component. The registered students can send or upload their exercises through this portal and the suitable assistant can correct them and give a note.
• Game component represents leisure time for students. There should be some "intelectual" games to play in this area depending on the subject.
• Chat component makes it possible to chat with professors, assistants and other students depending on the subject.
• Mailing list component. The students can apply for a mailing list so he or she willl get the current information in their e-mail box.
• Discussion component functions like chat component but in asynchronous way.
• Archives component can produce an archive e.g. for every semester. This can be distributed through CD Roms so the students can search and look at the history at their faculties and subjects.
• Virtual assistant component helps the students to manage their study and time table. It also gives an opportunity for assistants to give personalized comments to the performance of each and every students.
• Data Warehouse and Data Mining component gives the assistants statistical data and general use of the system. This component can be used as a system report.

User Architecture

This architecture gives users of OpenUSS a comprehensive view about how the system works for them.

Figure 3: User Architecture of OpenUSS

As you can see there are three roles available in the system: Student, Administrator and Assistant. In this case assistant means professors, assistants and secretaries. To see the details of these roles please look at the use case diagrams of the system.

Multi Tier Architecture

OpenUSS will be build based on Multi Tier Architecture. Figure 4 shows this in detail. Explanation about this is ommited.

Figure 4: Multi Tier Architecture of OpenUSS

Summary

The architecture of OpenUSS will evolve at the time we are beginning to implement this system. We will be very happy if you give us your comments to this part, because we think that the system architecture is one of the most important part of the software engeneering.