larman chapter 11

8/12/2019 Larman Chapter 11

1/28


2/28

2

Objectives

Identify associations for a domain model.

Distinguish between need-to-know andcomprehension-only associations.


3/28

3

Introduction

Identify associations of conceptual classes

needed to satisfy the information

requirements of current scenarios.

Also identify the aid in comprehending the

domain model.


4/28

4

Associations

An association is a relationship between

instances of types that indicates some

meaningful and interesting connection


5/28

5

Associations

association

Register SaleRecords-current

1 1

Fig 1.Associations


6/28

6

Useful Associations

Associations for which knowledge of the

relationship needs to be preserved for

some duration.Associations derived from the Common

Associations List.


7/28

7

UML Association Notation

An association is represented as a line

between classes with an association name.

Associations are inherently bidirectional. Optional reading direction arrow is only an

aid to the reader of the diagram.


8/28

8

UML Association Notation

- reading direction arrow- it has nomeaning except to

indicate direction of reading theassociation label

- often excluded

Register SaleRecords-current

1 1

multiplicityassociation name


9/28

9

Finding Associations-Common

Associations List

The common categories that are worth

considering are:

A is a physical part of B . Eg: Wing-Airplane

A is a logical part of B. Eg: SalesLineItem-Sale.

A is physically contained in B . Eg: Register-Store.


10/28

10

Common Associations List 2

A is logically contained in B.Eg:ItemDescription-Catalog.

A is a description of B.Eg:ItemDescription-Item.

A is a line item of a transaction or report

B.Eg:SalesLineItem-Sale.A is a member of B .Eg: Cashier-Store.

A uses or manages B.Eg:Cashier-Register.


11/28

11


A is

known/logged/recorded/reported/captured

in B.Eg: Sale-Register.A is an organizational subunit of B .

Eg:Department-Store.

A communicates with B. Eg:Customer-Cashier.

A is next to B. Eg:City-City.


12/28

12


A is related to a transaction B. Eg: Customer-Payment.

A is a transaction related to anothertransaction B. Eg:Payment-Sale.

A is next to B. Eg:City-City.

A is owned by B. Eg:Register-Store.A is an event related to B. Eg:Sale-Customer.


13/28

13

High-Priority Associations

A is a physical or logical part of B.

A is physically or logically contained in/on

B.A is recorded in B.


14/28

14

Associations Guidelines

The knowledge of the relationship needs to

be preserved for some duration.

Identifying conceptual classes is moreimportant than identifying associations.

Avoid showing redundant or derivable

associations.


15/28

15

Roles

Each end of an association is called a role.

Roles may have

name

multiplicity expression

navigability


16/28

16

Multiplicity

Multiplicity defines the number of instances

of a class A ,that can be associated with

one instance of class B,at a particularmoment.

Eg: In countries with monogamy laws,a

person can be married to 1 person at anyparticular time.But over a span of time one

person can be married to many persons.


17/28

17

Multiplicity

multiplicity of the

role

Store ItemStocks

1 *

Fig 3 Multiplicity on an association.


18/28

18

Multiplicity

Fig 4. Multiplicity values.

T

*

zero or more;many

T

1..*

one or more;

T1..40

one to 40

T

5

exactly 5

T

3,5,8

exactly 3,5 or 8


19/28

19

Naming Associations

Name an association based on TypeName-

VerbPhrase-TypeName format.

Names should start with a capital letter. Legal formats are:

Paid-by

PaidBy


20/28

20

Associations Names

Supervises

*

Paid-byCaptures

1..* 11

Contains

1..*

1

Store

Register Sale Payment

1

Assigned-toAssigned-to

* *1

Employs

1..*

1

Airline

Person Flight Plane

11

Fig 5.Association names.


21/28

21

Multiple Associations

Two types may have multiple associations

between them.


22/28

22

Multiple Associations

1

1

*

*

Flies-from

Flight Airport

Flies-to

Fig 6. Multiple associations.


23/28

23

Implementation

The domain model can be updated to

reflect the newly discovered associations.

But,avoid updating any documentation ormodel unless there is a concrete

justification for future use.

Defer design considerations so thatextraneous information is not included and

maximizing design options later on.


24/28

24

Cleaning Associations 1

Do not overwhelm the domain model with

associations that are not strongly required.

Use need-to-know criterion for maintaining

associations.

Deleting associations that are not strictly

demanded on a need-to-know basis can

create a model that misses the point.


25/28

25

Cleaning Associations 2

Add comprehension-only associations to

enrich critical understanding of the domain.


26/28

26

A partial domain model

Initiated-by

Paid-by

Captured-on

Records-sales-on

Logs-

com leted

1

1

1

11

1 1

1

1

*

1

Describes

1..*

1

Records-sale-of

Described-by

*

1

1..* 1

11

1

Stocks

*1

Contains

1..*1

Product

Catalog

Product

Specfication

Store ItemSales

LineItem

Register ManagerSale

Cashier

CustomerPayment

Used-by

*

Started-by

Houses

1..*

Contained-in

0..1 *

Initiated-by


27/28

27

Without need-to-know

associations

Paid-by

Captured-on

Records-sales-on

Logs-

com leted

1

1

1

1

1 1

1

*

1

Describes

1..*

1

Records-sale-of

Described-by

*

1

1..* 1

1

1

Stocks

*1

Contains

1..*1

Product

Catalog

Product

Specfication

Store ItemSalesLineItem

RegisterSale

Cashier

Payment

Used-by

*

Houses

1..*

Contained-in

0..1 *

Initiated-by


28/28

28

Conclusion

When in doubt if the concept is

required,keep the concept.

When in doubt if the the association is

required,drop it.

Do not keep derivable association.

larman chapter 11

Documents