Fig19. Session facade class
diagram
Participants and Collaborations
The client of the Session Facade is who needs access to the
business service.
The SessionFacade is implemented as a session bean. It manages
the relationships between numerous BusinessObjects and provides a higher level
abstraction to the client.
The BusinessObject is a role object that facilitates applying
different strategies, such as session beans entity beans and a DAO (see the
next section, "Strategies"). A BusinessObject provides data and/or some service
in the class diagram. The SessionFacade interacts with multiple BusinessObject
instances to provide the service.
3.3.2 Data base conception
At this stage will present the various modules of
the system before exposing the class diagrams, then we
will finish by introducing the kinetics of the application.
Database details:
The user entity described by an id, name,
user surname and login/password for authentication. It also
contains other additional information as his privilege
id and e-mail.
The Internet user can view his privileged
space via his login and password, but he
must following the appropriate
role. Its timing (via calendar table)
and the address book (via Address Book
table).
It can also add or download documents
from the platform, ask questions, propose answers or
comments, organize or register for training/ online tests.
To
control and manage the application the administrator
thus may consult the database tables through web interfaces.
Table's presentation:
§ Person Table: Contains information of various
users of the system.
§ Document table: lists
all files exchanged between the different users.
§ Knowledge table: knowledge of professor
backup.
§ Person
knowledge table: contains the list of knowledge of
each teacher.
§ Privilege table: register the articles
of each user: administrator, user or teacher.
§ Question table: Saves the
questions posed and the user who asked each
question.
§ Answer table: The
response and the user responded to each question.
§ Training table: records all the
information necessary for training.
§ Calendar table:
contains the events created by users.
§ Address Book
table: contains lists of contacts for each Internet.
3.3.3 Packages
decomposition
To move to the design step, we
rely on the principles of the object-oriented approach;
we are moving from a functional structure
through the use case, to
a structure object through
classes and packages.
Given our application architecture and it's
large number of candidate classes; it was important to part
them into packages to better understand the overall
role of each part and facilitate code
maintenance.
To identify the packages, we rely on application
layers and independence criteria.
So we try to group classes that have
a strong correlation between them, which belong to
the same functional area: They must render similar
services to user. The package diagram of
our application as follow:
controller
models
Session beans
| 
