Home - this site is powered by TWiki(R)
PROBRAL/InternalArea > CaseStudies > HealthWatcherDR (r3)
TWiki webs: Main | TWiki | Sandbox   Log In or Register

Changes | Index | Search | Go

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. Two DRs are provided in this level.

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);
   }   
}

Business DR

public abstract cclass DRBusinessCollaboration {   
   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 transactionalBlock() = 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 declares an event (transactionalBlock()) that is fired whenever occurs a call to registerComplaint, registerEmployee, and so on. This definition is quite similar to the definition of a pointcut, and I have not found any reason for making the definition of this event abstract. Perhaps, making the system facade reusable for different systems. But I have not designed this interface with this specific goal. As explained earlier, the driver for this interfaces is to promote the independent development of the features.

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

-- RodrigoBonifacio - 16 Aug 2010

Edit | Attach | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions...


Parents: WebHome > CaseStudies
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback

mersin escort bayan adana escort bayan izmit escort ankara escort bursa escort