23
Lawrence Chung CS6359.0T1: Module 4 1 Module 4: Relationships

Module 4: Relationships

  • Upload
    iain

  • View
    35

  • Download
    0

Embed Size (px)

DESCRIPTION

Module 4: Relationships. Overview. Relationships Dependency Generalization Association Realization (See Module 2 for this) Modeling Techniques. Relationships and Associations. different words, but more or less same concept. UML Associations Fusion Relationships OMT Associations. - PowerPoint PPT Presentation

Citation preview

Page 1: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 1

Module 4: Relationships

Page 2: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 2

Overview Relationships

Dependency Generalization Association Realization (See Module 2 for this)

Modeling Techniques

Page 3: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 3

Relationships and Associations

UML Associations

Fusion Relationships

OMT Associations

different words, but more or less same concept

Page 4: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 4

Relationships: 3 Kinds

Window

open()close()

ConsoleWindow DialogBox Control

Event

association

dependencygeneralization

Page 5: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 5

AudioClip

Dependency A change in one thing may affect another. “Uses” relationship. May have a name, but not common.

record(m:Microphone)start()stop()

Microphonename

dependency

One important use of dependency

Page 6: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 6

Generalization Relationship between general thing (parent) and more

specific thing (child) Child “is-a-kind-of” parent. Child inherits attributes and operations of parent.

Rectangle

Square

PolygonCircle

Shape base class

leaf class

generalization

Page 7: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 7

Associations (UML)

Professor Courseteaches

relationship name

direction indicator:how to read relation name

teacher class

role names Multiplicitydefines the number of objects associated with an instance of the association.

Default of 1; Zero or more (*); n..m; range from n to m

inclusive

1..**

Represent conceptual relationships between classes

Page 8: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 8

Associations - In Other OOAD

Professor Courseteaches

Fusion Style

binary association

Ternary association

Project Language

Person

Associations may be binary, ternary, or higher order

How are these represented in UML?

Page 9: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 9

Associations – A Question How would you model the following situation?

“You have two files, say Homework1 and MyPet, where Homework1 is accessible only by you, but MyPet is accessible by anybody.”

You could create two classes, File and User. Homework1 and MyPet are files, and you are a user.

Approach 1: Now, would you associate the file access right with File?

Approach 2: Or, would you associate the file access right with User?

Page 10: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 10

Associations – LinksUML has links and associations whose ideas originate largely from OMT and also from Fusion to a certain

extent.

OMT has links link is a physical or conceptual connection between object

instances. E.g., MyPet “is-accessible-to” by any user. OMT has association

describes a group of links with common structure and common semantics

Inherently bi-directional Often implemented as pointers in programming languages

In other advanced OOAD notations, such as RML (Requirements Modeling Language), relationships including associations are treated fully and uniformly as classes. And as such they can have links as instances.

Page 11: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 11

Associations – UML Links

link is a semantic connection among objects. A link is an instance of an association.

Company1..* *

employee employer

: Companyassign(development)

w : Worker

linkNamed object Anonymous object

classassociation class

Worker

+setSalary( s : Salary)+setDept( d : Dept)

works for

association name

Page 12: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 12

Associations – Link Attributes Link Attributes

The most compelling reason for having links and attributes is for-many-to-many relationships

File User

access permission

File User

access permission

UML Association Class

AccessRight

* 1..*

link attribute

association class

class class

Page 13: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 13

Associations - Aggregation

CompanyDepartment1..*

association

multiplicity

aggregation

part whole

- structural association representing “whole/part” relationship.- “has-a” relationship.

Page 14: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 14

Modeling Techniques Simple dependencies Single inheritance Structural relationships

Page 15: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 15

Modeling Simple Dependencies

CourseSchedule

addCourse(c : Course)removeCourse(c : Course

Course

Usually initial class diagrams will not have any significant number of dependencies in the beginning of analysis but will as more details are identified.

Using relationship

The most common dependency between two classes is one where one class uses another as a parameter to an operation.Create dependency pointing from class with operation to parameter.

Page 16: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 16

Modeling Single Inheritance

In UML, abstract classes and theiroperations would be italicized.But not in Rational Rose

CashAccount

presentValue()interestRate

Security

presentValue()history()

Bond

presentValue()

Stock

presentValue()

PreferredStock CommonStock

abstract

is-a-kind-of relationship

Look for common responsibilities, attributes, and operations that are common to two (2) or more classes.

If necessary, create a new class to assign commonalities. Specify that the more-specific classes inherit from the more-general.

Page 17: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 17

Modeling Single Inheritance (cont’d) Abstract

Abstraction—the essential characteristics of a thing. Abstract class—cannot be instantiated. Abstract method—has no implementation defined (i.e., no

method body). Depicted in italics or with stereotypes.

Concrete Not abstract. Can have instances.

Page 18: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 18

Modeling Structural Relationships

The model above is from Rational Rose. How did the composite symbol ( )get loaded versus the aggregation? Use the Role Detail and select aggregation and then the “by value” radio button.

School

InstructorCourse

Department

Student

*

1..*

1..*

1

has

member

*

*attends

*

1..* teaches

1..*

1..* 1..*

1..*

0..1

1 chairperson

assigned to

Considering a bunch of classes and their association relationships

Page 19: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 19

Modeling Structural Relationships

Composite is a stronger form of aggregation. Composite parts live and die with the whole.

Liver

Body

Heart Wheel

Car

Engine

Composite Aggregation

Page 20: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 20

Modeling Structural Relationships Specify an association to create a navigation path between two

objects (in either direction). Specify an association if two objects interact with each other beyond

operation arguments.

Specify multiplicity; 1 is assumed. (Error in text on implicit default.)

Specify aggregation when one of the classes represents a whole over the other classes.

How do you know that objects of one class must interact with another class?• Review the scenarios that were derived from Use Cases.• CRC cards seem much less used in practice..

Page 21: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 21

Hints & Tips Modeling relationships

Use dependencies when relationship is not structural. Use generalization with “is-a” relationship. Don’t introduce cyclical generalizations. Balance generalizations - Not too deep, not too wide. Use associations where structural relationships exist.

Drawing a UML relationship Use rectilinear or oblique lines consistently. Avoid lines that cross. Show only relationships necessary to understand a particular grouping

of things. Elide redundant associations.

Page 22: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 22

Summary Relationships

Dependency Generalization Association -Links and Link Attributes -Aggregation

Modeling techniques Simple dependencies Single inheritance Structural relationships

Page 23: Module 4: Relationships

Lawrence Chung CS6359.0T1: Module 4 23

Points To Ponder Show that cyclical generalizations lead to symmetric relationships

between two classes. Use a couple of examples. Why are cyclical generalizations not desirable? Show that associations do not lead to transitive relationships but

aggregations do. Use a couple of examples. Express compositions using FOL (first-order logic). Show that two classes C1 and C2 can be such that C2 is a subclass

of C2 but at the same time C2 is an aggregation of C1. Use a couple of examples.

Show that two association classes can be related to each other, for example, through an association.

Can you give a counter-example to the statement “Composite parts live and die with the whole”? Or when would the statement not hold?