| 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. |
