HACS Design Patterns

HACS System Implementing

Design Patterns

Assignment 3

Due: February 20, 2002

Section 1: Group Members

Section 2: Description of Implemented Design Patterns

A.Façade Pattern

B.Bridge Pattern

C.Factory Method Pattern

D.Iterator Pattern

Section 3: Class Diagrams of HACS system

Section 4: Assumptions

Section 5: Suggested Testing Scenarios

HACS System Implementing Design Patterns1

Section 1: Group Members

Brian Kellogg A32301976

Michelle Pirtle A31959590

Section 2: Description of Implemented Design Patterns

1. Façade Pattern

The façade pattern provides a unified interface to the HACS system. HACSFacade class is the main class, which acts as a façade, in the HACS system. It encompasses the entirety of the current system and provides a unified interface to the HACS system. The clients are the main (String argv[]) class and the human users of the system.

The subsystem classes implement the functionality of the HACSFacade subsystem, handle work assigned to the HACSFacade object, and do not have knowledge of the HACSFacade class. These points allow for the subsystem to implement functionality without ability to alter the façade. If alteration of the façade is possible then the needed uniformity of the system would be lost.

Clients to the HACSFacade are instructors and students; which access the façade through the class HACS. Before a client can access menu options, the façade authenticates the user and classifies them as an “instructor” or “student”. If the user logs in incorrectly three times the system will exit. Once authenticated, HACSFacade sends an instruction to a subsystem class for the appropriate menu for the client. Then these clients send requests to the façade by way of selecting a menu option. HACSFacade via executeMenuOption sends the request to the necessary subsystem class through the PersonInterface class for implementation.

Using the façade and implementing it in this manner allows for communication between clients and the façade to be organized and efficient. In the subsystem, the dependencies and lack of redundancy help to improve client usage of the façade. Circular dependencies are avoided to help ensure independence between subsystem classes. Additionally, the clients see a uniform interface, which allows for clarity and ease of use while promoting variations between courses and instructor/student roles.

1. Bridge Pattern

The bridge pattern is used to decouple an abstraction from its implementation so that the two can vary independently. In the HACS system, this pattern is implemented around Menu and MenuImp classes. Menu is the abstraction and MenuImp is the implementation of Menu. The hierarchy of each of these is further extended so that multiple courses can have independent menu options, both for student and instructor.

In this section of the subsystem, PersonInterface acts as a client to instantiate a menu; then calls a function on that menu to print out. displayMenu is the abstract operation of the Menu subclasses. Under MenuImp, the subclasses are inherited and allow for unique actions specific to a course when one of the subclasses is given a command; thus, this is the implementation for each course.

The bridge was very effective to use in this situation. If we had not used the bridge, but still kept this functionality, then the hierarchy of Menu would have needed to be extended – both InstructorMenu and StudentMenu would have a Course1Imp class and Course2Imp class. As one can see, this would have increased the amount of code required and further increased the amount of work if further extensions are ever desired.

1. Factory Method Pattern

The factory method pattern allows for a class to defer instantiation to a subclass. PersonInterface creates an interface for the getMenu factory method, but allows the subclasses to decide which class to instantiate. This is based off of who the client (HACSFacade) says it is, an instructor or a student.

The usage of the factory method at this point within our system is very beneficial to the overall implementation of HACS. This is due to the fact that a client of the façade is categorized immediately, which limits the client’s access to aspects of the subsystem. Limiting access is achieved through the encapsulation of knowledge of which Menu subclass to create. Immediate segregation between the different types of clients within the system increases security because different classes will be instantiated by the factory method based upon the knowledge encapsulated. In the case of HACS, this concerns the menu options displayed.

1. Iterator Pattern

In order to provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation, an Iterator Pattern was implemented. PrintIterator, the iterator object, defines the interface for accessing and traversing the list’s elements for the sole purpose of printing.

