Mathodactyl Software Design Specification - Notes | CS 430, Study Guides, Projects, Research of Software Engineering

Material Type: Project; Professor: Cukic; Class: Advanced Software Engineering; Subject: Computer Science; University: West Virginia University; Term: Spring 2008;

Typology: Study Guides, Projects, Research

Pre 2010

Uploaded on 07/30/2009

koofers-user-qr2-1
koofers-user-qr2-1 🇺🇸

10 documents

1 / 23

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Mathodactyl
Software Design Specification
Team Illusion
March 11, 2008
Joshua Dodson
Philip Fahnestock
Stephen Schoenberger
Nathan Vickers
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17

Partial preview of the text

Download Mathodactyl Software Design Specification - Notes | CS 430 and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity!

Mathodactyl

Software Design Specification

Team Illusion

March 11, 2008

Joshua Dodson

Philip Fahnestock

Stephen Schoenberger

Nathan Vickers

E-mail: [email protected]

Table of Contents

  • 1.0 Introduction....................................................................................................................
    • 1.1 Goals and objectives..................................................................................................
    • 1.2 Statement of scope.....................................................................................................
      • 1.3 Software context.......................................................................................................
    • 1.4 Major constraints.......................................................................................................
  • 2.0 Data design.....................................................................................................................
    • 2.1 Internal software data structure..................................................................................
    • 2.2 Global data structure..................................................................................................
    • 2.3 Temporary data structure...........................................................................................
    • 2.4 Database description..................................................................................................
  • 3.0 Architectural and component-level design....................................................................
    • 3.1 Program Structure......................................................................................................
    • 3.2 Description for Components...................................................................................... - 3.2.1 Login Function.................................................................................................... - 3.2.2 View Grades (Individual) Function.................................................................. - 3.2.3 View Grades (Graph) Function......................................................................... - 3.2.4 Alter Grades Function....................................................................................... - 3.2.5 Problem Sets (View All) Function.................................................................... - 3.2.6 Problem Sets (View by Set) Function............................................................... - 3.2.7 Alter Problem Function.................................................................................... - 3.2.7 View Error Logs Function................................................................................
    • 3.3 Software Interface Description................................................................................ - 3.3.1 External machine interfaces.............................................................................. - 3.3.2 External system interfaces................................................................................ - 3.3.3 Human interface................................................................................................
  • 4.0 User interface design....................................................................................................
    • 4.1 Description of the user interface.............................................................................. - 4.1.1 Screen images................................................................................................... - 4.1.2 Objects and actions...........................................................................................
    • 4.2 Interface design rules...............................................................................................
  • 5.0 Restrictions, limitations, and constraints.....................................................................
  • 6.0 Testing Issues............................................................................................................... - 6.1 Classes of tests........................................................................................................
    • 6.2 Performance bounds.................................................................................................
  • 7.0 Appendices...................................................................................................................
    • 7.1 Requirements traceability matrix.............................................................................
    • 7.2 Packaging and installation issues.............................................................................

1.1 Goals and objectives

As always, Team Illusion is concerned with the users and operators of this

system. This being the case, our number one goal and objective is to deliver a

product which satisfies the customer’s needs and wants. With a firm grasp of the

customer’s satisfaction, our objective thereafter is to deliver a website which

performs exactly as expected and delivers all the information that is needed. In

addition to stability and correctness, further goals include establishing a website

that is easy to use and convenient for the user. By offering charts, drop-down

menus, and more; we hope to build a website which can accomplish this ease of

use. As a final objective we want to ensure our website will maintain functionality

in the future. Therefore, we will perform weekly quality checks on the website to

ensure that it is up to par with the user’s needs.

1.2 Statement of scope

The website’s functionality is based upon a number of major inputs. These

inputs have a very simple and easy to use format. Inputs will either be selected

by clicking appropriately labeled areas of the website; or by using drop-down

menus to choose specific information. Since all of the data from the database

will be available remotely, every drop-down menu from the Mathodactyl program

will be accessible from the website. In other words you will not be able to select

any information from the website that has previously been deleted from the

database. When an input is selected, the database is queried and all information

regarding that input is retrieved and sent to the user as an output. There are

several ways to query the Mathodactyl database: for student information, student

scores, problem sets, and problem descriptions. Also, the website offers

administrators access to the error logs generated by the Mathodactyl learning

utility.

1.3 Software context

The overall context of this program is such that a teacher will be able to check

online to monitor the progress of his or her students. The teacher will be able to

view student records as well as make minor changes to problem sets, in the

event he or she deems certain problems inefficient. In other words, this website

will provide a convenient workplace allowing strong and stable remote operation

of the Mathodactyl utility.

1.4 Major constraints

First, it is implied that the user has an actively deployed Mathodactyl database

within their school. Without this, the website will not function properly. The link

between the two will be established without any action from the user. All

navigation of the website is done via mouse in a Windows or Linux environment.

An active internet connection must also be present to access the database.

A Teachers table will include the teacher’s name and password that can

be used to manually log into the application. The table will make a

reference to the Face_Info table using the Name field.

An Error_Log table will contain an error number, error name, and a count

variable to auto increment the table.

