Update 10/30/16

We now have some communication between the app and server components. The app can now authenticate with the Tomcat server and send attendance evidence. We will be adding to the user interface, and create a mock-up of all the evidence methods we plan on implementing. Hopefully we will have ZXing (Zebra Crossing) working soon!

--Eugene

Update 10/23/16

Our group is still making adjustments to the app in order to get the user interface to display better on Android. We have also changed the way some user input fields function by limiting the maximum length and characters that can be used. In the future, we may make server/class selection easier by implementing a drop down menu that students can choose from. Since we already have password and PIN methods of authentication, the next two methods to implement will be QR code and pattern.

In this week's meeting, we were able to demo our app prototype. Dr. Zheng advised us to focus on communication between the server and the app. Currently, the local SimpleHTTPServer has been our testing platform for authentication; we have yet to authenticate with Nico's server. Dr. Kuo mentioned that we should also be transmitting timestamps, which will be an important part of collecting data for the user study. An idea was proposed that unique secrets would be generated server-side then displayed in the student app prior to check-in. However, in order to prevent fraudulent check-ins, we will have to wait until we have location-based functionality until we implement this.

--Eugene

Update 10/16/16

After working on the client side of our application, we now have a semi-functional prototype. The app can connect to an instance of a modified SimpleHTTPServer and authenticate. This server will help us in testing and debugging our PIN/password authentication, however, it will not be a component of our finished project. We have also made some modifications (shown below) to the UI to better suit the features we need to implement first.

Students can enter their PIN

The initial login page

Check-in success page

We have yet to reach the point where QR codes can be used as a valid form of attendance evidence. We expect that QR code authentication will be implemented soon. 

--Eugene

Update 10/10/16

We are still working on getting the app fully functional. As of late, we have been focusing our efforts on setting up the server-side component. We have decided on using the NetBeans IDE for the development of the Java servlet that will be created and deployed to a Tomcat server. We will also be using GitLab to aide in managing our project. GitLab offers an issue tracking feature that will help us organize tasks that need to be completed.

--Eugene

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

Update 10/03/16

We have decided to store class information in XML format. We have made progress on the networking component of our application. This is the first step toward integrating with Moodle. The app is capable of retrieving a file from a server and storing it locally on a device. Once the XML file has been parsed, we will be able to store the student's classes as QObjects and display them in a ListView. Parsing the XML will also allow us to load other relevant class information, such as attendance records and meeting times. Nico has started setting up a Tomcat server so that we can get an idea of what the server-side architecture will look like. Hugo has created a deployment diagram, along with diagram to show what the client-side implementation will look like, which are discussed here.

--Eugene