There are four methods to the PrintIterator class that allow for this job to be accomplished: First, Next, IsDone and CurrentItem. First allows me to initialize the current element to the first element, Next advances the current element to the next element, IsDone tests if the list has been completely traversed, and CurrentItem is the current item in the list. Due to the fact that HACS system traverses multiple lists of different types, the subclasses to PrintInterator, InstructorIterator and StudentIterator, are used for the different list implementations.

InstructorList and StudentList are the classes that instantiate the respective iterator classes. In order for these classes to properly instantiate the respective iterator classes, CreateIterator is used within each list class. CreateIterator is a factory method, which connects the PrintList and PrintIterator hierarchies.

Data output was a good location to use an iterator pattern. This is because it allows HACS to have multiple traversals of aggregate objects. Without this ability, we would have to keep the list and the needed print iterators all within the same class, making the class very large and congested while limiting reusability of code.

Section 3: Class Diagrams of HACS system

The first diagram is a color diagram showing the design patterns for the complete HACS system. This illustrates which classes are used with the various patterns.

The class diagram of the complete project is divided into 3 separate parts, which make up the entire diagram. This is due to the space limitations. The classes that connect between the diagrams are marked with a dashed box around them telling you which diagram to refer to for more information.

Section 4: Assumptions

The date of the system is static and specified in the file "date". This allows the system to evaluate if an assignment is dispersed, due or overdue.

All input to the system is valid input.

All login names must be unique to the system. The Students first name is their login. Students have unique names, this includes students in other classes and instructor’s last names. Instructors names are also unique by their last name and are unique to the student’s first names. For a larger system, the login value could be equivalent to a MSU PilotID.

The password for the students is "student" and the password for the instructors is "instructor". This is for ease of testing the program without having to know multiple login-password relations. The test files can be altered to have different passwords for each person.

No instructor can be a student without having two unique logins.

For login, file names and passwords, the possible length varies between one character and the maximum size of a Java String.

To show the different implementation of the menus, Dr. Cheng assigns grades using a percentage, and she allows the student to enter comments when turning in an assignment. Dr. McKinley assigns letter grades and has no option for comments from the students.

The student is only allowed to hand in one file for each assignment. Rather than letting the student choose an assignment name, the system chooses it for them. The name of the file is student_name with the assignment_num appended on the end.

Assignments can be graded without being turned in. This allows for multiple exception cases: a) the teacher is corrupt and accepts bribes; b) the assignment was handed in by hand.

Grades can be overwritten, but files (assignments and solutions) are monotonous. Due to the implementation of this system, names of files handed in do not alter once handed in; thus, once an assignment is turned in a student cannot decide to turn in nothing. In addition, files from the instructor being added automatically assume that the next assignment or solution is being added.

Section 5: Suggested Testing Scenarios

It is important to note when testing the program that the files are being altered. For this reason, you should ensure that you have a backup copy of the files incase of system malfunctions or the possibility of wanting to restart from the original state.

Upon starting the program the following information can be supplied one line at a time for each scenario. You will need to restart the program for each of the scenarios:

Scenario 1: (Student Course1)

Objective: To see each menu option implemented for Course1 students.

Brian

student

1

2

2

<Enter any text desired>

3

1

0 (This will exit the system)

To verify that this works you can check the file

Scenario 2: (Instructor Course1)

Objective: To see each menu option implemented for Course1 instructor.

Cheng

instructor

1

2

<enter one word for file name>

<enter “homework” or “programming”>

<enter number equal to the current month but less than 12>

<enter number between 1 and 31>

3

<enter one word for file name>

4

<enter number between 1 and 4>

5

Michelle

3

97

0 (This will exit the system)

Scenario 4: (Instructor Course2)

Objective: To execute different menu functionalities for Course2 instructor.

McKinley

instructor

5

Greg

<enter number between 1 and 4>

<enter any letter grade, such as A or C+>

0 (This will exit the system)

Scenario 5: (Student Course2)

Objective: To execute the different file hand in feature for students.

Kathryn

Student

2

<enter number between 1 and 4>

0 (This will exit the system)

HACS System Implementing Design Patterns1