An Admins table will hold the ID, name, and password for the system

administrators.

A Problems_Scores table will contain the grade given for a problem, the

student name, the set number, and the problem number for each question.

The table will make references to the Students table using the Name field,

the SetNum table using the Set_Number field, and the Problems table

using the Problem_Number field.

The Total_Score table will hold the student name, set number, and the

total score for the set for each student. The table will make references to

the SetNum table using the Set_Number field, and the Students table

using the Name field.

The Grade_Total table will contain the name of a student, and the total

score they have accumulated for the problems completed. The table will

make a reference to the Students table using the Name field.

3.0 Architectural and component-level design

3.1 Program Structure

The overarching system architecture to be implemented by the

Mathodactyl teacher website uses a Model-View-Controller pattern, or

MVC. This is combined with components of an event-driven architecture.

Other architectural patterns such as pipes and filters were briefly

considered before settling on a more natural pattern for this application,

MVC.

3.2 Description for Components

The following diagrams combine a PSPEC, component interface

description, with processing details into a single diagram that nicely

illustrates the way the component fits into the Mathodactyl teacher website

architectural pattern.

3.2.2 View Grades (Individual) Function Module – Grades (Individual) Algorithm: Select drop down Individual Grades Get DB table Problem_Score

Controller

Module – Grades (Individual) Algorithm: Receive information from DB table Problem_Score Put in set order

Model

Grades (Individual) Module See all problems per nine weeks in sets of 25. On next display next 25 problems

View

Mathodactyl DB Module Model Web Page Modue View Mathodactyl Module Controller Web Page Modue View Mathodactyl Module Controller Mathodactyl DB Module Model

Grades

(Individual)

3.2.3 View Grades (Graph) Function Module – Grades (Graph) Algorithm: Select drop down Graph Grades Select Nine Weeks Get DB table Total_score

Controller

Module – Grades (Graph) Algorithm: Receive information from DB table Total_score

Model

Grades (Graph) Module Display line graph of grades in set order

View

Mathodactyl DB Module Model Web Page Modue View Mathodactyl Module Controller Web Page Modue View Mathodactyl Module Controller Mathodactyl DB Module Model

Grades (Graph)

3.2.5 Problem Sets (View All) Function Module – Problem Sets (View All) Algorithm: Get Problems from DB table Problems

Controller

Module – Problem Sets (View All) Algorithm: Receive Problems from DB table Problems ordered by nine weeks

Model

Module – Problem Sets (View All) Display all Problems in sets of 25. Upon next display next 25 problems.

View

Mathodactyl DB Module Model Web Page Modue View Mathodactyl Module Controller Web Page Modue View Mathodactyl Module Controller Mathodactyl DB Module Model

Problem Sets

(View All)

3.2.6 Problem Sets (View by Set) Function Module – Problem Sets (View by Set) Algorithm: Get Problems from DB table Problems

Controller

Module – Problem Sets (View by Set) Algorithm: Receive Problems from DB table Problems Select Nine Weeks Select Set

Model

Module – Problem Sets (View by Set) Display Problems from selected set/nine weeks

View

Mathodactyl DB Module Model Web Page Modue View Mathodactyl Module Controller Web Page Modue View Mathodactyl Module Controller Mathodactyl DB Module Model

Problem Sets

(View by Set)

3.2.7 View Error Logs Function Module – Error Logs Get ErrorLog Table Send support ticket

Controller

Module – Error Logs Algorithm: Receive ErroLog Table

Model

Module – Error Logs View Error Logs ordered by ID

View

Mathodactyl DB Module Model Web Page Modue View Mathodactyl Module Controller Web Page Modue View Mathodactyl Module Controller Mathodactyl DB Module Model

Error Logs

3.3 Software Interface Description

In this section the software's interfaces to the outside world are described.

3.3.1 External machine interfaces

Connection to other machines from the system will be done via

HTTP transfer (web browser). There are no special cases that need

to be discussed since the user will access the site from his or her

computer and the site and database server will be residing on the

same physical system.

3.3.2 External system interfaces

There will not be any external system interfacing occurring.

3.3.3 Human interface

All human interfaces to the system proper will be implemented via

HTML markup and presented through a web browser formatted

with style sheets. The next section gives examples of possible

interfaces.

4.2 Interface design rules The interface should be very smooth in operation so the user does not experience any discomfort or irregularities during system use. Rules that should be followed include  Abstraction in keeping components doing one thing at a time.  All elements should be tied together.  Sticking to patterns in the overall look of the site.  Hiding the back-end database connections and querying from the user and making sure these connections operate in real- time.  The user interface will not require the memorization of archaic commands but will rely on the user’s visual intelligence and rely on them clicking on well defined buttons and web controls.  A built-in help system will be provided as well as a contact system.  Most importantly the user will be in control of the situation at hand.

5.0 Restrictions, limitations, and constraints

As the website will be located online, it is secure and independent of any

personal computer loss or malfunctions. However, since the website heavily

depends on the Mathodactyl database, a good connection between these

servers must be established in order to use the website properly. Any faults with

Mathodactyl are not covered with this website, but faults within Mathodactyl will

be logged into our database as well. This can be queried from the website and

observed for possible solutions.