S/W Design and Architecture

Final Project: Quiz Application with Microservices

Objectives

During this activity, students should be able to:

This activity helps students develop the following skills, values and attitudes: ability to analyze and synthesize, capacity for identifying and solving problems, and efficient use of computer systems.

Activity Description

This activity must be developed in teams of two or three people.

Write a quiz application that allows testing the user's knowledge about design patterns.

Requirements Checklist

  1. Application Code and Functionality
    1. The application must be comprised of at least three microservices plus the web client code that integrates them all and provides the user interface.
    2. Each microservice must be implemented as an AWS Lambda function in Ruby and provide a RESTful API with JSON requests and responses.
    3. Each microservice should have its own independent persistent data store (if it actually needs one), shared with no other microservice. For read only data stores you can use plain text files (for example YAML or JSON files). For read & write data stores you must use the Amazon DynamoDB NoSQL database.
    4. The web client must be developed in Ruby using the Sinatra DSL using the Model–View–Controller (MVC) architectural pattern.
    5. The user interface must be intuitive and easy to use. You may use a web front-end framework (for example Bootstrap or W3.CSS) if you wish.
    6. The application must allow the user to select how many different questions (between one and ten) she/he wants to answer.
    7. The questions must be selected randomly from a bank of at least 40 multiple choice items. All questions must be related to design patterns or antipatterns, and must be taken from any of the following resources: [OLSEN], [GAMMA] or [SOURCEMAKING].
    8. Each question must appear all by itself in the web browser window.
    9. Once the user answers a question, the application must give the user the corresponding feedback, indicating if the answer was right or wrong, and displaying the correct answer if the user’s choice was wrong. After this, the user can proceed to see and answer the next question.
    10. Once all questions have been answered, the application must display the final score. Also, a score table with the initials and scores (in descending order) of all previous users should be displayed.
    11. The user should be given the choice to receive an SMS text message in her/his phone containing the score and the place obtained relative to the other users. This should be done using the Amazon Simple Notification Service.
    12. Finally, the user should be given the option to restart the quiz application.
  2. Documentation
    1. You must write the documentation for your application’s design and architecture. See the example in: greeter.tgz. The greeter/README.rdoc file contains all the indications on how to produce the documentation. This is how the final result should look: greeter/doc/index.html.
    2. Your README.rdoc must contain these sections:
      • General overview
      • How to install and run the application and all the microservices
      • 4+1 architectural view model
        • Logical view
        • Process view
        • Development view
        • Physical view
        • Scenarios
      • Patterns used
      • Acknowledgments (optional)
      • References
    3. Every Ruby class and public method developed must be adequately documented using the RDoc markup language.
    4. All the source files must include at the top the authors’ personal information (name and student id) within comments. For example:
      # Final Project: Quiz Application with Microservices
      # Date: 14-May-2019
      # Authors: A00456654 Thursday Rubinstein
      #          A01160611 Anthony Stark
      

Deliverables

Place in one tarball file called microservices.tgz all the contents of your project.

Upload Instructions

To deliver the microservices.tgz file, please provide the following information:

Request PIN

Only one team member needs to upload the file.

Due date is Tuesday, May 14.

Evaluation

This activity will be evaluated using the following criteria:

50% Implementation of program requirements.
50% Documentation.
1 The program and/or documentation was plagiarized.