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

• The blog post that introduced the Onion architecture contains several useful ideas: http://jeffreypalermo.com/blog/the-onion-architecture-part-3/
• http://www.methodsandtools.com/archive/onionsoftwarearchitecture.php
• http://blog.thedigitalgroup.com/chetanv/2015/07/06/understanding-onion-architecture/

Bibliography

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

• Free Monads: (in Haskell and other strongly-typed functional languages) http://degoes.net/articles/modern-fp-part-2
• Elm's Scalable Architecture: https://guide.elm-lang.org/architecture/
• Ports and Adapters: http://www.dossier-andreas.net/software_architecture/ports_and_adapters.html
  
  • The core logic can be tested independent of outside services.
  • It is easy to replace services by other ones that are more fit in view of changing requirements.
• Screaming Architecture: "A good architecture emphasizes the use-cases and decouples them from peripheral concerns." https://8thlight.com/blog/uncle-bob/2011/09/30/Screaming-Architecture.html
• Data Context Interaction: Helps "cleanly separate code for rapidly changing system behavior (what a system does) versus slowly changing domain knowledge (what a system is), instead of combining both in one class interface." https://en.wikipedia.org/wiki/Data,_context_and_interaction