We're going to start with one of the more high-level diagrams: the activity diagram.

A quick aside: starting with the high-level diagrams is a good idea from a practical perspective, but it is also required by the UML specification. It may seem like an interesting thing for UML to specify, but that's because it is so important. In order to be most effective, you need to understand the system as a whole before you try to design any of the smaller pieces. Additionally, employers may have complex project management systems and may request formal UML designs from you, which will need to meet those strict requirements.

Activity Diagram Requirements

Quiz taking process (6-10 activities)

Roles:

• Teacher
• System
• Student

Example activities:

• Asking a question
• Generating a question set
• Approving results

With activity diagrams (especially ones that have multiple participants like this one) you want to make sure that you're using swim lanes, and that inside of each of those swim lanes you have activities that are specific to the participant. Make sure that generating a question set falls in line with what the system is responsible for. Each activity should be modeled within the right participant's roles.

After you've finished the activity diagram it's time for the class diagram.

We're moving to the implementation modeling so quickly because this project is not overly complex. That makes it a great opportunity to research various other elements, as you'll see once we get to the deployment diagram.

Class Diagram Requirements

• Student
• Klass
• Grade
• Result
• Teacher
• User
• Quiz
• Question
• Essay
• Multiple Choice
• Answer
• Project
• Practice

In many programming languages, you aren't allowed to use the word "Class", because it is a reserved word. In these situations, a common convention is to spell it "Klass", as I've done here.

Also, be sure to nest your classes properly (e.g. the 'Teacher' and 'Student' classes are both 'Users').

Even though this is a smaller class diagram than for some of the other systems we've built, it has some surprising and hidden complexities, specifically around the 'question' concept. We may have two types of questions, and they both have the ability to have an answer. We don't want to create two answer classes, so the answer has to have an association to both of those question classes.

There is a specific name for this: polymorphic association. Research polymorphic association and see how it can be modeled inside of a UML class diagram. For a good reference, I recommend looking through documentation that is specific to Ruby on Rails. You don't have to be a Rails developer in order to understand them or to implement them, but I love the way that they've implemented polymorphic systems in the Rails framework.

Our third diagram is a state machine diagram.

State Machine Diagram Requirements

Question answering state management

• Waiting for answer
• Answer chosen
• Answer confirmed
• Submit status

This type of diagram models a very small feature, but it gives us a really clear understanding of how the workflow should proceed. In this case, it defines that a user must select an answer and that they aren't allowed to submit the form until they do so.

Our last diagram is a deployment diagram. For this, you'll need to research what is called a "Continuous Integration" service, or CI. I recommend investigating Travis CI, or Codeship (which is what I use for devCamp).

When I push code to, for example, the devCamp servers, I don't push it directly to the server itself. Instead, I push it to the CI server, which performs a number of tasks. The CI server runs database migrations, code checks and tests, and various other processes. If the new code passes the tests, then the CI server will push that code along to the other servers.

Deployment Diagram Requirements

Nodes:

• Continuous Integration (CI) server
• Staging environment
• Pre-production environment
• Production environment