Wednesday, October 5, 2016

Design

I recently drew a draft of a deployment diagram that shows the high-level architecture of the server and client and the network interactions of each program.



More importantly, we've been researching some appropriate techniques for managing software complexity. One of the main design goal for our project is to reduce coupling. We wish to enforce a separation of concerns among each component in the code. One model that we believe will help us enforce this design goal is the Onion Architecture.

A key idea behind the Onion Architecture is to keep infrastructure separate from the rest of the application (UI, logic, model). This can be implemented using Java's interfaces or C++ pure virtual methods. The programmer "can change code in any outer layer without affecting the application core". For example, the data model (a class, a class' meeting times, a token that provides evidence of attendance) should be kept separate from the logic (XML de/serialization, modifications, processing (statistics)), and from the I/O (UI, reading/writing data using a REST API). This will help any automated testing much easier to run. We could test the UI and the data model by implementing app service interfaces (load XML from local file instead of network; create a special provider that raises several HTTP errors (404...); POST to an always false or always true verifier)

These are the motivations behind the organization of the first draft of the client's class diagram:




-- Hugo

Sources

Bibliography

Analogues to the Onion Architecture can be found in many systems.

No comments:

Post a Comment