In-Depth

Using GroupSystems in Teaching and Learning an Object-Oriented Analysis and Design Course

• By Narasimha Bolloju
• January 1, 2001

Object-oriented analysis and design (OOAD) has become significantly more relevant to students of information systems in recent years because of the increasing use of OO technologies. Students learning OOAD must overcome a steep object-technology learning curve. Many students of information systems learn some structured analysis-and-design approach to systems development before learning an OO approach. Like information systems professionals who are experienced in using structured methods, such students encounter many difficulties in changing from structured to OO methods. Fayad et al. observe that, on average, the transition of a development team to OO methods takes at least a year.

Different approaches are taken by various organizations and institutions to overcome the difficulties associated with teaching and learning object technology. Some current practices include spreading the training across longer periods,² relating OO concepts to structured development methods,³ OO shock therapy to achieve "object-think,"⁴ and psychological studies such as the "Aha" experience.⁵ Researchers and practitioners are working on finding other effective and efficient means for teaching and learning object technology. For example, Pedagogical Patterns Workshops are regularly held at OOPSLA conferences. There are over 50 different pedagogical patterns reported by teachers of object technology available for reference.⁶ Such a large number of patterns is itself an indication of the complexity and difficulties involved in teaching and learning OO technology. A categorization of these patterns based on teaching/learning elements puts 18 out of 52 patterns under the three categories of group activity, group exercise, and discussion. It is therefore proposed that facilitating a suitable environment for large group discussion can substantially help address teaching and learning difficulties associated with OO technology.

Extensive research in the field of group support systems in recent years has identified many benefits from their usage. These include parallel, or simultaneous, participation; more information brought in by larger groups; the support of organizational memory; and increased individual satisfaction with group size.⁷ Group support systems have been successfully used in many decision-making and group tasks such as strategic planning,⁸ strategic planning and change management,⁹ requirements elicitation,¹⁰ and exploring the difficulties of learning OO techniques.¹¹ Compared to traditional discussions, electronic brainstorming—a facility provided by group support systems—was found to result in improved quality and quantity of contributions.¹² Group support systems, thus, can facilitate an effective and efficient environment for large group discussion for teaching and learning OO technology.

In addition to employing such an environment, OO methodology and real-world problem use in teaching and learning play an important role in overcoming associated difficulties. The instructional design of an OOAD course is presented in the following section, and the experiences of using a group support system in this course are presented in those subsequent.

INSTRUCTIONAL DESIGN OF OOAD COURSE
The OOAD course, taught to undergraduates in the final year of Information Systems, aims to provide the OO approach as an alternative to other systems analysis and design approaches. All the students of this course were exposed to structured systems analysis and design (SSADM) in their second year of the undergraduate program. The course duration was 14 weeks, with a 50-minute lecture and a 100-minute tutorial/laboratory (T/L) session per week. Coad's OO Methodology¹³ was selected as the methodology in this course because of its simplicity, which was expected to minimize the learning difficulty, and because it provides good guidance in the form of commonly used modeling patterns and strategies. A simple modeling tool, Playground, and the hyperlinked version of the strategies and patterns handbook¹⁴ were used during T/L sessions.

The UHS Walk-in Clinic case study¹⁵ was used to apply the concepts and techniques presented in the lectures in the T/L sessions to develop an object model of an administration support system. This services management case study was selected specifically because of its neutrality to any specific information-systems-development methodology. In addition, the case has ample potential for identification of the services of various classes/objects other than the implicit services such as add, delete, or modify. Students were introduced and asked to get familiar with the case study one week prior to the first T/L session.

GroupSystems for Windows¹⁶ was used to support the group discussion required as part of the modeling activity in a number of T/L sessions, beginning in the third week of the course. The course was designed to use six T/L sessions to develop the problem-domain object model (see Fig. 1). These sessions included group activities for identification of system features, objects/classes, connections, and their attributes and services. In each session, the 26 students of the tutorial group formed about 10 teams of two or three. The composition of the teams underwent some changes in subsequent sessions. The teams were required to discuss and make their submissions using one workstation running GroupSystems per team. A member of each team entered his/her team submissions, such as features, suggestions, and comments. The students were also informed that quality submissions would contribute toward the participation marks (10 percent of the total marks). Teams were asked to identify themselves by specifying the names of the team members with their submissions. This approach was used to encourage normal discussion within teams, and to enable teams to refer to the object model under development and the strategies and patterns handbook using an adjacent workstation. This process of combining traditional discussion with electronic discussion was required to handle complexity and to control the quantity and improve the quality of submissions.

Figure 1. Tutorial/laboratory sessions.

The entire course (lectures and T/L sessions) was conducted by the author. Each session started with a brief explanation of session objectives and the inputs and outputs expected. The author played the role of tutor-cum-facilitator to summarize discussion at the end of each T/L session and to prepare input for the next session based on the results.

