Practical Exercise Exercise
Practical Exercise
Your Name
________________________________________________________
Exercise
Step 1) Fill in the form about your background. The background form should be filled by
each individual. Please provide as precise information as possible about your previous
experience.
Step 2) After filling in the background form, you can start to follow the guidelines and
answer the questions.
Step 3) Start by reading the description of the Health Watcher system provided below.
IMPORTANT: before you start to read the description, indicate here what time
it is now: ___:___ ___ 
Health Watcher System – Textual Description
The Health Watcher (HW) system allows a citizen to register complaints to the public health
system. Figure 1 shows a diagram representing some of the classes and interfaces of the Health
Watcher system. This diagram is actually a simplification of the HW design. In the HW system,
complaints are registered, updated and queried through a Web client.
The system is structured with the goal of decoupling different parts of the system in order to make
it easy to change them independently. Therefore, the user interface part of the system is
decoupled from the part which implements the business logic which, in turn, is also decoupled
from the database management.
The user interface is represented by the Servlet classes, such as ServletInsertEmployee and
ServletSearchComplaintData (Figure 1). Access to the HW services is made through the IFacade
interface, which is implemented by the HealthWatcherFacade.
One of Health Watcher’s requirements is to allow several customers to access the system at the
same time. Therefore, a client-server approach is used to distribute part of the execution, which is
implemented by the class HealthWatcherFacade and Servlets. HealthWatcherFacadeInit works
as a portal to access the business collections, such as ComplaintRecord and EmployeeRecord.
Although the Record classes concurrently receive requests from many clients, they manage to
synchronise their accesses to the data. Interfaces, like IComplaintRepository, decouple the
business logic from the specific type of data management in use.
Figure 1 shows the classes that serve the purpose of implementing a repository for a relational
database: HealthUnitRepositotyRDB, EmployeeRepositoryRDB and ComplainRepositoryRDB.
Table 1 summarizes the main responsibilities associated with each class in the HW system.
Furthermore, six concerns are the main drivers of the Health Watcher design.
Table 2 describes these six design concerns. Classes and interfaces that somehow realise the
main concerns of this system are tagged in the design model of Figure 1. For example, a class
realising the Business concern is identified by the letter ‘B’ inside that class.
Health Watcher System –Design
HWServlet
D V
ServletUpdateHealthUnitData
D E V
ServletSearchComplaintData
ServletInsertEmployee
ServletUpdateComplaintData
D E V
D E V
D E V
IFacade
B
HealthWatcherFacade
B D E P
HealthUnit
B
HealthWatcherFacadeInit
Complaint
B
B
IPersistenceMechanism
P
HealthUnitRecord
B C
ComplaintRecord
B C
EmployeeRecord
Employee
B C
B
PersistenceMechanism
IHealthUnitRepository
P
P
HealthUnitRepositoryRDB
E P
IComplaintRepository
P
IEmployeeRepository
P
ComplaintRepositoryRDB
EmployeeRepositoryRDB
E P
E P
Concerns:
Legend:
Class or Interface
Association
B Business Logic
E
Exception Handling
Inheritance
Dependency
C Concurrency
P
Persistence
D Distribution
V
View (GUI)
Figure 1. A partial view of the Heath Watcher design
Table 1. Responsibilities of Health Watcher classes
Classes
HWServlet
ServletInsertEmployee,
ServletSearchComplaintData,
ServletUpdateComplaintData,
ServletUpdateHealthUnitData
IFacade,
HealthWatcherFacade,
HealthWatcherFacadeInit
HeathUnit,
Employee,
Complaint
HealthUnitRecord,
EmployeeRecord,
ComplainRecord
HealthUnitRepositotyRDB,
EmployeeRepositoryRDB,
ComplainRepositoryRDB
IHealthUnitRepositoty,
IEmployeeRepository,
IComplainRepository
PersistenceMechanism,
IPersistenceMechanism
What they do
These classes implement the user interface of the system.
These classes provide a simple interface to all services of the system.
These classes represent business basic concepts of the Health Watcher system
domain.
These classes represent a grouping of objects from a basic class. For instance,
EmployeeRecord groups objects of Employee.
These classes contain methods for manipulating persistent objects of the business
basic classes. The code of these classes depends on a specific API for accessing
some persistence platform, thus any changes to this platform will cause direct impact
on these classes.
These interfaces establish a decoupled relationship between the “Record” classes
and “RepositoryRDB” classes. In this way, changes to the data access code (i.e.,
“RepositoryRDB” classes) do not have impact on business code.
This class and its interface implement services such as connecting to and
disconnecting from the database, transaction mechanism, concurrency mechanism,
etc.
Table 2. Key Health Watcher design concerns
Concern
Business Logic
Concurrency
Distribution
Exception Handling
Persistence
View (GUI)
What they mean
It defines the business elements and rules. In the Health Watcher case, Business is
mainly related to kind of manipulated information, such as employees, complaints,
and health units.
It provides a control for avoiding inconsistent information stored in the system’s
database. Concurrency control can be implemented, for example, by defining
atomic database transactions. That is, each action performed in the database must
either be entirely completed or have no effect in stored data.
It is responsible for externalizing the system services at the server side and
supporting their distribution to the clients. Remote Method Invocation (RMI) is
used by client classes to call the Health Watcher services.
It is a mechanism designed to handle the occurrence of a condition that changes the
normal flow of execution. Many computer languages, such as Java, have built-in
support for exceptions and exception handling. The scope for exception handlers
starts with a marker clause (try) and ends in the start of the handler clauses (catch).
It is NOT related to exception handling: (1) initiating an exception (throw
statements) and (2) signalling an exception (throws clauses in a method signature).
It refers to the ability to retain data between program executions. In other words, it
is responsible for retrieving and storing the information manipulated by the system.
In the Health Watcher implementation of persistence, database connections are
used before retrieving and storing data into disk.
It provides a Web interface that allows users to interact with the Heath Watcher
system. View is implemented by servlets in Health Watcher.
Step 4) The Java source code of four of the Health Watcher classes was given to you
(Partial Health Watcher Implementation). Take your time to look at this source code
focusing on how the six key Health Watcher concerns were implemented.
IMPORTANT: before you start to look at the source code, indicate here what time
it is now: ___:___ ___ 
Step 5) The Health Watcher developers need your help to identify which pieces of code
implement the main concerns of this system in the source code. Use the letters presented
in the legend of concerns (Figure 1) to tag lines of code realising each design concern.
For example, if you think a method/attribute/statement is somehow realising the
Concurrency concern, write the letter ‘C’ in the respective area on the left side of this
coding element.
If many consecutive lines are implementing the same concern, you don’t need to specify
line per line; instead, you can group them in a block (using brackets) and then put just
one letter for the block of lines. Similarly, if the same line (or block) of code is realising
more than one concern, you have to specify with letters all concerns this line (or block) is
realising.
Remember that it is important to reason about the design model and the concern
descriptions in order to identify which pieces of code are realising each concern. Also,
some of these concerns may be well modularised in one (or more) classes, i.e., there are
classes entirely dedicated to realise them. However, other design concerns may not be
well modularised and may spread over a number of classes of the system, i.e., they are
realised by small pieces of code in classes whose main purpose is NOT to modularise
them.
IMPORTANT: when you finish your analysis and assignment of concerns to
classes,
indicate here what time it is now: ___:___ ___ 
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising