SI540: Fall 1999

HW5 Solution Set

Junho Song and Paul Resnick


Written exercise


1. Identify the subcomponents of the Student Administration component, and each of their subcomponents (hint: this information is all found on the MPathways timeline.

Top level components are listed, immediately followed by the subcomponents of each.

Recruiting/Admissions – Prospect development, event planning, application processing, admission decision

Financial Aid – Establish need/pkg aid, process loans, disburse awards, tution waivers, student employment

Records/Curriculum/Acad Advising – Careers, course/class mgmt, degree audit/requirements, enrollment/registration, transcripts

Student Financials – Fees, deposits, statements, collections, credits, adjustments


2. For any one of the lowest-level (most specific) subcomponents, describe in more detail its functions

Enrollment/registration – stores information about students enrollment/registration. It should let students modify the registration information as they drop/add courses.


3. For the subcomponent you chose, specify at least two interfaces (name, parameters, return values) for it that allow users or other components to interact with it. Specify the interface at an appropriate level of abstraction (i.e., just a little more specific than your description of the function of the component, not at the level of bits and bytes).

List Registration: studentIDà {courses registered for}

Check Course Availability: CourseNumber, Credit, StudentID à course availability (Y or N)

Add: studentID, CourseNumber, Credit à confirmation

(This last function also changes the state of the database, so that future requests to List Registration will include one more course.)

4. For one of the two interfaces that you specified, what features of how the component's function is implemented would be important to encapsulate, and why?

For example, in checking course availability, this currently works by counting the number of students enrolled and comparing it to the maximum. If there are too many, it checks whether there is a valid override for a particular student. But students should not necessarily learn the max number for the class, in case that maximum is changed. And in the future, it may be that professors will be able to specifically request that particular students not be allowed in their sections, and it would be better if the student did not know this!

5. For one of the two interfaces that you specified, sketch out a scenario of future functionality not completely supported by your interface, and say what changes could be made that are consistent with the open-closed principle.

Let’s assume that students want to know what other courses are available if the specified course is not available. In order to maintain open-closed principle, we could add a completely new interface, or we would extend the existing interface with an optional parameter like following. Note that, in this example, if the student don’t specify the schedule parameter, it will just return course availability.

Check Course Availability: CourseNumber, Credit, StudentId, [time-optional] à course availability, [other available courses if the time was specified]

6. For the subcomponent you chose, how will it interact with other components? (In question 3, you specified the interfaces for your component that are visible to other components, and hence that other components can use. Here, I want you to consider the reverse direction: specify some interfaces of other components that would be used by this component.)

Checking financial holding status on the student account will be used when implementing the functionality behind the ‘add’ interface. When a student wants to add/register a class, the system should check for his/her financial status so that it can force students pay all the past due amount before the registration. Thus, the following would be a useful interface of the Student Financials component, probably the statements subcomponent.

Check financial status: studentID à holding status;

7. Consider the data in a personnel record (the information about one employee, their job title, salary, benefits, etc.). Describe it at at least three different layers of abstraction, much as we talked about bank balances at different layers of abstraction in class.

We can think about an entire personnel record as a single piece of information, with associated operations like hiring, firing, and promoting. At this level of abstraction, the unit of information is an employee record.

In order to carry out an operation like promoting an employee, it will be necessary to perform several operations on component pieces of data, including changing the employee’s job title and salary. At this level of abstraction, the unit of information is the job title or the salary. The software code at the higher layer (which deals with personnel records) will invoke these operations in a way that maintains integrity constraints on the related information (e.g., salaries for particular job titles have to fall within a specified range). But the operations at this level of abstraction just work with individual pieces of information.

In order to carry out an operation that changes a job title, for example, a character string in a database will have to be replaced. At this layer of abstraction, the unit of information is a character string. The software code at the next higher layer (the job title layer) enforces constraints like making sure that the new character string is a valid University job title. But the operations at this level of abstraction just replace the old character string with the new.

In order to replace the old character string with a new one, bits in a particular storage location will have to be changed. At this layer of abstraction, the unit of information is the bit string. The software code at the next higher layer treats those bit-strings as character sequences. But the operations at this level of abstraction just replace bit strings.

Of course, this can keep going: the bits are represented by electrical signals, or magenetic polarities, etc.

8. Suppose that within the University there are five existing departmental systems that each have their own representations for personnel records. For example, in one system, the salary is recorded in a field called Salary, in a denomination of dollars per month, but in another system, the salary is recorded in a field called Pay, in a demoniation of cents per year. Suppose, moreover, that instead of replacing all these systems with MPathways, the University decided to make them all work together, so that it could, for example, transfer employees between units easily or compute average salaries across the University.


  1. If the University created a translation program for every pair of departmental systems, so that a personnel record in any of the five systems could be directly translated into a record for any other departmental system, how many translation programs would be needed?
  2. 4 + 3 + 2 + 1 = 10 or n(n-1)/2 n=5 à 5*4/2 = 10

    (10 pairs actually, since you’d probably want to translate in both directions)


  3. If, instead, the University created a new master format, and created a translation program between each departmental system and the new master format, how many translation programs would be needed? In order to translate one person's data from one system to another, how many translations would be necessary?

5 programs (or pairs of programs). To translate from one system to another would require two translations, first to the master format and then from the master format to the second system.

9. The University has implemented software called CITRIX to enable MPathways to run on both Windows and Macintosh computers. See the news release about it.

  1. Draw a client-server diagram for this architecture, and describe what software runs on each host.






Note that this is analogous to the MIRLYNWeb architecture we showed in class. There is an application server (PeopleSoft’s in this case, the MIRLYN mainframe in the other) that already has a predefined interface for talking with clients (an Excel-based interface in the case of PeopleSoft; a dumb terminal interface in the case of MIRLYN). We set up a "proxy" in the middle to do translation (to a client that may not have Excel running in PeopleSoft case; to a client with a better-than-dumb-terminal GUI in the MIRLYN case). Eventually, in both cases, we may prefer to define a better interface for the application server, and eliminate the proxy in the middle.

Subsequent to this press release, CITRIX purchased some of Insignia's technology, and created a Winframe client for the Macintosh. We have not been able to verify whether the MAC client (provided by Isignia and now by CITRIX) is truly a different piece of software, or whether it's really the Windows client running together with generic Windows emulation software for the MAC. For the purpose of this exercise, it doesn't matter.

You could have gotten full credit if you combined the two boxes at the right of the diagram, so long as you noted that the WinFrame server needed to be running in that box. The PeopleSoft server on its own can't talk to the WinFrame client.

b. Suppose that Microsoft Excel for the Macintosh included some features that are not available in Microsoft Excel for Windows. If someone was using Excel-based MPathways software from a Macintosh, would these Macintosh-only features be available?

No, because Excel runs on the WinFrame Server and it runs the PC version of Excel.

  1. The news release says the eventual goal is to use a Web interface rather than CITRIX. Why is this preferable? If it is preferable, why did they not do it right away?


Explanation exercise

Explain the open-closed principle to someone

An application should be able to accommodate new functions or procedures without changing existing interfaces or implementation.

Open to extension: (Related issues: Easy expandability)

Closed to modification: (Related issues: Maintains encapsulation and enforces abstraction.)