Object-oriented systems model the real world in terms of objects each with a set of attributes (characteristics that an object has) and operations (things that an object can do), and a business process as a set of objects collaborating with one another to achieve specific objectives within a business context. Now, read p.166-167 (Chapter 5) on the process of identifying objects and revise lecture notes. Consider the following minicase: Each School can offer any number of courses, with each course having at most one Lecturer as the Lecturer in Charge (LIC). Each lecturer can be associated with at most two courses per semester and can hire any number of tutors per course to assist in course delivery. A course can have any number of tutorials, with a restriction that each tutorial has a maximum of twenty-five students for an undergraduate course and forty-five students for a postgraduate course. Furthermore, each tutorial has a maximum of one tutor. The tutor is responsible for capturing the attendance, preparation and participation marks of each student in the tutorial. Lastly, each student can be enrolled in a maximum number of four courses per semester. Students, lecturers and tutors are all identified by a Unique ID. Furthermore, additional information such as their first and last names, date of birth, age and address are also captured. Additionally, each Course has a Unique ID, associated list of Student IDs, and Start and End Date. Similarly, each Tutorial has a Unique ID, associated list of Student IDs, Start and End Date, tutorial location and the associated Course ID The School admin manages the course and tutorial lists, and has the additional responsibility of allocating LiCs to courses, whereas the Lics select and allocate tutors to course. It is the students' responsibility to enrol into courses and tutorials. Students can also change tutorials any time before Week 1 of the semester and can drop a course without financial implications before Week 4 of the semester. 1. Identify a set of objects considering the minicase above 2. Identify a set of attributes and operations/functions for each of those objects 3. Think about how these objects are related, how they rely on each other and the nature of these relationships. Identify and note groups of object that frequently collaborate with each other. Understand in what order do the collaborate and what messages to they pass between each other. Roughly sketch the interactions between objects using your own notations (make them up!) (refer to p. 172-175, Chapter 5 for guidance). Grade 1.5-2.5 . 1.00-1.5 Quality Indicators Identifies relevant objects and their respective attributes and operations, provides justifications when required Identifies appropriate relationships/dependencies between objects, offers justifications when needed Identifies relevant business processes within the chosen context. Homework formatted to superior standard Identifies objects and their respective attributes and operations, although not exhaustively with some instances of incorrect identification/classification; does not provide justifications when required Identifies appropriate relationships/dependencies between objects although not exhaustively with some instances of incorrect identification/classification; does not provide justifications when required Identifies business processes not always within the scope of the chosen context. Homework formatted to an acceptable standard Fails to demonstrate a reasonable understanding of the underpinning concepts of objects, attributes and operations Fails to demonstrate a reasonable understanding of relationships/dependencies between objects; does not provide any justifications Fails to identify relevant business processes Homework not adequately formatted to meet standard Homework not submitted AND/OR Absent for tutorial 0.50- 1.00 . 0.0 166 Chapter 5 Structural Modeling Furthermore, generalization relationships between classes can be combined to form gener- alization hierarchies. Based on the previous examples, a secretary class and an engineer class can be subclasses of an employee class, which in turn could be a subclass of a person class This would be read as a secretary and an engineer are a-kind-of employee and a customer and an employee are a-kind-of person. The generalization data abstraction is a very powerful mechanism that encourages the analyst to focus on the properties that make each class unique by allowing the similarities to be factored into superclasses. However, to ensure that the semantics of the subclasses are maintained, the analyst should apply the principle of substitutability. By this we mean that the subclass should be capable of substituting for the superclass anywhere that uses the super- class (eganywhere we use the employee superclass, we could also logically use its secretary subclass). By focusing on the a-kind-of interpretation of the generalization relationship, the principle of substitutability is applied. Aggregation Relationships Generally speaking all aggregation relationships reiate parts to wholes or assemblies. For our purposes, we use the a-part-of or has parts semantic relationship to represent the aggregation abstraction. For example, a door is a part of a car, an employee is a-part-of a department, or a department is a part of an organization. Like the generalization relationship, aggregation relationships can be combined into aggregation hierarchies. For example, a piston is a part of an engine, and an engine is a part of a car. Aggregation relationships are bidirectional The flip side of aggregation is decomposition The analyst can use decomposition to uncover parts of a class that should be modeled sepe rately. For example, if a door and an engine are a part of a car, then a car has parts door and engine. The analyst can bounce around between the various parts to uncover new parts. For example, the analyst can ask, What other parts are there to a car? or To which other assem blies can a door belong? Association Relationships There are other types of relationships that do not fit neatly into a generalization (a-kind-of) or aggregation (a-part-of) framework. Technically speaking, these relationships are usually a weaker form of the aggregation relationship For example, a patient schedules an appointment. It could be argued that a patient is a part of an appoint ment. However, there is a clear semantic difference between this type of relationship and one that models the relationship between doors and cars or even workers and unions. Thus, they are simply considered to be associations between instances of classes. OBJECT IDENTIFICATION Different approaches have been suggested to aid the analyst in identifying a set of candidate objects for the structural model. The four most common approaches are textual analysis, brainstorming, common object lists, and patterns. Most analysts use a combination of these techniques to make sure that no important objects and object attributes operations, and relationships have been overlooked. Textual Analysis The analyst performs textual analysis by reviewing the use-case diagrams and examining the text in the use-case descriptions to identify potential objects, attributes , operations, and relationships. The nouns in the use case suggest possible classes, and the verbs suggest pos sible operations. Figure 5-1 presents a summary of useful guidelines. The textual analysis of Object Identification 167 A common or improper noun implies a class of objects A proper noun or direct reference implies an instance of a class. . A collective noun implies a class of objects made up of groups of instances of another class . An adjective implies an attribute of an object. A doing verb implies an operation A being verb implies a classification relationship between an object and its class A having verb implies an aggregation or association relationship . A transitive verb implies an operation An intransitive verb implies an exception A predicate or descriptive verb phrase implies an operation An adverb implies an attribute of a relationship or an operation, a Adapted from. These guidelines are based on Russell. Abbott Program Design by Indomal English Description" Citation of the ACM 26, no. 1118 883-394 Peter P. Cherish Strand Entity Relationship Diagrams." Information Sciences Anternational Journal 23, 2-396 127-12 lan Graham, Migrating to Object Technology Reading, MA:Addison Wesley Long 1996 FIGURE 5-1 Textual Analysis Guidelines use-case descriptions has been criticized as being too simple, but because its primary pur- pose is to create an initial rough-cut structural model , its simplicity is a major advantage For example, if we applied these rules to the Make Old Patient Appt use case described in Chapter 4 and replicated in Figure 5-2, we can easily identify potential objects for an old patient, doctor, appointment, patient, office, receptionist, name, address, patient informa- tion, payment, date, and time. We also can easily identify potential operations that can be associated with the identified objects. For example, patient contacts office, makes a new appointment, cancels an existing appointment changes an existing appointment, matches requested appointment times and dates with requested times and dates, and finds current appointment. Brainstorming Brainstorming is a discovery technique that has been used successfully in identifying candi- date classes. Essentially, in this context, brainstorming is a process that a set of individuals sitting around a table suggest potential classes that could be useful for the problem under consideration. Typically, a brainstorming session is kicked off by a facilitator who asks the set of individuals to address a specific question or statement that frames the session. For example, using the appointment problem described previously, the facilitator could ask the development team and users to think about their experiences of making appointments and to identify candidate classes based on their past experiences. Notice that this approach does not use the functional models developed earlier. It simply asks the participants to identify the objects with which they have interacted. For example, a potential set of objects that come to mind are doctors, nurses, receptionists, appointment, illness, treatment, prescrip- tions, insurance card, and medical records. Once a sufficient number of candidate objects have been identified, the participants should discuss and select which of the candidate objects should be considered further. Once these have been identified, further brainstorm- ing can take place to identify potential attributes, operations, and relationships for each of the identified objects. Bellin and Simone have suggested a set of useful principles to guide a brainstorming session. First, all suggestions should be taken seriously. At this point in the development D. Bellin and S S Simone, The CRC Card Book (Reading, MA: Addison Worley, 1997) Object-oriented systems model the real world in terms of objects each with a set of attributes (characteristics that an object has) and operations (things that an object can do), and a business process as a set of objects collaborating with one another to achieve specific objectives within a business context. Now, read p.166-167 (Chapter 5) on the process of identifying objects and revise lecture notes. Consider the following minicase: Each School can offer any number of courses, with each course having at most one Lecturer as the Lecturer in Charge (LIC). Each lecturer can be associated with at most two courses per semester and can hire any number of tutors per course to assist in course delivery. A course can have any number of tutorials, with a restriction that each tutorial has a maximum of twenty-five students for an undergraduate course and forty-five students for a postgraduate course. Furthermore, each tutorial has a maximum of one tutor. The tutor is responsible for capturing the attendance, preparation and participation marks of each student in the tutorial. Lastly, each student can be enrolled in a maximum number of four courses per semester. Students, lecturers and tutors are all identified by a Unique ID. Furthermore, additional information such as their first and last names, date of birth, age and address are also captured. Additionally, each Course has a Unique ID, associated list of Student IDs, and Start and End Date. Similarly, each Tutorial has a Unique ID, associated list of Student IDs, Start and End Date, tutorial location and the associated Course ID The School admin manages the course and tutorial lists, and has the additional responsibility of allocating LiCs to courses, whereas the Lics select and allocate tutors to course. It is the students' responsibility to enrol into courses and tutorials. Students can also change tutorials any time before Week 1 of the semester and can drop a course without financial implications before Week 4 of the semester. 1. Identify a set of objects considering the minicase above 2. Identify a set of attributes and operations/functions for each of those objects 3. Think about how these objects are related, how they rely on each other and the nature of these relationships. Identify and note groups of object that frequently collaborate with each other. Understand in what order do the collaborate and what messages to they pass between each other. Roughly sketch the interactions between objects using your own notations (make them up!) (refer to p. 172-175, Chapter 5 for guidance). Grade 1.5-2.5 . 1.00-1.5 Quality Indicators Identifies relevant objects and their respective attributes and operations, provides justifications when required Identifies appropriate relationships/dependencies between objects, offers justifications when needed Identifies relevant business processes within the chosen context. Homework formatted to superior standard Identifies objects and their respective attributes and operations, although not exhaustively with some instances of incorrect identification/classification; does not provide justifications when required Identifies appropriate relationships/dependencies between objects although not exhaustively with some instances of incorrect identification/classification; does not provide justifications when required Identifies business processes not always within the scope of the chosen context. Homework formatted to an acceptable standard Fails to demonstrate a reasonable understanding of the underpinning concepts of objects, attributes and operations Fails to demonstrate a reasonable understanding of relationships/dependencies between objects; does not provide any justifications Fails to identify relevant business processes Homework not adequately formatted to meet standard Homework not submitted AND/OR Absent for tutorial 0.50- 1.00 . 0.0 166 Chapter 5 Structural Modeling Furthermore, generalization relationships between classes can be combined to form gener- alization hierarchies. Based on the previous examples, a secretary class and an engineer class can be subclasses of an employee class, which in turn could be a subclass of a person class This would be read as a secretary and an engineer are a-kind-of employee and a customer and an employee are a-kind-of person. The generalization data abstraction is a very powerful mechanism that encourages the analyst to focus on the properties that make each class unique by allowing the similarities to be factored into superclasses. However, to ensure that the semantics of the subclasses are maintained, the analyst should apply the principle of substitutability. By this we mean that the subclass should be capable of substituting for the superclass anywhere that uses the super- class (eganywhere we use the employee superclass, we could also logically use its secretary subclass). By focusing on the a-kind-of interpretation of the generalization relationship, the principle of substitutability is applied. Aggregation Relationships Generally speaking all aggregation relationships reiate parts to wholes or assemblies. For our purposes, we use the a-part-of or has parts semantic relationship to represent the aggregation abstraction. For example, a door is a part of a car, an employee is a-part-of a department, or a department is a part of an organization. Like the generalization relationship, aggregation relationships can be combined into aggregation hierarchies. For example, a piston is a part of an engine, and an engine is a part of a car. Aggregation relationships are bidirectional The flip side of aggregation is decomposition The analyst can use decomposition to uncover parts of a class that should be modeled sepe rately. For example, if a door and an engine are a part of a car, then a car has parts door and engine. The analyst can bounce around between the various parts to uncover new parts. For example, the analyst can ask, What other parts are there to a car? or To which other assem blies can a door belong? Association Relationships There are other types of relationships that do not fit neatly into a generalization (a-kind-of) or aggregation (a-part-of) framework. Technically speaking, these relationships are usually a weaker form of the aggregation relationship For example, a patient schedules an appointment. It could be argued that a patient is a part of an appoint ment. However, there is a clear semantic difference between this type of relationship and one that models the relationship between doors and cars or even workers and unions. Thus, they are simply considered to be associations between instances of classes. OBJECT IDENTIFICATION Different approaches have been suggested to aid the analyst in identifying a set of candidate objects for the structural model. The four most common approaches are textual analysis, brainstorming, common object lists, and patterns. Most analysts use a combination of these techniques to make sure that no important objects and object attributes operations, and relationships have been overlooked. Textual Analysis The analyst performs textual analysis by reviewing the use-case diagrams and examining the text in the use-case descriptions to identify potential objects, attributes , operations, and relationships. The nouns in the use case suggest possible classes, and the verbs suggest pos sible operations. Figure 5-1 presents a summary of useful guidelines. The textual analysis of Object Identification 167 A common or improper noun implies a class of objects A proper noun or direct reference implies an instance of a class. . A collective noun implies a class of objects made up of groups of instances of another class . An adjective implies an attribute of an object. A doing verb implies an operation A being verb implies a classification relationship between an object and its class A having verb implies an aggregation or association relationship . A transitive verb implies an operation An intransitive verb implies an exception A predicate or descriptive verb phrase implies an operation An adverb implies an attribute of a relationship or an operation, a Adapted from. These guidelines are based on Russell. Abbott Program Design by Indomal English Description" Citation of the ACM 26, no. 1118 883-394 Peter P. Cherish Strand Entity Relationship Diagrams." Information Sciences Anternational Journal 23, 2-396 127-12 lan Graham, Migrating to Object Technology Reading, MA:Addison Wesley Long 1996 FIGURE 5-1 Textual Analysis Guidelines use-case descriptions has been criticized as being too simple, but because its primary pur- pose is to create an initial rough-cut structural model , its simplicity is a major advantage For example, if we applied these rules to the Make Old Patient Appt use case described in Chapter 4 and replicated in Figure 5-2, we can easily identify potential objects for an old patient, doctor, appointment, patient, office, receptionist, name, address, patient informa- tion, payment, date, and time. We also can easily identify potential operations that can be associated with the identified objects. For example, patient contacts office, makes a new appointment, cancels an existing appointment changes an existing appointment, matches requested appointment times and dates with requested times and dates, and finds current appointment. Brainstorming Brainstorming is a discovery technique that has been used successfully in identifying candi- date classes. Essentially, in this context, brainstorming is a process that a set of individuals sitting around a table suggest potential classes that could be useful for the problem under consideration. Typically, a brainstorming session is kicked off by a facilitator who asks the set of individuals to address a specific question or statement that frames the session. For example, using the appointment problem described previously, the facilitator could ask the development team and users to think about their experiences of making appointments and to identify candidate classes based on their past experiences. Notice that this approach does not use the functional models developed earlier. It simply asks the participants to identify the objects with which they have interacted. For example, a potential set of objects that come to mind are doctors, nurses, receptionists, appointment, illness, treatment, prescrip- tions, insurance card, and medical records. Once a sufficient number of candidate objects have been identified, the participants should discuss and select which of the candidate objects should be considered further. Once these have been identified, further brainstorm- ing can take place to identify potential attributes, operations, and relationships for each of the identified objects. Bellin and Simone have suggested a set of useful principles to guide a brainstorming session. First, all suggestions should be taken seriously. At this point in the development D. Bellin and S S Simone, The CRC Card Book (Reading, MA: Addison Worley, 1997)