13 Solution

1. Define each of the following terms:

• a. class: A template or blueprint for creating objects. It defines a set of objects that share the same attributes, operations, relationships, and semantics. A class represents a concept or thing relevant to the application domain, about which the organization wants to maintain state, behavior, and identity. (p. 13-4)
• b. state: An object’s properties (its attributes and relationships) and the current values those properties hold. (p. 13-4)
• c. behavior: The way an object acts and reacts, represented by its operations. An object’s behavior may depend on its current state. (p. 13-4)
• d. encapsulation: The technique of hiding the internal implementation details (structure and secrets of behavior) of an object from its external view, exposing only a defined interface (operations). (p. 13-6)
• e. operation: A function or service that can be requested from an object of a class to effect its behavior. Operations provide an external interface to the class. (p. 13-4, 13-6)
• f. method: The actual implementation of an operation within a class. It specifies the algorithm or procedure that executes when the operation is invoked. (p. 13-17)
• g. constructor operation: An operation that creates a new instance (object) of a class and initializes its state. (p. 13-6)
• h. query operation: An operation that accesses the state of an object (retrieves information) but does not alter the state. It has no side effects. (p. 13-6)
• i. update operation: An operation that alters the state of an object (modifies attribute values or relationships). (p. 13-7)
• j. abstract class: A class that cannot have direct instances, but whose descendants (subclasses) can. It often defines common features (attributes, operations) inherited by subclasses, and may contain abstract operations. (p. 13-14)
• k. concrete class: A class that can have direct instances (objects). (p. 13-14)
• l. abstract operation: An operation whose form or protocol (signature: name, parameters, return type) is defined in an abstract class, but whose implementation (method) is not. Concrete subclasses must provide the implementation. (p. 13-17)
• m. multiplicity: A specification associated with an association role that indicates the number of objects that can participate in a given relationship instance. It defines the lower and upper bounds on the number of participating instances (e.g., 0..1, 1, , 1..). (p. 13-7)
• n. class-scope attribute: An attribute of a class that specifies a value common to the entire class (all instances) rather than a specific value for each instance. Its value is stored once per class. (p. 13-16)
• o. association class: An association that has attributes or operations of its own, or that participates in relationships with other classes. It models properties belonging to the relationship itself, rather than to the participating classes. (p. 13-10)
• p. polymorphism: The ability of an operation with the same name to be implemented differently and behave differently in different classes (typically subclasses within a hierarchy). The specific method executed depends on the class of the object receiving the request. (p. 13-17)
• q. overriding: The process where a subclass provides a specific implementation (method) for an operation that is already defined (and potentially implemented) in its superclass. This allows the subclass to refine or replace the inherited behavior. (p. 13-17)
• r. multiple classification: A situation where an object can be an instance of more than one class simultaneously. (Note: Discouraged by experts and not supported by standard UML semantics). (p. 13-18)
• s. composition: A strong form of aggregation representing a whole-part relationship where the part belongs exclusively to one whole object and its lifecycle is dependent on the whole (it lives and dies with the whole). Represented by a solid diamond. (p. 13-20)
• t. recursive aggregation: An aggregation relationship where instances of a class can be composed of other instances of the same class (or its superclass), often used for hierarchical structures like bill-of-materials. (p. 13-21)

2. Match the following terms to the appropriate definitions:

• concrete class: c. direct instances
• abstract operation: b. form, not implementation
• aggregation: f. part-of relationship
• overriding: e. method replacement
• polymorphism: a. operation applied in different ways
• association class: h. equivalent to associative entity
• composition: d. belongs to only one whole object
• class: g. a set of objects (or more accurately, a template defining a set of objects)

3. Contrast the following terms:

• a. class; object: A class is a blueprint or template defining attributes and operations. An object is a specific instance created from that class, having its own state (specific values for attributes) and identity.
• b. attribute; operation: An attribute represents a piece of data or state held by an object (a property). An operation represents a function or service the object can perform (its behavior).
• c. state; behavior: State refers to the properties (attributes and relationships) and their current values for an object at a point in time. Behavior refers to how an object acts and reacts, defined by its operations and how they change or access the state.
• d. operation; method: An operation defines what service a class provides (its interface signature). A method is the specific implementation or algorithm how that service is carried out within the class.
• e. query operation; update operation: A query operation accesses an object’s state without changing it (read-only). An update operation modifies an object’s state (read-write).
• f. abstract class; concrete class: An abstract class cannot be instantiated directly; it serves as a template for subclasses. A concrete class can be instantiated directly to create objects.
• g. class diagram; object diagram: A class diagram shows the static structure of a system – classes, attributes, operations, and relationships (the blueprint). An object diagram shows specific instances (objects) and their links at a particular point in time (a snapshot based on the blueprint).
• h. association; aggregation: Both represent relationships. An association is a general relationship between classes. Aggregation is a stronger form representing a “whole-part” relationship, implying one object is made up of or contains others. Aggregation is shown with a hollow diamond.
• i. generalization; aggregation: Generalization relates a subclass to its superclass (“is-a” relationship, e.g., GraduateStudent is-a Student), involving inheritance. Aggregation relates a whole object to its component parts (“part-of” relationship, e.g., a Computer has a CPU as part-of it).
• j. aggregation; composition: Both represent whole-part relationships. Composition is a stronger form of aggregation where the part can belong to only one whole and shares the same lifetime as the whole (lives and dies with the whole). Aggregation allows a part to potentially exist independently or be part of multiple wholes. Composition uses a solid diamond; aggregation uses a hollow diamond.
• k. overriding for extension; overriding for restriction: Both involve a subclass replacing an inherited method. Extension adds behavior to the superclass method. Restriction reduces the scope or modifies the protocol (e.g., tightens an argument type) compared to the superclass method. (p. 13-17, 13-18)

4. State the activities involved in each of the following phases of the object-oriented development life cycle:

• Object-oriented analysis: Focuses on understanding and modeling the real-world application domain. Activities include identifying relevant classes, their attributes, operations (responsibilities), and relationships based on system requirements. The goal is to create an abstract model of what the system must do, independent of how it will be implemented. (p. 13-2)
• Object-oriented design: Focuses on defining how the application-oriented analysis model will be realized in the software environment. Activities include refining the analysis model, defining software classes, specifying detailed method logic (algorithms), message passing between objects, data structures, considering implementation constraints (performance, environment, language, DBMS), and designing the system architecture. (p. 13-2)
• Object-oriented implementation: Focuses on translating the detailed object-oriented design model into executable code. Activities include writing code in an object-oriented programming language, implementing classes, methods, and relationships, and integrating with database management systems or other platform components according to the design specifications. (p. 13-3)

5. Compare the object-oriented model with the EER model:

• Similarities:
  • Both model entities/objects (Classes vs. Entity Types).
  • Both model relationships between entities/objects (Associations vs. Relationships).
  • Both support generalization/specialization hierarchies (Superclass/Subclass vs. Supertype/Subtype).
  • Both have mechanisms to model relationships with attributes (Association Classes vs. Associative Entities).
  • Both model attributes of entities/objects.
• Differences:
  • Behavior: The OO model explicitly encapsulates behavior (operations/methods) within classes, while the EER model primarily focuses on data structure.
  • Encapsulation: OO emphasizes hiding internal implementation details. EER models generally expose structure.
  • Concepts: OO includes concepts like polymorphism and overriding, which are not part of the EER model.
  • Expressive Power: The OO model is generally considered more expressive, especially for complex relationships and integrating data and process modeling. (p. 13-1)
  • Development Lifecycle: OO modeling provides a more seamless transition between analysis, design, and implementation phases due to a consistent underlying representation, unlike the potentially abrupt transitions between different model types (e.g., DFDs to structure charts) often used with EER in structured approaches. (p. 13-3)
  • Aggregation/Composition: OO explicitly supports ‘part-of’ relationships through aggregation and composition, which EER typically models as standard relationships.

