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

Changes | Index | Search | Go
 <<O>>  Difference Topic HealthWatcherDR (5 - 2010-08-17 - RodrigoBonifacio)
Line: 1 to 1
 
META TOPICPARENT name="CaseStudies"

Health Watcher DRs

Line: 22 to 22
 

Domain DRs

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

Line: 56 to 56
 }
Changed:
<
<

Business DR

>
>

Transactional Methods and Business DRs

 
public abstract cclass DRTransactionalMethods {
Line: 90 to 90
 }
Changed:
<
<
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.
>
>
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

Line: 155 to 155
 
Changed:
<
<
I've tried to specify these constraints using a CaesarJ collaboration that "requires" the DRTransactionalMethods. This specification leads to several compile errors in my environment, but it might be useful to explain my idea. Must of the 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 TransactionalAspect (see bellow).
>
>
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   
Line: 186 to 186
  Problems and questions:
Changed:
<
<
>
>
  • 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?
Added:
>
>
  • Does ECaesarJ supports Java Generics?
  • ...
  -- RodrigoBonifacio - 16 Aug 2010

View | History: r6 < r5 < r4 < r3 | More

View | History: r6 < r5 < r4 < r3 | More
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