Open Source Software for Universities and Faculties (Open Source University Support System)

Open Source Software for Universities and Faculties (Open Source University Support System)
last updated: 2002-09-09

Business Objects



Foundation Components

Relationships and Dependencies between the Foundation Components

It is important to understand how the foundation components build the architecture of OpenUSS together. As you can see in the architecture specification of OpenUSS, the system provides some foundation components such as Student, Assistant, Faculty, Administrator, Semester, Subject, etc. that should be used to handle common services at a faculty or a university. Figure 1 shows the relationships and dependencies between these foundation components.

The Enrollment component will be used mostly to communicate with the Extension Components of the OpenUSS system. An enrollment can be compared with an order. It's a combination between a customer, a product and a time point. An enrollment is a combination between a faculty, a subject and a semester.

As a summary:
Most of Extension Components should have a relationship with the Enrollment component, if they have or want to persist and save some data.

For example: If someone wants to build a Lecture Extension Component, then she or he has to save some informations and relationships between the lecture and the enrollment itself (An enrollment can have many lectures but a lecture will always be owned by one specific enrollment. Please be careful: an enrollment is not the same as a subject!).

In the most cases you will have to extend the Enrollment component. Mailing list, Discussion, Excercises, etc. all depend on the enrollment. In some exceptions maybe you also want to extend some other components. More about this later in the Extension part.


Figure 1: UML class diagram for the Foundation Components


Design Pattern for the Foundation Component

Every foundation component can be divided into three categories as we have seen it in the components specification before: Business Object, Workflow Object and Relationship Object. Figure 2 helps you to understand this situation. It shows how we can handle a complex (n:m) relationship within the foundation components within the EJB architecture (Enterprise JavaBeans). As an example we use the relationship beetween an Assistant Foundation Component and a Faculty Foundation Component (as normally an assistant can work in many faculties and a faculty could have many assistants as well). This design pattern for the foundation components should be used all over the OpenUSS system.


Figure 2: Design pattern for Foundation Components in OpenUSS


Figure 3 until 5 show the detail information of every BO, WO and RO.


Figure 3: Assistant Foundation Component BO and WO


Figure 4: AssistantFaculty Foundation Component RO


Figure 5: Faculty Foundation Component BO and WO


We will provide you with some templates to make such a relationship easier to handle. To look at the source code we recommend you to directly browse it in the CVS.


SourceForge Logo

(c) Copyright OpenUSS 2002. Designed by Torsten Menzel 2002. Web master: