uml documentation of a call tracking software

UML Documentation

for

<Project>

Version 1.0 approved

Prepared by <author 1><author 2>

<organization>

<date created>

Revision History

Name Date Reason For Changes Version

Use Cases for <project>

Contents1. Introduction <Introduction of your Project>

2. Actors <Identify Actors and Explain their roles>

3. Use Case <Identify Use cases and document them as per the use case template given>

4. Class Diagram <Identify classes and explain the attributes and methods of each class;

Mention the relationship between the classes properly>

5. Activity Diagram <Draw and explain the activity diagram of your system>

6. Sequence and Collaboration Diagrams <for each use case>

7. State Machine Diagram <Describe possible states and transitions of your system>

8. Component Diagram <Explain each components and their inter-relationships>

9. Deployment Diagram < Show the configuration of the hardware elements (nodes) and shows

how software elements and artifacts are mapped onto those nodes>


Introduction:


Actors:

Admin:

A privileged user who is allowed to create/edit problems, create/edit contests, moderate comment threads and users.

User:

A normal user who is just allowed to attempt practice and contest problems, discuss them on comment threads.

Problem:

A problem represents a programming problem with a problem statement, a set of input and output test cases, a description, a sample test case. Each problem is associated with a comment thread and a leaderboard.

Contest:

A contest is a collection of problems which collectively has a leaderboard of top problem solvers. A contest is managed by an admin. It normally has a deadline.

Leaderboard:

A leaderboard (contest) is a list of top performers of a contest.

A leaderboard (problem) is a list of top submissions to a problem.

It gets updated automatically when problems are attempted.

LoginSystem:

LoginSystem is the actor that is responsible for user registration, user login, user logout.


Use Case List

Use Case ID Primary Actor Use CasesUC-1.1 Non-member A non-member of the system registers with the system.

UC-1.2 Non-member A non-member of the system logs into the system.

UC-1.3 User/Admin An admin or member logs out of the system.

UC-2.1 Admin An admin creates a problem and adds it to the system.

UC-2.2 Admin An admin creates a contest and adds it to the system.

UC-3.1 User A member attempts to solve a problem.

UC-3.2 User/Admin A member or admin comments on a problem.

1. Login System

1.1. Registration

1.2. Use Case(s)Use Case ID: UC-1.1

Use Case Name: A non-member of the system registers with the system. (Registration)

Created By: Last Updated By:Date Created: Last Revision Date:

Actors: Primary: Non-memberSeconday: Login System

Description: A non-member registers with the system. If the person is trying to become an admin he needs to use a special invitation code that is givento him by an existing admin.

Trigger: An action related to using the coding judge system.

Preconditions: 1. All the credentials needed to register with the system: username, password, Name, DOB, email_ID2. Invitation code (in case of admins)

Postconditions: 1. If the details were entered correctly by the person, the system enters his data in the database and person becomes a member.2. If there were missing credentials/incorrect credentials, the person is told about the same and he is expected the fix them.

Normal Flow: 1. Person opens the registration page.2. Person enters registration credentials.3. System validates the input.4. System adds data to database.5. System notifies the user of success.

Alternative Flows: After 2., if any of the credentials are wrong.1. System marks those fields as incorrect and asks him to re-enter them.

Exceptions: During 4. if some faulty database transaction is noticed,1. System does a DB rollback.2. System throws an excpetion page that tells the user about this happening.During 2, if there is are missing fields or fields of incorrect formats,1. System highlights those fields.2. System reports that the user must re-enter these fields.


Includes: NoneFrequency of Use: 50 per day

Special Requirements: None

Assumptions: User understands English and his browser has JavaScript enabled.

Notes and Issues: 1. What is the minimum and maximum length of password and its character-set.

Use Case ID: UC-1.2

Use Case Name: A non-member of the system logs into the system. (Login)


Actors: Primary: Member/AdminSeconday: Login System

Description: Admin/Member logs into the system to gain the privileges that members have by identifying himself to the system.

Trigger: An action related to using the coding judge system.

Preconditions: 1. Admin/Member must have an account with the system.2. Admin/Member must have the user name and password with him.

Postconditions: 1. If the log-in attempt was a valid one, the user gets logged in. The system sets some tokens in it to recognize the user.2. If the log-in attempt was an invalid one, the user gets notified about the same and he may try again.

Normal Flow: 1. Person enters the login page.2. Person enters his username and password.3. Person hits submit.4. Person gets logged in.

Alternative Flows: After 3., if user name doesn't exist:1. System asks the user to register.

Exceptions: After 3, if the password was wrong,1. System asks the user to re-try with the right password.

Includes: UC-1.1Frequency of Use: 1000 per day



Notes and Issues:

Use Case ID: UC-1.3

Use Case Name: An admin or member logs out of the system. (logout)


Actors: Primary: Member/AdminSeconday: Login System

Description: Admin/Member logs out of the system to destroy the tokens that were set for him in the system.


Trigger: User wanting to leave the system.

Preconditions: 1. Admin/Member must have logged in to the system.

Postconditions: 1. The user gets logged out.Normal Flow: 1. User hits log-out button.

2. User gets logged out.Alternative Flows: None

Exceptions: If after 1, if the user's token has expired,1. User is told is already logged out.

Includes: UC-1.1, UC-1.2Frequency of Use: 1000 per day



Notes and Issues:

2. Administrative Tasks

2.1. Feature Process Flow / Use Case Model


Use Case Name: An admin creates a problem and adds it to the system. (create problem)


Actors: Primary: AdminSecondary: Problem, Contest (optional)

Description: Admin adds a problem to the system database either as a practice problem or a contest problem.

Trigger: Admin wants to add a practice problem upon request or to add problems to a contest, etc.

Preconditions: 1. Admin must have logged into his account.2. Admin must have have a list of test inputs and corresponding outputs.3. Admin must have problem statement.4. Admin must have the contest ID to which he wants to add the problem (optional).

Postconditions: 1. A problem appears in the list of problems in the system (contest or practice).2. A problem page is created for the problem with a comment thread and a leaderboard.

Normal Flow: 1. Admin clicks on “add problem” on either a contest or practice set.2. Admin is presented with a form.3. Admin fills up the form with problem statement, problem test inputs and

outputs.4. The problem gets added to the database and it appears in the right lists.

Alternative Flows: Admin leaves some of the fields in the form empty after 2.1. The system rejects the submission.

Exceptions: None. Even though the test cases may be entered wrongly, that will be found out only upon receiving feedback from the users.

Includes: UC-1.1, UC-1.2Frequency of Use: 1 time every 3 days.


Special Requirements: A thoroughly analyzed and tested problem with test cases.Assumptions: User understands English and his browser has JavaScript enabled.

Admin enters problem in English and is understandable.Notes and Issues: A good way to check the validity of entered test cases.

Use Case ID: UC-2.2

Use Case Name: An admin creates a contest and adds it to the system. (create contest)


Actors: Primary: AdminSecondary: Contest

Description: Admin creates a contest.

Trigger: The admin decides it is appropriate to have a contest then.

Preconditions: 1. Admin must have logged into his account.2. Admin must have a name for the contest.3. Admin must have a deadline for the contest.4. Admin must have some information that the users wish to see about the contest.

Postconditions: 1. A problem appears in the list of problems in the system (contest or practice).2. A problem page is created for the problem with a comment thread and a leaderboard.

Normal Flow: 1. Admin clicks on “create contest”.2. Admin enters contest details in the form presented to him3. Admin hits submit.4. Contest gets created.

Alternative Flows: Admin leaves some of the fields in the form empty after 2.1. The system rejects the submission.

Exceptions: Includes: UC-1.1, UC-1.2

Frequency of Use: 1 time every 20 days.

Special Requirements: A well defined contest.Assumptions: User understands English and his browser has JavaScript enabled.

Admin enters contest details in English and is understandable.Notes and Issues:

3. Normal operations

3.1. Feature Process Flow / Use Case Model


Use Case Name: A member attempts to solve a problem. (attempt problem)



Actors: Primary: MemberSecondary: Problem, Contest (optional)

Description: A member submits a solution to a problem to the judge, which the judge then evaluates and shows the results to the memberand updates the leaderboards.

Trigger: Member wants to solve a problem for practice or participating in a contest

Preconditions: 1. Member must have logged into his account.2. Member must have a source program that attempts to solve the problem.

Postconditions: 1. A result is shown to the user.2. Upon achieving a positive result, the problem (and contest) leaderboard(s) are updated.3. The problem is marked "solved" in the user's interface.

Normal Flow: 1. User clicks on “Solve problem”2. User submits his solution (source code)3. User hits “Evaluate”.4. User's attempt correct.5. The problem's (and contest's) leaderboard(s) are updated.

Alternative Flows: User's solution is wrong:1. The user is notified of the error and he is expected to resubmit a solution.

Exceptions: User's solution exceeds time limit:1. The program is interrupted and the user is notified about the same.

Includes: UC-1.1, UC-1.2, UC-2.1Frequency of Use: 3000 times every 1 day.

Special Requirements: Code to be submitted in a supported language.Assumptions: User understands English and his browser has JavaScript enabled.

Notes and Issues:

Use Case ID: UC-3.2

Use Case Name: A member or admin comments on a problem. (comment)


Actors: Primary: AdminSecondary: Problem, Comment Thread

Description: A member or admin comments on a problem, possibly seeking clarification, providing clarification discussing the problem.

Trigger: User wants clarification or wants to discuss a problem.

Preconditions: 1. Member must have logged into his account.2. Member must be at the problem page.

Postconditions: 1. The comment appears on the comment thread of the problem.Normal Flow: 1. User goes to problem page.

2. User enters his comment in the comment box.3. Hits submit.4. Comment appears with a timestamp and user name.

Alternative Flows: User leaves the comment field empty.1. The system rejects the submission.

Exceptions: 1. Database transaction error: Rollback


Includes: UC-1.1, UC-1.2, UC-2.1Frequency of Use: 1000 times every 1 day.

Special Requirements:Assumptions: User understands English and his browser has JavaScript enabled.

Notes and Issues: Spam detection and content filtering.

Use case diagram:


Class diagram

Person:

This represents any person interacting with the system. He is a user of the system.

Attributes:• Name: Name of the person• user_name: A unique user_name corresponding to the person• email_id: Unique Email ID of the person• password: A password

Methods:• solve(): Any user of the system may a solve a problem.

Params: Problem_ID

Admin:

This inherits from Person. It has the extra ability to add problems, contests and manage them.

Methods (extra):• create_problem() : creates a problem

Params: Problem object• edit_problem() : edit an existing problem

Params: Problem object


• create_contest() : create a contestParams: Contest object

• edit_contest() : edit a contestParams: Contest object

Problem:

Represents a problem that exists in the system. It maybe either a contest problem or a practice problem.

Attributes:• input: An input test case.• Output: The output corresponding to the input test case.• Statement: An explanation of the problem• pid: Problem ID• leaderboard: A LeaderBoad object corresponding to the problem (best performers)

Methods:• c_thread(): Returns the CommentThread object present in the problem.• Check(): Checks a submitted solution and returns appropriate response.

Params: input source code

CommentThread:

Represents a comment thread associated with a problem where users may submit comments.

Attributes:• comments[] : An array of Comment objects present in the comment thread

Methods:• add(): Adds a comment

Params: A Comment object• remove(): Removes a comment

Params: A Comment object• edit(): Edits a comment

Params: A Comment objectComment:

Represents a comment present in a comment thread.

Attributes:• user_name: user name of the user who posted the comment• time: Time at the which the comment was posted• date: Date on which the comment was posted• text: The actual comment string

LeaderBoard:


Represents a leaderboard for a problem or a contest. It is generic in the sense that it supports any schema.

Attributes:• schema: Names of columns present in the leaderboard. (an array of strings)• entries: string[][] each row corresponding to an entry.• sort_col: The column by which it is sorted.• Compare: A function that tells us which entry should come before which.• Size: The number of entries in the leaderboard.

Methods:• add() : Add an entry to the leaderboard.• Remove(): Remove an entry from the leaderboard

Contest:

Represents a contest in the system.

Attributes:• problems: An array of Problem objects present in the contest.• Leaderboard: The Leaderboard object associated with the contest• duration: The time (in milliseconds) for which this contest should last.• Start_date: The start date of the contest.• Start_time: The start time of the contest.• Status: A quick description of the contest.

Methods:• add(): Adds a problem to the contest.

Params: A Problem object.• Remove(): Removes a problem from the contest.

Params: A Problem ID.• Update(): Updates a problem.

Params: A Problem objet.MemberUtils:

A utility class that helps in membership management.

Methods:• login(): Logins a user.

Params: user_name (String) and password (String)• logout() : Logs out a user.• Signup(): Registers a user.

Params: A data object in JSON containing the credentials of the user.


Activity Diagram:

The system starts in the initial state.

A person attempts to login. If he login was valid, the systems logs him in.

Then, if the user wants to solve a problem, he attempts one. Otherwise he exits.If the attempt was correct, the problem leaderboard is updated. Otherwise and error message is shown and the user may attempt the problem again.If the problem was a contest problem, the contest leaderboard is also updated.

The user may continue solving problems or exit.

Deployment Diagram


The client sits at a client machine and interacts with a UI Server node.The UI server contains HTML software objects that displays content to the user.The admin also interacts the same way.

The UI server in response to the interactions of the users and admins, communicates with the application server, where project objects such as Problem, CommentThread, LeaderBoard etc. are present.

All data is stored in a Database server.The application server which needed, communicates with the Database server to retrieve or update data.

Collaboration Diagram


1. Admin creates a Problem object.2. Person logs in through the login system.3. Person comments on a problem possibly asking for clarifications.4. Comment gets added to the comment thread of the problem.5. Person solves the problem.6. Problem updates its leaderboad.7. Person logs out through the login system.

State diagram

uml documentation of a call tracking software

Documents