IDENTIFICATION OF SYSTEM FEATURES
To facilitate the activity of identifying the system features according to Coad's methodology, the teams were provided with the following statement of system purpose: to support the Chief Administrator of the walk-in clinic and its staff in daily operations, organization of medical and support services, and overall planning.

GroupSystems's categorizer tool was used with four categories corresponding to the four types of system features, and an additional category to list problems and difficulties in the current administration system. The number of submissions in each category made by the teams in this session were

• Features for logging information: 34
• Features for conducting business: 25
• Features for analyzing business results: 29
• Features for interacting with other systems: 21
• Problems and difficulties in the current system: 30

The typical length of each submission was 10–15 words, and some submissions included a few additional lines of explanation. Analyzing the process and its outcomes, the following positive aspects were identified:

• Identification of high-level features: Teams became progressively better at identifying higher-level features required at this stage. High-level features (e.g., scheduling medical professionals and optimal allocation of resources) rather than trivial low-level features (e.g., recording of assignment, scheduling, and allocation decisions) were identified.
• Separation of manual processes from system processes: The session helped to differentiate manual processes from processes required as part of the information system to be developed. This separation was useful later, in illustrating and understanding differences between the responsibilities of real-world objects and information-system objects.
• Mapping organizational objectives to information system objectives: Mapping organizational objectives to information system objectives is an important part of this session activity. Submissions relating to both of these types of objectives helped students understand differences between these two types of objectives and illustrated how organizational objectives (e.g., providing better service to patients) can be mapped to information system objectives (e.g., monitoring queue lengths, waiting times, or work distributions).
• Emphasis on management information: Submissions under the category of features for analyzing business results helped teams to focus on management information requirements. The number and quality of submissions made within this category demonstrate the approach's effectiveness in this regard. Submissions covered features such as analysis of resource utilization, statistical information on waiting times for different types of resources, and staff performance assessment and comparison.
• Determination of system scope: Submissions under the category of features for interacting with other systems highlight issues related to delineation of the system boundary and interface requirements. These submissions identified other systems (e.g., medical records system, personnel system) and the type of interaction required (e.g., exchange of medical records).
• Identification of problems and solutions: Submissions under this category (not part of Coad's methodology) resulted in identifying problems with the current system and possible solutions from organization and information-system perspectives. These submissions also helped in possible simplifications or improvements to the current processes and operations, and in further identification of features in other categories.

IDENTIFICATION OF CLASSES
Proper identification of classes (or objects) is a difficult task that has received great attention in OO modeling. Students experienced with entity-relationship (ER) modeling often find it easier to identify classes that are equivalent to entity types. However, at the same time, they find it quite difficult to differentiate between ER modeling and object modeling. A T/L session was conducted to identify and describe problem domain classes based on short-listed system features from the previous session. GroupSystems's topic commentator facility was used to brainstorm, then the categorizer was used to group classes for further description. The teams were given the purpose statement and a summarized feature list required for the administration system (see System Purpose and Feature List sidebar).

As part of this activity, the teams first identified classes using the case-study material, then elaborated the purpose and/or relevance of each identified class. This lasted for about 40 minutes. The identified classes were grouped into 14 categories based on the type of objects they represent (e.g., Staff, Medical Staff, Doctor, Nurse, and Nurse Practitioner were grouped into one category) following a 20-minute discussion. Some of the categories contained up to 10 classes. This short discussion was followed by a 30-minute discussion to examine each class and identify any missing classes. The results of the entire session amounted to an eight-page report with 72 comments from 10 student teams. Some of the interesting aspects of this session were:

• Abstraction of objects into classes: At the beginning of the discussion, the submissions included a combination of objects and classes. From comments submitted by other students and from the list of classes/objects, students realized the differences and started identifying classes rather than objects. Some of the objects were abstracted into appropriate classes (e.g., reception, x-ray room, and waiting room were abstracted to a class TreatmentRoom). This transformation process also led to the identification of many class hierarchies.
• Understanding the purpose and relevance of each class: Students discussed the purpose and relevance of each class in detail. In this process the classes with insufficient relevance or purpose were less discussed. This elaboration process led to an increased understanding of class structures. For example, the class Schedule was decomposed into WorkingDay, Session, and StaffSession classes.
• Determination of the system scope: Sometimes the discussion moved around the boundary of the system scope. Some of the identified classes (e.g., Ambulance, Booking) were clearly outside the system scope with respect to the case study and given purpose statement. Student teams quickly reacted to submissions proposing such classes by explaining why those classes should be left out of the system.

IDENTIFICATION OF CONNECTIONS
The activity of identifying different types of connections (generalization-specialization, aggregation, association) between various classes was performed without the support of GroupSystems. All the teams were given a soft copy of the current object model, which included only a list of classes. The task of identifying connections was distributed among different teams. Teams used the Playground tool and the strategies and patterns handbook.¹⁴ The complete set of connections was evolved using presentations made by individual teams. This approach is more effective and efficient because of GroupSystems' limited capabilities for drawing connections and moving the classes around. The connection identification session included teamwork for 30 minutes and a 60-minute large group discussion. The resulting model (described in the next paragraph) contained all the classes with necessary connections. Some of the difficulties identified and addressed in this session included differentiating aggregations from one-to-many types of associations, eliminating redundant associations, and the proper balancing of generalization and specialization hierarchies.

Figure 2. Object-model notation.

The problem-domain object model for the UHS walk-in clinic is shown in Figure 3. The notation used is depicted in Figure 2. Labels indicating the object connection constraints are the reverse of in Coad's methodology. For example, the connection between Class1 and Class2 indicates that an object of Class1 is connected to one (1) Class2 object and an object of Class2 is connected to zero or more (0-n) Class1 objects. The labels ordered n and xor A n represent, respectively, ordered collections of n objects and exclusive OR pertaining to all object connections labeled with the same tag (e.g., "by" in Fig. 3).

Figure 3. Problem-domain object model.

IDENTIFICATION AND LOCATION OF ATTRIBUTES
The activity of identifying and locating attributes was completely supported by GroupSystems. The discussion started with using class names as different categories. The teams were asked to submit their suggested class/object attributes with a description. The 90-minute discussion in this session produced an eight-page report, which was used for arriving at all the attributes shown in Figure 3. Some of the common difficulties identified and addressed in this session include differentiating ER-modeling and object-modeling concepts (e.g., primary keys vs. object identifiers), improper usage of relational model concepts (e.g., foreign keys), difficulties in identifying class attributes, and usage of derivable attributes (e.g., number of objects, average waiting times).

IDENTIFICATION AND LOCATION OF SERVICES
Identification and location of class and object services is a unique and difficult activity in OO modeling. Students with a background in structured systems analysis-and-design methods are used to modeling functional aspects of the system using techniques such as data-flow diagrams. To identify and locate services, they are required use object-oriented rather than process-oriented thinking.

The system features (see sidebar) were used as different GroupSystems categories for this activity because GroupSystems could provide a proper perspective for role-playing and identification of related class/object services for each feature. Using this approach, teams started visualizing the interactions between the services and identified any missing services needed to support a given system feature. This process helped students better understand implicit and explicit services, particularly how to identify and locate explicit services in the appropriate class/object. In addition, teams also experienced tracing how a service delegates parts of its responsibility to other objects or classes.

Teams were asked to provide their submissions in the following format:

.(;) 

A couple of examples:

1. MedicalStaff.findStaff(registrationId;staff)—a class service to find a staff object for a given registrationId and return the staff object if found.
2. staffSession.addStaff(staff;)—an object service (identified by lowercase letter at the beginning of the class name) to add a staff object to the staffSession after verifying that the staff can be added to it.

During the two 90-minute sessions, the teams identified 44 services (excluding six services provided as an example). The number of services identified per feature ranged from three to 10. Some of the interesting aspects of this session:

• Identification of explicit services: As expected, the teams started identifying implicit services (e.g., create, delete, update, get attribute values, add/connect, disconnect) easily. Students were reminded to use role-play to understand the process and identify only the nonimplicit services. The description of the service required with each submission also helped to reduce submissions related to implicit services.
• Differentiating manual services from information system services: The inability to distinguish between the services provided by real people/units in the organization (e.g., staff in the clinic) and the services provided by the objects representing those people/units (e.g., staff object) resulted in improper identification of the services. However, in the majority cases the required description of the service made the difference obvious to most students. As the session progressed, the number of such submissions was drastically reduced.
• Proper location of services: Role-playing also helped properly locate services. Certain services were required to be located in more than one class/object. For example, calc avg waiting time service is a class service and an object service in queue class. The class service in queue calculates the average waiting time over all the queues and the object service calculates the average for a given queue. This type of submission also helped improve understanding of the polymorphism concept.
• Differentiating class and object services: This task turned out to be easier than initially thought. For this task, the teams followed the simple rule: If a service is required to access or operate on more than one object, or a single specific object capable of providing such a service cannot be identified, then that service is a class service; otherwise it is an object service.
• Improper assumptions on available attributes/services: Elaboration of services also identified missing attributes, primarily due to assumptions about the availability of attributes/services elsewhere. Discussion of the responsibilities of related classes that are supposed to provide the values/computations resulted in identifying remaining services and locating those services.

CONCLUSION
Experiences using GroupSystems to address some of the difficulties in teaching and learning OOAD have been presented. The UHS Walk-in Clinic case study was used in an OOAD course to develop the problem-domain object model for the administration system using Coad's methodology. Usage of GroupSystems resulted in an improved understanding of concepts and their application as compared to earlier offerings of the same course. Annotating initial submissions in various sessions as positive and negative examples, with explanation, resulted in proper application of the concept in subsequent submissions. Teams provided critical comments on their own submissions and on submissions from other teams as the discussion progressed. Teams also provided their interpretation and understanding of concepts and applications in various sessions as part of their submissions. The process of sharing understanding with others contributed to faster learning. Most teams participated actively in the discussions. The teams themselves quickly brought the discussion back from minor diversions in various sessions. Overall, experience with this approach indicates that the benefits from such sessions exceeded initial expectations. Figure 4 summarizes the specific difficulties encountered and addressed in various sessions of this OOAD course.

Figure 4. Specific difficulties encountered and addressed.

Feedback from the students regarding the use of GroupSystems in the T/L sessions was quite positive. They pointed out the major difficulties in learning this subject in a separate 20-minute feedback session, also conducted using GroupSystems. First, the 15-page UHS Walk-in Clinic case study was found to be lengthy, complex, and less interesting. Feedback on this aspect indicates that selection of case study plays an important role in teaching and learning. From this experience, a shorter case study (8–10 pages in length), with little or no dependence on any information-systems-development methodology could be more effective in a course of this duration. Second, many students felt that the duration of the course needed to be increased to two semesters with systems development. This aspect conforms to the findings of Fayad et al.¹ regarding the time required for transition. Third, many students found the transition to OOAD quite difficult. Specifically, students found identification and location of services to be the most difficult of the activities. In addition, they reported difficulties in differentiating the four components of Coad's methodology and in applying strategies and patterns. Last, detailed discussion reports generated by GroupSystems were found to be quite useful in reviewing the process of object modeling and reinforced the learning after each T/L session.

This experience of using GroupSystems in teaching and learning an OOAD course highlights the importance of supporting large group discussion, using a simple OO methodology, and selecting an appropriate case study in overcoming the associated difficulties.

References

1. Fayad, M. E., W.-T. Tsai, and M. L. Fulghum. "Transition to Object-Oriented Software Development," Communications of the ACM, 39(2): 108–121, 1996.
2. Fayad, M.E. and W.-T. Tsai. "Object-Oriented Experiences," Communications of the ACM, 38(5): 50–53, 1995.
3. Robinson, K. and G. Berrisford, Object-Oriented SSADM, Prentice–Hall, Englewood Cliffs, NJ, 1994.
4. Dodani, M. "Object-Oriented Shock Therapy," JOOP, 9(4): 17–19, Juy/Aug.1996.
5. Mann, J. and R. Schneider. "'Aha' Experiences in Object-Oriented Education: Searching for a Theoretical Foundation," Proceedings of the AIS Conference, 768–770, 1997.
6. The Pedagogical Patterns Project. Successes in Teaching Object Technology (PROTO-PATTERNS), 1999.
7. Gray, P. and J. F. Nunamaker. "Group Decision Support Systems," in Decision Support For Management, R. Sprague and H. J. Watson, Eds., Prentice–Hall, Englewood Cliffs, NJ, 330–349, 1996.
8. Dennis, A. R. et al. "Group Support Systems for Strategic Planning," Journal of Management Information Systems, 14(1): 155–184, 1997.
9. de Vreede, G. J. "Collaborative Business Engineering with Animated Electronic Meetings," Journal of Management Information Systems, 14(8): 141–168, 1998.

System Purpose and Feature List Walk-in Clinic Case Study

Overall Purpose Statement: to support the Chief Administrator of the walk-in clinic and its staff in daily operations, organization of medical and support services, and overall planning. Features for logging information: to maintain patient records (patient details, visits, preferences, treatment details, lab reports); to maintain details of staff (physicians, nurses, nurse practitioners, triage coordinators, administration staff); to maintain details of various medical facilities and resources; and to maintain guidelines for patient categorization. Features for conducting business: to schedule medical professionals (physicians, nurses, nurse practitioners, triage coordinators); to receive patients and to queue them for triage coordinators; to assist triage coordinators in recording their assessment of a patient and in assigning the patient to a doctor or a nurse practitioner; to arrange and handle walk-in appointments; to set and monitor service levels (e.g., maximum waiting times, maximum number of walk-in appointments) and to receive alerts/alarms upon violation of service levels. Features for analyzing business results: to get statistical information on patient visits, preferences, type of treatment, waiting times, walk-in appointments, etc.; to assess distribution of workload across various resources; to assess performance of different types of staff in their assigned duties; and to evaluate patient satisfaction with the service provided. Features for interacting with other systems: to receive patient records from the medical records systems of other UHS clinics, and to provide patient records to other UHS clinics.