Update 11/20/16

In this week's meeting we continued discussing conferences that we are interested in attending. We decided that we would take ACMSE 2017 into serious consideration.

Regarding progress on the project, the server can now interpret timestamp information transmitted from the app component. Along with sending timestamp information, we also have the capability to send basic device information to the server. We have encountered a bug in the app that causes it to crash when launching on a mobile device. We were able to test the information transmission by using the desktop app, however, we will need to look into this bug.

--Eugene

Update 11/13/16

In this week's meeting we discussed what other information should be sent in addition to the evidence submitted by the student. We decided that there should be various timestamps sent between the server and the device. Using these timestamps for our user study will allow us to collect important efficiency-related data. Along with these timestamps, we also thought about sending device information that could be used to determine a user's identity as a means of bypassing the log-in process every time.

We also discussed various conferences that we are interested in attending, including some international ones, such as: GCCCE (China), LTLE (Japan), IEEE ICALT (Romania), and AACE ED-Media (Washington, D.C.). We will hopefully come to a decision in next week's meeting.

--Eugene

Update 11/06/16

In this week's meeting we displayed the version of our app that is capable of communicating with the server. There is still some work to do on the user interface to make it more dynamic across devices with different screen sizes. The current state of the app is shown below on an Android device:

                               Initial log in screen                      
    

Error upon bad authentication attempt 

 

 Screen where attendance evidence will be submitted

 

   Evidence success screen

There are still many evidence methods that have yet to be implemented. In the user study we will have the ability to disable certain methods so that we are able to choose which ones will be tested at one time. We have given some thought to a system where students are required to use a certain number of evidence methods simultaneously in order for their attendance to be considered valid. Requiring students to submit 2-3 different types of evidence can help in reducing fraud.

In this next week we will continue developing the server-side component to ensure that information is being sent successfully. We also have to determine what other information can be sent to the server, i.e., WiFi information and device information. This type of information will be useful in the user study.


--Eugene

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

Update 09/25/16

In this week's meeting we shared the information we discovered regarding the localization part of our application. We found that iOS does not allow for the collection of low-level data, i.e., wireless access point information. We have yet to do research to determine a method of gathering this information on iOS. Dr. Kuo said she would inquire about collecting WAP information on iOS. Implementing this feature would increase our sample size in the user study that will be performed later.

Dr. Zheng proposed that we focus on the authentication aspect of our app so that we have some basic functionality. There are two priorities for this:

1. initial login functionality (user profile initialization)
2. ensure that PIN entry works

We will begin with a simple PIN authentication method and add other methods (QR code, pattern) after we have the PIN authentication functional.  At the moment, we are planning on having the PINs generated server-side, where they will be compared with the PINs sent from the student app.

--Eugene

Update 09/18/16

Hugo and I have started experimenting with a variety of Qt's modules to understand how app features will be implemented later in development. We have also discussed methods of obtaining location information, as well as methods of facial recognition. 

At the moment we are considering using OpenCV (Open Source Computer Vision Library) as the back end for facial recognition. OpenCV has a plethora of algorithms that will aid in the detection and recognition of faces. Since OpenCV's primary interface is in C++, it will integrate nicely with the C++ components of our app. The library has sufficient documentation and it is open-source, which is always a positive attribute!

Nico has been planning and designing the server-side part of our application. He has researched prospective classroom integration platforms for us to utilize. Mainly focusing on Moodle, we have decided that it will probably not be a practical method of hosting the server, due to issues discussed in Nico's post. In the coming weeks we will begin exploring other options for our server-side needs. 

--Eugene 

