Object Oriented Analysis and Design Using the UML OOADv4.2 Instructor Notes Object Oriented Analysis and Design Using the UML Introduction to Object Orientation PART 2 Module 3 - Introduction to Object Orientation

Basic Concepts of Object Orientation OOADv4.2 Instructor Notes Basic Concepts of Object Orientation Object Class Attribute Operation Interface (Polymorphism) Component Package Subsystem Relationships Module 3 - Introduction to Object Orientation

OOADv4.2 Instructor Notes Relationships Association Aggregation Composition Dependency Generalization Realization Don’t cover the details of the graphic on this slide. The semantics of each of the relationships will be discussed later. Module 3 - Introduction to Object Orientation

Relationships: Association OOADv4.2 Instructor Notes Relationships: Association Models a semantic connection among classes Associations connect instances of two or more classes together for some duration (as opposed to a dependency relationship, which represents a temporary association between two instances). Dependency relationships will be discussed in the Class Design module. Do not use relationship/role names if they add no value/information to the model. Remember, readability and understandability of the model are key -- only add information that adds value, not clutter to the diagrams. Professor University Works for Class Association Association Name Role Names University Professor Employee Employer Module 3 - Introduction to Object Orientation

Relationships: Aggregation OOADv4.2 Instructor Notes Relationships: Aggregation A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts There are many examples of whole-part relationships: a Library contains Books, within a company Departments are made-up of Employees, a Computer is composed of a number of Devices. However, whether you model a relationship as an association or aggregation is really dependent on the domain being modeled. This is discussed in more detail on a later slide. Whole Part Schedule Student Aggregation Module 3 - Introduction to Object Orientation

Relationships: Composition OOADv4.2 Instructor Notes Relationships: Composition A form of aggregation with strong ownership and coincident lifetimes The parts cannot survive the whole/aggregate Explain to the students that the diamond on this slide must be filled in with black so that the books would print right. If it was filled in with white, it would not be filled in in the books. Note: Compositional aggregation can be shown in by nesting one class within another; however, Rose does not directly support the drawing of a class within a class. Composition is not equivalent to containment by value, as some languages do not support containment by value (e.g., Java). By-value vs. by-reference is an implementation “thing”, whereas composition is a conceptual “thing” that can realized in the implementation using by-value, or by-reference (if the distinction is supported). Note: In Rose, composition is modeled by specifying “by-value” for the containment property of a role of a relationship. Whole Part Schedule Student Aggregation Module 3 - Introduction to Object Orientation

Association: Multiplicity and Navigation OOADv4.2 Instructor Notes Association: Multiplicity and Navigation Multiplicity defines how many objects participate in a relationships The number of instances of one class related to ONE instance of the other class Specified for each end of the association Associations and aggregations are bi-directional by default, but it is often desirable to restrict navigation to one direction If navigation is restricted, an arrowhead is added to indicate the direction of the navigation Module 3 - Introduction to Object Orientation

Association: Multiplicity OOADv4.2 Instructor Notes Association: Multiplicity Unspecified Exactly one Zero or more (many, unlimited) One or more Zero or one Specified range Multiple, disjoint ranges Specification of multiplicity flushes out business rules and assumptions. The lower bound is critical, as the lower bound is what determines whether or not the relationship is optional (e.g., a lower bound of 0 indicates that the relationship is optional). Multiplicity is needed on both ends of a relationship, even if you can only navigate in one direction. Even though there is no need to navigate in that direction, the multiplicity still provides valuable business information. Sometimes navigation decisions are made for performance reasons, which may change over time. The multiplicity should reflect the requirements. Navigation is discussed on later slides. The use of ‘N’ instead of ‘*’ is Booch, not UML (e.g., the use of “0..N” and ‘N’ is not UML). 1 0..* * 1..* 0..1 2..4 2, 4..6 Module 3 - Introduction to Object Orientation

Example: Multiplicity and Navigation OOADv4.2 Instructor Notes Example: Multiplicity and Navigation Multiplicity Schedule Student 1 0..* Navigation Module 3 - Introduction to Object Orientation

Relationships: Dependency OOADv4.2 Instructor Notes Relationships: Dependency A relationship between two model elements where a change in one may cause a change in the other Non-structural, “using” relationship Client Supplier Component Class Package Client Supplier Dependency relationship ClientPackage SupplierPackage Dependency relationship Module 3 - Introduction to Object Orientation

