An important issue is how to handle errors. There is always the risk that errors may arise even though an application has been thoroughly tested and a profound handling of errors is therefore crucial.
Errors may arise in any of the application tiers. Chiefly, two types of errors can arise in the data tier:
Class Name Description
SqlException Exception that is thrown when the SQL Server returns a warning or an error.
XmlException Exception that is thrown when an error occurs parsing an XML document.
We have introduced theDalExceptionclass as a common container for the exceptions that may arise in the data tier. Hereby, the business tier only has to deal with this single exception.
In order to make tests on the different error types more convenient we operate with the following error codes in theDalExceptionclass:
5.7 Error Handling 75
Error Code Description
4 Validation error on a property. For instance the value of an attribute, that is not allowed to beNULL, has not been set.
8 Row does not exist. For instance non-existing row has been attempted to be retrieved, updated or deleted.
12 Row already exists. For instance a row with an already existing primary key has been attempted to be created and the primary key constraint has thereby been violated.
16 A severe error has occurred. For instance the SQL server may be unreachable or an error has arisen parsing an XML document.
The error codes are arbitrarily chosen. TheDalException class may be instantiated spec-ifying either anSqlException or an XmlException.Recipients of a DalException may (in addition to the returned error code) get the exact error message by looking at theMessage property of the thrownDalExceptionobject.
The recipients of thrown exceptions in the data tier are the classes in the business tier.
The business tier may be able to cope with caught errors, however, some errors can not be handled and in such cases an exception must be thrown to the presentation tier. We have introduced the BizExceptionclass as a common container for unmanageable errors arisen in the business tier. ABizExceptionis supposed to be thrown only if an error is severe and unmanageable. Finally, the presentation tier is to catch exceptions thrown by the business tier, provide a useful message to the user and possibly guide the user in what to do.
As a sum up we have introduced the following exceptions classes in the study planning application:
Exception Name Description
DalException Represents an exception in the data tier. When an error occurs in the data tier a DalExceptionis thrown to the busi-ness tier. The busibusi-ness tier may be able to handle the error and proceed, however, in case of a severe error arisen in the data tier, the business tier is not able to continue and an error must be given to the user.
BizException Represents an exception in the business tier. When an error occurs in the business tier a BizException is thrown to the presentation tier. A BizException is supposed to be thrown only if an error is severe and unmanageable and the current part of business tier is in no way able to continue. The presentation tier is based on a caughtBizException responsi-ble of presenting a useful message to the user.
77
Chapter 6
System Modules
In sections 5.3-5.6 we took a horizontal look by describing the data tier, business tier and presentation tier, respectively, in a general manner. In this chapter we will take a vertical look at the system.
We do so by describing select parts of the system referred to as system modules. As illustrated by figure 6.1, a system module is to be conceived as some entity or functionality transverse to the business and data tier possibly including a number of database tables.
Figure 6.1:Illustration of how a system module is to be conceived.
In the description of the different system modules we will describe select parts of the database design and select parts of the business tier. We will refrain from describing the data tier and the stored procedures for each of the system modules for the following reasons:
1) The data tier and the stored procedures work more or less alike for all the different system modules.
2) Section 5.4 should have given adequate insight in the data tier and how it interacts with the database through stored procedures.
We will cover the following system modules (section number in brackets): “Courses” (6.1),
“Projects” (6.2), “Students” (6.3), “Study Plans” (6.4), “Study Plan Criteria” (6.5), “Study Plan Elaboration” (6.6) and “Users and Security” (6.7).
6.1 Courses
The greater part of a student’s study consists of taking courses – attend lectures, hand in assignments, take examination &c.For that reason courses form a weighty part of a study plan and are thus important with regard to study planning.
Courses are composed of much information and are cumbersome to deal with:
• courses are only taught in certain periods.
• teaching in courses is timetabled in certain modules.
• courses may be taught in several parts.
• courses may have complex interdependencies with other courses.
• &c.
A course is represented by the Course class in the business tier. The chief purpose of the methods in this class is to support the study plan elaboration algorithm.
Overview of this section:
• In subsection 6.1.1 select parts of the database design for courses are described.
• In subsection 6.1.2 a selection of methods provided by theCourseclass are described.
6.1.1 Database Design
In the table below some select database tables used to store course data are presented. Confer appendix E.3 for diagrams of all the database tables used for storing course information.
Table Name Description
CourseVersion This is the main table for storing course information, including e.g. course number and objective descrip-tion.
Course_Lecturer Stores the lecturers who are responsible for and teach the courses. The table maps the primary keys of the CourseVerionand theLecturertables.
Course_Keyword Stores the keywords associated with courses by map-ping the primary keys of the CourseVersion and Keywordtables.
Course_Period Contains the periods in which course parts are taught.
Course_Point Stores the credit points of course parts.
Course_RecommendedPlacement This table contain the recommended placement for all courses for distinct study types.
Course Interdepencies
Recall from subsection 4.1.1 that course interdependencies must be specifiable in the form shown in figure 3.11.
6.1 Courses 79 The interdependencies between courses are specified by using the two tables Course_Rela-tionCourseandCourse_RelationCourseItemshown in the table below:
Table Name Description
Course_RelationCourse Each record in this table represents a disjunction list.
Course_RelationCourseItem Entries in this table represent the items in the dis-junction lists.
A course may have multiple entries in the Course_RelationCoursetable meaning that it has a conjunction list of disjunctions lists since there is implicit conjunction between entries in theCourse_RelationCoursetable as illustrated in figure 6.2.
• Items
• Disjunction lists
C11 ∨ C12 ∨ C13
∧ C21 ∨ C22 ∨ C23
• Items
Figure 6.2:Illustration of the representation of course interdependencies.
6.1.2 Select Methods
In this section a selection of methods provided by theCourseclass are presented.
public static Guid[][] GetPointBlockingCourses(Guid courseVersion ID)
Retrieves a list of point blocking courses represented by Course IDs for a given Cour-seVersion ID.
public static Guid[][] GetPrerequisites(
Guid courseVersion ID, PrerequisiteCourseType type)
Gets a list of prerequisite courses of the specified prerequisite type for the specified course version.
public static float GetWorkload(
Guid courseVersion ID, int part)
Retrieves the workload for a course part.
public static float[] GetRecommendedPlacement(
Guid courseVersion ID, int studyType ID)
Retrieves the recommended placement for a course and studytype, expressed as a lower and upper limit of points. Confer sections 6.1.3 and 6.1.4.
public static Guid[][] GetKeywordMatchingCourses(
string[] keywords, string culture ID)
Retrieves a list of the course versions which match the specified keywords in the specified culture. The result is sorted such that courses matching the most keywords appear first in the resulting array.
In the following a selection of the methods generating chains of course prerequisites are presented:
public static Guid[][] GetPrerequisiteCourseCombinations(
Guid courseVersion ID, PrerequisiteCourseType type, bool chain)
Generates a list of prerequisite courses for a given course. The type of prerequisite is specified by the type parameter. The chain parameter specifies the depth of the prerequisite chains generated. If TRUE the complete chains will be generated such that the prerequisites of a prerequisite course are recursively included. IfFALSEonly the first level of prerequisites is generated.
public static Guid[][] SortCombinationsByComplexity(
Hashtable passedGoingPlannedCourses, Guid[][] prerequisiteCombinations)
This method sorts the course chains by ascending complexity such that the short-est chains appear first in the result. The passedGoingPlannedCourses parameter is a hashtable containing all the courses which the student has passed at this point either for real or as estimated by the study plan elaborator. The method then removes the passed courses from the dependency chains and sorts the result.
6.1.3 Measurable Recommended Placements
To perform an automated study planning which takes the recommended placement of courses into consideration the recommended placements must be translated into a measurable quan-tity – such as credit points – for each study type. This can be achieved by associating the recommended placement with a point interval for each study type as shown in the example below:
Study Type Recommended Placement Point Min Point Max
Bachelor of Science 4th to 5th semester 90 150
Master of Science 3rd to 4th semester 60 120
6.1 Courses 81 The example shows that before taking the course Bachelor of Science students should ideally have collected between 90 and 150 credit points whereas Master of Science students need to gather between 60 and 120 credit points to follow the placement recommendation of the course. Using credit points instead of semester numbers also has the advantage that the recommendation works even if a student has been delayed in his study which is not the case when using semester numbers.
Figure 6.3:Logical model of theCourseclass and its associations to the Course-RecommendedPlacement,StudyTypeandPointclasses.
Figure 6.3 shows a part of the logical model from figure 3.14 which has been extended to include the translation into point intervals. A course may have one or more recommended placements – one for each study type. EachCourseRecommendPlacementobject is linked to a Point object which represents the recommended point interval for the given StudyType andCourseobjects.
The measurable recommended placement of courses is stored in the following database table:
Table Name Description
Course_RecommendedPlacement Contains the placement recommendation for all courses for each study type to which the course ap-plies. The placement is specified by aPoint_IDwhich refers to a point interval in the Pointtable. Alterna-tively, the placement is specified as a Recommended-PlacementConcept_ID(confer section 6.1.4).
6.1.4 RecommendedPlacementConcept
As mentioned in section 3.3.5 on page 20 the placement recommendation for a course may also be specified as a concept. The concept must be translated into a measurable quantity in order to perform an automated study planning.
TheRecommendedPlacementConceptStudyTypeclass is used to translate the recommended placement concepts into credit points (figure 6.4).
The translation depends on the study type as shown in the example below:
Study Type Recommended Placement Concept Point Min Point Max
Bachelor of Science At the end of the study 140 210
Master of Science At the end of the study 200 300
Figure 6.4:Logical model of the association between theStudyType, Recommended-PlacementConcept, StudyTypeRecommendedPlacementConcept and Point classes.
The recommended placement concepts associated with courses are stored in the following database tables:
Table Name Description
Course_RecommendedPlacement Contains the placement recommendation for all courses for each study type to which the course ap-plies. If the placement is specified as aPoint_IDthe placement has been specifically specified (confer sec-tion 6.1.3). The placement may also be expressed as a RecommendedPlacementConcept_IDwhich refers to an entry in theRecommendedPlacementConcepttable.
RecommendedPlacementConcept Maps the recommended placement concepts into Point_IDswhich refer to thePointtable containing a point interval describing the placement recommenda-tion.