Server-side development progress

     For the past three weeks I've been working on the design of the server-side component of our application, and consulting with Hugo and Eugene on how the client app is going to tie into this. This post focuses on the prospect of integrating our software with existing classroom management software to see how our software would utilize their APIs if we choose to support them, with a specific focus on Moodle. Since Moodle is a modular, plugin-based system, if we choose to integrate our application with theirs we would need to write a plugin composed of PHP, JS, HTML, and CSS.

     Moodle seems to have substantial support for everything we need at first glance. The Enrollment and Access APIs provides functions that allow us to pull a list of the students' classes, check if our software is used in these classes, pull lists of the students in each class, and restrict the use of our software to those enrolled in the class through role-based authentication. Being role-based, this also allows the teacher to act as an administrator so that they can a student after attendance polling has closed if a student has forgotten their phone. The Attendance Module provides and modifies a database for storing students' attendance record, with pre-set options to account for being present on time, tardy, absent without an excuse, and absent with an excuse. Students may upload files, which we would use for the secret-sharing based authorization component of our application. Moodle also handles software updates and logging for us.

     What's more, since Moodle is open-source, it is installed and managed by each school that uses it. This was an important design consideration-- if each school runs their own copy of our software, as opposed to us running one copy of the server that services every school, we would not need to concern ourselves with operating at a large scale, or with handling potential downtime. Since our plugin would also be open-source, it could be configured by each school to suit their needs. Because Moodle supplies so much support for us, I began to consider developing the entire server-side component of our software as a Moodle plugin, rather than just potentially providing support for it.

     However, there were some serious drawbacks to this approach. First, Moodle's documentation is incomplete, and questions are generally handled by the community. While this is a common approach, this made it difficult to find information critical to continuing with this approach-- like whether an additional JSP could be run from inside our plugin to run our facial recognition algorithm, location-checking, random secret generation, and the other components of authentication our application requires. This would mean that Eugene and Hugo's mobile component would need to interface with this JSP, which would then make calls to Moodle, which I felt defeated the purpose of integrating fully with Moodle. Moodle provides a mobile application that users are free to fork and use for their own purposes, but because this is compiled with Phonegap and Hugo and Eugene have decided to work with Qt, this would be inconvenient. Since they are also implementing methods of authentication we felt were outside of the capabilities of Moodle's native interface, like capturing photos or completing lock patterns, I decided against integrating our server-side component fully.

     This has been a very roundabout way of saying that I'm not going to do something, but not for naught! We learned a lot in the process of examining Moodle as a host for our server. Moodle provides enough support for integrating core components of our application that I could write a simple helper plugin to integrate our software with Moodle relatively easily. Since this is possible with Moodle, it is likely possible with alternative classroom managers like Canvas as well. Furthermore, the importance of each school running their own copy of our server-side software for scalability and modifiability reasons helped me to realize that developing a desktop application server for professors to run as they take attendance is the most flexible method of implementing our server-side design-- more on this in my next post!

--Nico

Update - 09/09/16

In our meeting yesterday, we presented a draft of how the app UI will function and how the different screens will interact with one another:

We were also able to show Dr. Zheng and Dr. Kuo the intial UI we designed in Qt Creator:

 Dr. Kuo suggested that we create a drop-down server list so that the student does not need to re-enter the server information every time. 

We discussed different methods of fraud prevention like wifi-based localization and facial recognition, which will be implemented after there is a base app.

We decided that having the instructor input student details would be the easiest procedure to initially populate information. Another possible method of information population is interfacing with the Moodle/Canvas API and pulling student information from there.

There was also an idea for an additional feature where the app would send notifications to truant students, informing them of how often they miss class.

Dr. Zheng tasked us with creating a small localization-test app so we can determine the accuracy of the Qt Location module. We will also need to collect access point information for each classroom.

--Eugene

Initial Thoughts

I've researched several cross-platform app development frameworks. We want a platform that's free to use, powerful, and runs on iOS, Android, and Windows Phones. Candidates include PhoneGap, Xamarin, CodenameOne, and Qt. It would be difficult to maintain one code-base per OS, but this is also an option.

Qt seems like the best framework for our purposes. With it we can write efficient and multi-platform C++ code. Not only that, but it comes with a JSON/JavaScript-like domain-specific-language called QML for describing graphics layouts and most application logic. QML doesn't support networking so we will have to write the TCP or HTTP code using C++, but QML works well with C++ components.

Qt gives us the benefits of developing with PhoneGap, an easy-to-use language with WYSIWYG editor, and the benefits of writing the app using a compiled language as we would use CodenameOne and Xamarin.

I learned all of this from its very readable documentation --- another feature!

Qt employs asynchronous functions and a related concept called "signals" for handling many inputs, like clicks or network requests. When used right, these improve the application's efficiency; but we'll have to learn about this new control style.


--Hugo