modeling the static structure: relationships ©softmoore consultingslide 1
TRANSCRIPT
![Page 1: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/1.jpg)
Modeling the Static Structure:Relationships
©SoftMoore Consulting Slide 1
![Page 2: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/2.jpg)
Class Relationships
• Association – general relationship
• Aggregation – whole/part relationship
©SoftMoore Consulting Slide 2
Class1 Class2
Aggregate
Part
![Page 3: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/3.jpg)
Class Relationships(continued)
• Inheritance – generalization/specialization relationship
• Dependency – general dependency between classes
©SoftMoore Consulting Slide 3
Superclass
Subclass
DependentClass
IndependentClass
![Page 4: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/4.jpg)
Reflexive Associations
A reflexive association does not imply that an object instance is related to itself.
©SoftMoore Consulting Slide 4
: Personname = “John”
: Personname = “Jane”
is-married-to
Person
is-married-to
Class Level
Object Level
![Page 5: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/5.jpg)
Multiplicity of Associations
• Multiplicity is a constraint on an association that specifies how many instances of one class may relate to a single instance of another class.
• Examples:– a workstation has 1 or more windows– a car has 2 or 4 doors– a person works for 0 or more companies
• Multiplicity is indicated by text expressions at each end of the association.
©SoftMoore Consulting Slide 5
![Page 6: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/6.jpg)
Displaying Multiplicity
©SoftMoore Consulting Slide 6
Class0..1
Optional (zero or one)
Class1
Exactly one
Class*
Many (zero or more)
Class1..*
One or more
Class
Unspecified
Class1..4, 7
Numerically specified
![Page 7: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/7.jpg)
One-to-Many (1:N) Associations
A customer can place many (zero or more) orders, but each order is associated with only one customer.
©SoftMoore Consulting Slide 7
Customer
c1 : Customer
c2 : Customer
c3 : Customer
Order
o1 : Order
o2 : Order
o3 : Order
o4 : Order
places1 *Class Level
Object Level
![Page 8: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/8.jpg)
One-to-One (1:1) Associations
Each elevator has exactly one door, and each door is part of one elevator.
©SoftMoore Consulting Slide 8
Elevator
e1 : Elevator
e2 : Elevator
e3 : Elevator
Door
d1 : Door
d2 : Door
d3 : Door
1 1Class Level
Object Level
![Page 9: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/9.jpg)
Many-to-Many (M:N) Associations
A number of stock items in inventory are supplied by more than one vendor, and vendors often supply more than one stock item.
©SoftMoore Consulting Slide 9
Vendor Stock
s1 : Stock
s2 : Stock
s3 : Stock
s4 : Stock
supplies* *Class Level
Object Level v1 : Vendor
v2 : Vendor
v3 : Vendor
v4 : Vendor
![Page 10: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/10.jpg)
Implementing Multiplicity
• Multiplicity of one is usually implemented using– a reference or pointer in a programming language– a foreign key in a relational database– a combination of the above
• Multiplicity of many is usually implemented using an array or a container class (e.g., list or vector).
©SoftMoore Consulting Slide 10
![Page 11: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/11.jpg)
Example: Implementing Multiplicity
©SoftMoore Consulting Slide 11
Customer Order1 *
class Customer { Order[] orders; ... }
class Order { Customer cust; ... }
cust orders
could be a list or set oforders instead of an array
![Page 12: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/12.jpg)
Role Names
• Each end of an association is a role. A role name may be used to identify how a class at one end of an association participates in the association.
• Roles provide a way of viewing a binary association as a traversal from one object to a set of associated objects.
©SoftMoore Consulting Slide 12
CompanyPersonworks-for
employee employer
![Page 13: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/13.jpg)
Aggregation
• Aggregation is a special kind of association used to represent a “whole/part” or “has-a” relationship among classes.
• Aggregation is specified by adorning an association with a small open diamond at the whole (aggregate) end of the relationship.
©SoftMoore Consulting Slide 13
Order LineItem1 *
![Page 14: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/14.jpg)
Using Aggregation
• Aggregation is a special kind of association– asymmetric relationship– transitive relationship– stronger coupling– additional semantics
• Behavior (copy, delete, etc.) is often propagated across an aggregation but not across an ordinary association.
• The decision to use aggregation is a matter of judgment. When in doubt, use ordinary association.
©SoftMoore Consulting Slide 14
![Page 15: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/15.jpg)
Generalization
• Generalization is a relationship between a more general class (the superclass) and a more specialized class (the subclass), in which objects of the subclass are substitutable in any context that requires an object of the superclass.
• Generalization expresses the “is-a-kind-of” relationship.
• A subclass inherits the attributes, operations, methods, and relationships of its superclass.
©SoftMoore Consulting Slide 15
![Page 16: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/16.jpg)
Notation for Generalization
Graphically, generalization is rendered as a directed line from the subclass to its superclass with a large, open arrowhead pointing toward the superclass.
©SoftMoore Consulting Slide 16
MouseEvent
Event
![Page 17: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/17.jpg)
Using Generalization
• The ability to define superclass/subclass relationships is a fundamental concept in using an object-oriented approach to software development.
• Generalizations can be defined at multiple levels, giving rise to an inheritance hierarchy. They are transitive across multiple levels.
• Inheritance hierarchies with “too many” levels of subclassing can be difficult to understand. Six or more levels would probably be excessive for most applications.
©SoftMoore Consulting Slide 17
![Page 18: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/18.jpg)
Using Generalization(continued)
©SoftMoore Consulting Slide 18
“It is true that an object-oriented language or notation needs the concept of inheritance to be fully object-oriented. But that doesn’t mean that you have to use inheritance on every problem. The real essence of object-oriented analysis is not inheritance but thinking in terms of objects.
– James Rumbaugh [JOOP, Nov/Dec 1991]
![Page 19: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/19.jpg)
Overriding Methods
An operation in a subclass that has the same signature as an operation in a superclass overrides (rather than inherits) the method from the superclass. In effect, the subclass has the same operation but supplies its own method.
©SoftMoore Consulting Slide 19
C1
operation1()operation2()
C2
operation1()
class C2 overridesthe method foroperation1()
![Page 20: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/20.jpg)
Abstract Class
• An abstract class is a class for which object instances may not be created.
• An abstract class is defined only for the purpose of deriving subclasses; it encapsulates commonality for all descendant classes but may not be used for declaring objects.
• An abstract class is specified by writing its name in italics.
©SoftMoore Consulting Slide 20
Shape
![Page 21: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/21.jpg)
Abstract Operation
• An abstract operation defines the signature of an operation whose corresponding method does not exist or is incomplete.
• An abstract operation may have a “default” method that implements common functionality.
• A class with one or more abstract operations is an abstract class; no object instances are permitted.
• As with classes, an abstract operation is specified by writing its signature in italics.
©SoftMoore Consulting Slide 21
![Page 22: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/22.jpg)
Concrete Class
• A concrete class is a class for which it is possible to declare object instances.
• A concrete class derived from an abstract class must provide an implementation (method) for each abstract operation. The abstract operation imposes an obligation on concrete subclasses to provide the corresponding method.
©SoftMoore Consulting Slide 22
![Page 23: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/23.jpg)
Example: Abstract Class
©SoftMoore Consulting Slide 23
Shape
origincolorlineStyle
draw()erase()move()
Rectangle
corner
draw()erase()
Circle
radius
draw()erase()
![Page 24: Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1](https://reader035.vdocument.in/reader035/viewer/2022062315/5697c01e1a28abf838cd10ef/html5/thumbnails/24.jpg)
Using AbstractClasses and Operations
• Minimize the overriding of non-abstract methods. In general, either an operation should be declared as abstract, or else its method should be inherited without overriding.
• Minimize inheritance from classes that are not abstract.
©SoftMoore Consulting Slide 24
“Make non-leaf classes abstract.” – Scott Meyers