CS4 Case Study

Toward the end of each academic year, the Syllabus Committee in the Department of Computer Science determines which modules will be available to CS4 students in the following year.  (A CS4 student is any student who is taking any fourth-year module in computer science department, whether or not the student is registered for a computer science degree.)

At the end of each academic session, the Head of Department allocates duties to members of the teaching staff and others; in particular, one person is assigned to each of the modules which are supposed to be available in the following year.  (We'll call these people lecturers for simplicity.)

Each lecturer updates the course handbook for his or her module.  The CS4 co-ordinator updates other parts of each handbook, and checks the module entries produced by the lecturers.  Module entries are written in the LATEX formatting language. 

Somebody in the Undergraduate Teaching Office (from now on we'll call any such person "the UTO") produces the paper version of each course handbook; the CS4 co-ordinator produces the HTML version by running the conversion application latex2html on the LATEX source. 

The CS3 co-ordinator is supposed to give a list of the students entering CS4 from CS3 both to the CS4 co-ordinator, and to the UTO.  The CS4 co-ordinator tells the UTO about any student entering CS4 other than from CS3, for example non-graduating students.  The UTO keeps the master list of all CS4 students, and updates the mailing list of students taking CS4 modules, which is known by the email address cs4class. 

Each student is advised by a member of staff acting as a Director of Studies (DoS).  A DoS is assigned to a student in their first year of study and remains in that role until they leave. 

Students provisionally register for modules by filling in paper forms and handing them to the Undergraduate Teaching Office.  The UTO checks that every student who registers is listed as a CS4 student, and that every CS4 student is registered for a reasonable set of modules.  In case of doubt, the student's DoS is consulted, and may have a discussion with the student. 

The UTO then produces a list for lecturers of the students taking their modules.  These lists cannot be guaranteed to reach lecturers sooner than week 3.  This is unfortunately too late for letting lecturers know how many copies of things to make...

The verbal description written above is rambling.  This is very often the case when a developer has taken notes while talking with domain people.  A few diagrams and/or structured text should provide some sort of structure to it all. 

The choice of what models to use depends on the nature of the case study and the mind set of the developer.  There are some differences between this case study and the library book one.  Here the choice is use case, class diagram, CRC cards and activity diagram.  None of the classes have sufficiently interesting life cycles to make it worth while to draw a state diagram.  Although, we don't have state diagrams this time,  an activity diagram has been used given the  strong work flow nature of this case study.  It's only necessary to model to the extent that one is able to start coding.  No more, no less. 

Use Case Diagram:

The use case diagram below provides an overview, or table of contents, for all the use case descriptions that we could then go on to write or simply keep in our heads.  In modern development, it's not necessary to verbalise everything, since we've always access to the domain people if we get stuck. 

Class Diagram:

There exists an error of sorts in the diagram above.  Strictly there should be an association line from Non-graduating student to Module and one from Graduating student to Module.  This is because the multiplicity of 6 at the Module end only applies to Graduating student.  (A non-graduating student can take less than 6).  However, to put in those two lines would be messy and arguably the inaccuracy is best left there,  for the sake of clarity. 

A practical way of dealing with this would be to add a note to the diagram explaining that a non-graduating student may take less than six Modules.  There is a syntax for notes on a UML diagram.  Type UML  note into Google, and see what it comes up with. 

CRC cards:

Activity Diagram:

See, first of all, the notes on activity diagrams elsewhere on this web site.

There are no syntax errors in the diagram below, except omissions.  There are logically two fork/joins one following the other, but not all the syntax associated with those are displayed.  The first  horizontal fork line is missing (do we really need it after all?), then the horizontal join line to terminate the first fork has been combined with the horizontal fork line of the second fork/join structure.  Finally the horizontal join line of the second fork/join is missing.   Thus we have only one horizontal line, instead of four.  Strictly, we should also have a solid start circle at the top and a ringed end circle at the end. 

Note that the three activities leading in from the top left have to be done STRICTLY in the order shown. The one leading in from the top right can be done at any time at all.  All we need is that ALL four of these activities MUST  be done before the outgoing lines at the bottom of the diagram are triggered.  Once they are triggered, it doesn't matter if the print hand book activity is done before generate html version or whether it's the other way round or whether indeed they're done at the same time.

The swim lanes, which ideally should have been drawn vertically (sorry about that!) introduce an element of  object-orientation to the activity diagram, by assigning responsibilities. 

This is a very heavy data system

The major part of the responsibilities of all our classes in this system is to encapsulate data, in other words to hold it in little capsules, called objects.  This shouldn't surprise us since the main purpose of the system is to maintain data about CS4.  That, however, isn't really typical of object-oriented systems.  Classes do nothing but hold data are often but not always a sign that all the behaviour is somewhere else perhaps in a single Controller class.  This is bad design because it tends to mean that the particular current use or the system (the current set of use cases) is being hard coded.  Therefore when your design has such classes you should check that you aren't missing some behaviour that goes with the data being encapsulated.  In this case, what we have is probably reasonable; our system doesn't have very much in the way of behaviour. 

The user interface

We haven't shown the user interface(s), i.e. how the actors get to use these facilities.  If we think about it long enough, it will probably become clear that a single user interface object isn't going to do; different actors need access to different parts of the system's functionality. 

Probably we would end up with something like a model-view-controller interface, in which each actor is provided with a different (but consistent) view on to the system.