6. State the conditions under which a designer should model an association relationship as an association class. In what way is the expressive power of an association class stronger than that of an ordinary association relationship?

• Conditions for using an Association Class: An association should be modeled as an association class when:
  1. The association itself has attributes that describe the relationship (e.g., the grade in a Student-Course registration).
  2. The association itself has operations that pertain to the relationship (e.g., checkEligibility for a registration).
  3. The association itself needs to participate in other relationships with other classes (e.g., a Registration issues a Computer Account). (p. 13-10, 13-11)
• Stronger Expressive Power: An association class has stronger expressive power than an ordinary association because it allows the relationship itself to be treated as a class. This means the relationship can have its own features (attributes and operations) and participate in further associations, which is not possible for a simple line representing an ordinary association relationship. It elevates the relationship to a first-class modeling construct with its own properties and connections. (p. 13-10)

7. Using a class diagram, give an example for each of the following types of relationships: unary, binary, and ternary. Specify the multiplicities for all the relationships.

• (Note: These diagrams would be drawn graphically in an exam).

  • Unary Relationship:

    • Example: An Employee manages other Employees.
    • Diagram: A class box labeled Employee. A line starts at the box, loops, and connects back to the same box.
    • Association Name: Manages (optional, can use role names).
    • Role Names: manager (at one end), subordinate (at the other end, optional).
    • Multiplicities: 0..1 next to manager role (an employee has 0 or 1 manager), * next to subordinate role (an employee manages 0 to many subordinates). (See Figure 13-3a)

  • Binary Relationship:

    • Example: A Student registers for a Course.
    • Diagram: Two class boxes: Student and Course. A line connects them.
    • Association Name: Registers For.
    • Multiplicities: * next to Course (a student registers for 0 or more courses), * next to Student (a course has 0 or more students registered). (See Figure 13-3b)

  • Ternary Relationship:

    • Example: A Vendor supplies a Part to a Warehouse.
    • Diagram: Three class boxes: Vendor, Part, Warehouse. A diamond shape in the middle connects via lines to all three boxes.
    • Association Name: Supplies (written inside or near the diamond).
    • Multiplicities: * next to each class box (assuming many-to-many-to-many: a vendor supplies many parts to many warehouses, a part can be supplied by many vendors to many warehouses, etc.). (See Figure 13-3c)

8. Explain the difference between the name of the association relationship and the role names linked to an association.

• The association name (e.g., Registers For, Manages, Supplies) describes the relationship itself, typically using a verb phrase. It often implies a direction for reading the relationship between the connected classes.
• A role name (e.g., manager, subordinate, instructor, advisee) describes the specific function or part that a class plays in the association from the perspective of the other class(es) in the relationship. Role names are placed near the end of the association line connected to the class whose role is being described. They clarify how an object of that class participates in the relationship. (p. 13-7)

9. Add role names to the association relationships you identified in Review Question 7.

• (Note: Added to the descriptions in Q7).

  • Unary (Employee Manages Employee): Role names: manager and subordinate.
  • Binary (Student Registers For Course): Role names could be registrant (near Student) and registeredCourse (near Course), although often omitted if class names are clear.
  • Ternary (Vendor Supplies Part to Warehouse): Role names could be supplier (near Vendor), suppliedPart (near Part), destination (near Warehouse), but are less commonly used than in binary associations.

10. Add operations to some of the classes you identified in Review Question 7.

• (Note: Added to the class boxes from Q7/Q9).

  • Employee Class:
    • calcPay()
    • assignToProject(project)
    • getManagedEmployees()
  • Student Class:
    • calcGpa()
    • registerFor(course)
    • dropCourse(course)
    • getAdvisor()
  • Course Class:
    • getPrerequisites()
    • addSection()
    • getEnrollmentCount()
  • Vendor Class:
    • submitQuote(part)
    • updateAddress(newAddress)
  • Part Class:
    • checkInventoryLevel()
    • reorder()
  • Warehouse Class:
    • receiveShipment(part, quantity)
    • shipStock(part, quantity)