Backend design Ideas

[evanpurkhiser]

Here's what I wrote for the last question of the midterm. (Good thing I typed it right?!?)

---

The App I would like to design is similar to what I've done for myself, where I list out all course that I've taken and need in a concise manner. This would automate that.

Understanding the domain

Being a student in the CS Department at The University of Akron means there are a few things you need to do before you can graduate:

• You need to accumulate 128 credits before you may graduate. You need to accumulate 42 credits of General Education classes before you are considered for graduation.
• You need to accumulate 75 credits in the Computer Science department before you can be considered to graduate with a degree in computer science.
• You will need at least 11 extra credits of anything to reach 128. Some credits in the GenEds and CS requirements may overlap meaning you may need more than 11 extra credits (As I well know).

  Backend design

We can design the backend of our application in such a way that the requirements of courses are defined in the data. This would allow the application to work for not only the CS Cirriculum, but for other programs as well.

Hopefully the ideas introduced below will encompass the various different course requirement policies (e.g. "one course from two different sets").

For now, keeping track of course pre-requisites will not be part of the requirements.

Models

Since I still don't have a full understanding of how CoreData relationships work, I'm going to give a overview of our models with standard relationship concepts.

• Course - This defines a single course. It will have attributes like code, name, and credits.
• Group - This defines a 'group' of courses. Each group may have a parent group. Each group has a numCoursesRequired, numCreditsRequired, and numGroupsRequired. If any of the *Required fields are nil, then they won't be considered 'required' however the parent group requirements will still be in effect.
• GroupCourse - This is a many-to-many 'pivot/through/junction' table. I'm not sure if we actually need this or not with CoreData.
• SelectedCourse - This contains the courses the student has completed or enrolled to take.

This allows us to define a base set of groups that represent the GenEd curriculum as well as the CS curriculum. For example, a group hierarchy could look something like this

CS Degree (75 required credits) 
    -> Core Requirements (46 credits)
        ...
    -> Foreign Language (14 credits)
        ...
    -> Elective CS Credits (15 credits)
        ...

Gen Ed (42 required credits)
    -> Mathematics (3 credits)
        ...
    -> Natural Science (8 credits)
        ...
        -> Labs (1 course)
            ...
    -> Oral Communications (3 credits)
        ...
    -> Social Sciences (6 credits, 2 courses, 2 groups)
        -> Economics
            ...
        -> Geography
            ...
        -> Government/Politics
            ...
        -> Psychology
            ...
        -> Sociology/Anthropology
            ...
        -> United States History
            ...
        -> Science / Technology / Society
            ...
   -> Humanities (10 credits, 3 courses, 3 groups)
         -> Core Humanities (4 credits, 1 course)
               ...
         -> Philosophy
               ...
         -> Literature
               ...
         -> History / General Humanities
               ...
   -> Area Studies & Cultural Diversity (4 credits, 2 courses)
         ...
   -> Physical Education / Wellness (1 credit)

This concisely identifies the required courses, encompassing all requirement policies in an intuitive way.

User Interface Design

Since the goal of this project is to make managing the courses you've taken and need to take very simple and intuitive, we probably are going to want to design a very simple and intuitive application.

Root window

The root window will be a tab view. The first tab will be a 'course dashboard' page that shows how many courses you've taken and how many we still need to take as an overall.

The second tab will be the 'course group navigator' that will navigate the tree of course groups down to the list of courses for a single group.

Course Navigator

Like the root window tab, each of the course groups can have it's own 'course dashboard' view. So the root 'course dashboard' page would actually just be the course dashboard for the root of the course groups tree. This is cool for example if we only want to see the overview of CS Core courses.

When we navigate far enough into the tree to the point where we reach the leafs (which would be courses) we can then click on these to view information about the course and to select the status of that course (have we taken it, will we take it?).

One more thing we may add is the ability to add a course and add that course to a group. This would be good if a course could be used for a CS requirement even if it isn't a standard requirement.

[evanpurkhiser]

Here are the inital sketches we had done on Friday.

[evanpurkhiser]

I think it's fair to say we've deviated quite a ways from my original design ideas. Better UI ideas can be found in #3 as well. Closing.