Health Watcher DRs

System overview

The purpose of the system is to collect then manage public health related complaints and notifications. The system is also used to notify people about important information regarding the Health System.

The Health Watcher system must also exchange information with the SSVS system (Sanitary Surveillance System). Initially, this exchange will involve the querying of sanitary licenses. Subsequently, when the SSVS has the Complaint Control module deployed, Sanitary Surveillance complaints will be exchanged between the two systems.

A detailed specification is available as an attached document.

DRs

The design rules detailed here aim to allow the independent development of the Health Watcher features. Therefore, the developers of the core use cases of the Health Watcher must obey to and rely on several assumptions specified as DRs; as well as the developers of the variant features. The DRs presented here are specified using ECaesarJ construtcts.

Domain DRs

These DRs specify which are the obligations of the HW Business developers. They state the responsibilities of the domain objects as well as the responsibilities of the manager classes that operate over the domain objects. Basically, we follow the anemic domain objects model, where classes from the domain only implement access methods. Differently, manager classes are responsible for implementing the business rules, which are specified in the use case document of the health watcher system. Three DRs are provided here.

Domain DR

public abstract cclass DRDomainCollaboration {

   public abstract cclass Address { ... }
   public abstract cclass Employee { ... }
   public abstract cclass HealthUnit { ... }
   public abstract cclass MedicalSpeciality { ... }

   public abstract cclass Complaint {
      public abstract String getAuthor();
      public abstract Address getAuthorAddress();
      public abstract String getDescription();
      public abstract String getEmail();
      public abstract Date getComplaintDate();
      public abstract Employee getEmployee();
      public abstract String getNote();
      public abstract Date getResponseDate();
      public abstract int getStatus();
      public abstract void setAuthor(String author);
      public abstract void setAuthorAddress(Address authorAddress);
      public abstract void setDescription(String description);
      public abstract void setEmail(String email);
      public abstract void setComplaintDate(Date complaintDate);
      public abstract void setEmployee(Employee employee);
      public abstract void setNote(String note);
      public abstract void setResponseDate(Date responseDate);
      public abstract void setStatus(int status);
   }   
}

Transactional Methods and Business DRs

public abstract cclass DRTransactionalMethods {
   public abstract cclass SystemFacade {
      abstract event transactionalMethod();
   }
}

public abstract cclass DRBusinessCollaboration extends DRTransactionalMethods {   
   public abstract cclass EmployeeManager {
      public abstract  Employee authenticate(String login, String passwd);
      public abstract Employee search(String login);
      public abstract void register(Employee employee) throws ObjectAlreadyExistsException;
      public abstract void update(Employee employee);      
   }

   public abstract cclass ComplaintManager {
      public abstract void registerComplaint(Complaint complaint);
      public abstract void updateComplaint(Complaint complaint);
      public abstract List listOpenComplaints();
      public abstract List listAllComplaints();
   }
   ...      
   public abstract cclass SystemFacade {
      event transactionalMethod() = this.registerComplaint(Complaint complaint) ||  this.registerEmployee(Employee employee) || ... ;
      public abstract Employee authenticate(String login, String password);
      public abstract void registerComplaint(Complaint complaint);      
      public abstract void registerEmployee(Employee employee);      
      ...
   }
}

Note that SystemFacade, declared within DRBusinessCollaboration, "implements" the event (transactionalMethod()), which is triggered whenever a call to registerComplaint, registerEmployee, and so on occurs. This definition is quite similar to the definition of a pointcut, and I have not found any reason for delaying the definition of this event to the SystemFacade developers. Perhaps, making the system facade reusable for different systems; even though I have not designed this interface with this specific goal. As explained earlier, the driver for these interfaces is to promote the independent development of the features. Nevertheless, it seems that declaring an event (instead of a pointcut) localizes the definition of the transactional methods events within the SystemFacade.

Persistence Mechanism DRs

The DR related to the persistence mechanism. It abstracts the details of the expected persistence mechanisms (in memory or database). In order to do that, several interfaces (abstract classes within the DR) are declared, with the purpose of:

specifying data access methods for the domain objects (repository interfaces)
getting access to the proper implementation of the repositories (AbstractDAOFactory interface)
getting access to a specific implementation of a DAOFactory (getDaoFactory() method)

Data Access DR

public abstract cclass DRDataAccessCollaboration {
   public abstract AbstractDAOFactory getDAOFactory();
   
   public abstract cclass AbstractDAOFactory {
      public abstract AbstractEmployeeRepository createEmployeeRepository();
      public abstract AbstractComplaintRepository createComplaintRepository();
      ...
   }
   
   public abstract cclass AbstractEmployeeRepository {
      public abstract boolean exists(String login);
      public abstract Employee search(String login);
      public abstract void insert(Employee employee) throws ObjectAlreadyExistsException;
      public abstract void update(Employee employee);
      public abstract void remove(String login);
      
   }
   
   public abstract cclass AbstractComplaintRepository {
      public abstract boolean exists(int code);
      public abstract Complaint search(int code);
      public abstract void insert(Complaint complaint) throws ObjectAlreadyExistsException;
      public abstract void update(Complaint complaint);
      public abstract void remove(int code);
   }
   ...
}

Abstract repository definition using generics

We could have specified an abstract repository using generics, such as:

public abstract cclass AbstractRepository<T,K> {
      public abstract boolean exists(K key);
      public abstract T search(K key);
      public abstract void insert(T domainObject) throws ObjectAlreadyExistsException;
      public abstract void update(T domainObject);
      public abstract void remove(K key);
}

But, at this time, I am not sure if CaesarJ supports Generics (I guess that Carlos told me something about this limitation).

Transaction Mechanism DR

According to the previous Health Watcher case studies, a DR for the Transaction Mechanism must state that:

There must exist a TransactionManager interface, declaring methods such as begin(), commit(), and rollback()
There must exist an aspect (TransactionAspect) that calls begin(), commit(), and rollback at specific joinpoints
Calls to the TransactionManager methods must occurs only within the TransactionAspect pieces of advice

I've tried to specify these constraints using a CaesarJ collaboration that "requires" the DRTransactionalMethods. This specification leads to some compile errors in my environment, but it might be useful to explain my idea. I guess that those errors were motivated because I am not sure about how to express the binding between the pointcut definition (expressed as an event declared in the DRTransactionalMethods) and the pieces of advice declared within the TransactionAspect (see bellow).

public abstract cclass DRTransactionManagement requires DRTransactionalMethods   
{
   protected abstract AbstractTransactionMechanism getTransactionMechanism();
   
   public abstract cclass AbstractTransactionMechanism {
      protected abstract void begin();
      protected abstract void commit();
      protected abstract void rollback();
   }
   
   public cclass TransactionAspect {
      transactionalMethod() => {
        getTransactionMechanism().begin(); 
        try {
          proceed();
           getTransactionMechanism().commit();
        }
        catch(Exception e) {
           getTransactionMechanism().rollback();
        }
      }
   }
}

Problems and questions:

The method getTransactionMechanism() is not visible to the TransactionAspect advice
Does the declaration begin, commit, and rollback as protected prevent external calls to those methods?
Does ECaesarJ supports Java Generics?
...

-- RodrigoBonifacio - 16 Aug 2010

I	Attachment	Action	Size	Date	Who	Comment
pdf	Health_Watcher_Usecase_v2_1.pdf	manage	66.7 K	2010-08-16 - 13:56	UnknownUser

Parents: WebHome > CaseStudies