Relationships: Generalization OOADv4.2 Instructor Notes Relationships: Generalization A relationship among classes where one class shares the structure and/or behavior of one or more classes Defines a hierarchy of abstractions in which a subclass inherits from one or more superclasses Single inheritance Multiple inheritance Generalization is an “is-a-kind of” relationship Generalization relationships are also permitted between packages. However, since packages do not themselves have any semantics, generalization between packages is not very common (generalization amongst subsystems, however, is practical). According to Grady Booch: “The terms “inheritance” and “generalization” are, practically speaking, interchangeable. The UML standardized on calling the relationship “generalization” so as not to confuse people with language-specific meanings of inheritance. To confuse matters further, some call this an “is-a” or a “kind of” relationship (especially those into conceptual modeling in the cognitive sciences). So, for most users, it’s fair to use either term. For power users - people who care about things like the UML metamodel and specifying formal semantics of the same, the relationship is called “generalization” and applying such a relationship between, for example, two classes, results in the subclass inheriting the structure and operations of the superclass (i.e. inheritance is the mechanism). Module 3 - Introduction to Object Orientation

Example: Single Inheritance OOADv4.2 Instructor Notes Example: Single Inheritance One class inherits from another Ancestor Account balance name number Withdraw() CreateStatement() Checking Savings GetInterest() Superclass (parent) Generalization Relationship Subclasses Descendents Module 3 - Introduction to Object Orientation

Example: Multiple Inheritance OOADv4.2 Instructor Notes Example: Multiple Inheritance A class can inherit from several other classes FlyingThing Animal multiple inheritance Airplane Helicopter Bird Wolf Horse Use multiple inheritance only when needed, and always with caution ! Module 3 - Introduction to Object Orientation

OOADv4.2 Instructor Notes What Gets Inherited? A subclass inherits its parent’s attributes, operations, and relationships A subclass may: Add additional attributes, operations, relationships Redefine inherited operations (use caution!) Common attributes, operations, and/or relationships are shown at the highest applicable level in the hierarchy Emphasize that when a change is made to a super class all descendent classes inherit the change. Some languages do not support generalization. In these cases you will need to update the design model to reflect the characteristics of the implementation language. In cases where the implementation language does not support generalization between classes you must “design generalization in”. See the language specific appendices for more information. See Class Design for more information. Inheritance leverages the similarities among classes Module 3 - Introduction to Object Orientation

Example: What Gets Inherited OOADv4.2 Instructor Notes Example: What Gets Inherited Ask the class the following to test their understanding: “Without looking at your notes: How many operations does Car have? Answer: 1 How may relationships? Answer: 1 How many operations does Truck have? Answer: 2 How may relationships? Answer: 2” Generalization provides a way to implement polymorphism in cases where polymorphism is implemented the same way for a set of classes. The use of generalization to support polymorphism is discussed in more detail in the Class Design module GroundVehicle Person owner Superclass (parent) weight licenseNumber 0..* 1 register( ) generalization Truck Trailer Car Subclass size tonnage getTax( ) Module 3 - Introduction to Object Orientation

Relationships: Realization OOADv4.2 Instructor Notes Relationships: Realization One classifier serves as the contract that the other classifier agrees to carry out Found between: Interfaces and the classifiers that realize them Use cases and the collaborations that realize them We discussed subsystems earlier in this module. We will look at interfaces and the realization relationship in more detail in the Architectural Design module. Subsystem Interface Class Interface Component Interface Elided form Canonical form Use Case Use-Case Realization Module 3 - Introduction to Object Orientation

Class Diagram for the Sales Example OOADv4.2 Instructor Notes Class Diagram for the Sales Example Use this slide to review the key concepts and UML notation described earlier in this module. For example, ask the students the following: What are the classes in this diagram? What relationship exists between Salesperson and Sale? What relationship exists between Corporate and Customer? How would you interpret the diagram? Salesperson Product Sale Corporate Customer Individual Truck Vehicle Train seller buyer item sold shipping mechanism Module 3 - Introduction to Object Orientation

From Use Cases to: Objects, Attributes, Operations (methods) - “evolutionary ” Class 1 Class 1 Class 1 Class 2 Class 2 Class 2 Slide 4