Exclusive courses

[HwijungK]

Description

Overview of Course Exclusivity

Course exclusivity (and non-exclusivity) follows the DegreeWorks qualifiers pattern (see #350 for detail). By default, all courses are assumed to be exclusive (you cannot use it to fullfill multiple requirements). a NONEXCLUSIVE qualifier marks that classes that are found in the associated requirement can be used in other blocks that are specified in the qualifier.

For example:

The courses used in '11 Upper-Div Electives' can be shared with this block (major in comp sci). Thus, these classes can be shared with '2 Projects Courses' which is another requirement in this block. For example, COMPSCI 114 which is in both requirements can be shared. Note that the '2 Projects Courses' requirement doesn't have a non-exclusive qualifier.

Notice this qualifier is found in the header, instead of inside a specific requirement. This qualifier applies to the entire specialization, and states that any course taken for the specialization in algorithms can also be used for any other major (including the parent major, computer science). COMPSCI 165, which can be taken for the specialization will therefor also apply to '11 Upper-Div Electives' and '2 Project Courses' in the major block.

Remember all courses are exclusive by default, and can become non-exclusive with the qualifier. If there is a non-exclusive qualifier in the header, all courses in the block are non-exclusive. However, with a EXCLUSIVE qualifier in a requirement of a block that contains a NONEXCLUSIVE hear qualifier, that specific block opts out of the NONEXCLUSIVE qualifier. This pattern is only seen in the aerospace engr and mechanical engr majors.

List of variants of exclusive and non-exclusive qualifiers

• NONEXCLUSIVE ShareWith (THISBLOCK) - classes in this requirement apply to all other requirements in the same block
• EXCLUSIVE DontShareWith - overrides a block wide ShareWith (Major) qualifier and asserts that requirements that satisfy this requirement cannot be used in another requirements
  HighPriority, LowPriority, and LowestPriority might be used to determine which requirement a class will apply to if it can only be used in one
  • EX.
    This is only seen for the electives in a double major between ME and aerospace
    electives for one major cannot be from a core class in the other major
    This overrides the ShareWith (Major) found in the header of both majors
    DW splits the technical electives into 2 requirements (4 units in ENGRE and 8 units from a wider category)
    here the core class of the other major has no priority qualifier, the 4 units in ENGRE has a low priority qualifier, and the 8 units requirement have lowest priority
• NONEXCLUSIVE ShareWith (MAJOR) | (MINOR) | (SPEC) | (COLLEGE) - this requirement / block is shared with all other majors, minor, spec, or college requirement block
• NONEXCLUSIVE ShareWith (MAJOR | MINOR | ... = ###) - this requirement/ block is shared with a specific major, minor, spec, or college block specified with id. For major and minor, ‘BA-’ or ‘BS-’ is excluded; for college the code in the numerical representation of the college (ex 95 for school of bio i think). the @ wildcard can be used to denote any character (ex. SPEC = 201@)
• NONEXCLUSIVE ShareWith (LIBL) - probably share with Liberal Learning , its in drama, art, and international relations headers, and in Emphasis in Latin Language and Literature of Classics
• NONEXCLUSIVE ShareWith (OTHER = AHPER|AHGEO)
  the specialization that have special exceptions inside Scraper.ts is also found as an other block, hinting that this might be something worth looking into
• NONEXCLUSIVE ShareWith (Other = 3450|4290)
  no idea what these are. may be worth further investigations|
• NONEXCLUSIVE ShareWith # Classes with (...) - # classes can be shared between the 2 blocks. In practice # is only ever 2, and this pattern only appears in headers

Related Issue

DegreeWorks Qualifier issue #350 , specifically issue #296.

Motivation and Context

see #296

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code involves a change to the database schema.
• My code requires a change to the documentation.