1

AUTOMATED ABSTRACTION OF CLASS DIAGRAMS

Alexander Egyed. Automated abstraction of class diagrams. ACM Transactions on Software Engineering and Methodology, 11(4):449-491, Oct. 2002.

Presented by Xiang Zhang

CSE294@UCSD

May 14, 2010

2

AGENDA

A motivating example Simple abstraction rules

Generalization rules Association rules Aggregation rules Cardinality rules

Serial abstraction Abstracting the example Automation and tool support Validation

3

A MOTIVATING EXAMPLE

shippingaddress

payment

credit card

PayPal

customer shipment

order orderline

hardware

address

shopping cart

1

*

1

*

*

1

*

1

1

1

*

1

1

*

1..*

billingaddress

item

book

software

*

*

1

1

4

DEFINITIONS

Important classes: classes that are of interest

Helper classes: classes that should be abstracted

Path: a sequence of helper classes between two important classes and their relationships(excluding important classes)

payment shipment

PayPal

credit card

order orderlineA subset of the example class diagram

1

1

1..*

1

1

5

GENERALIZATION RULES

A Customer may have a payment implies some features of the class customer An object of type customer has access to an object of

type payment That PayPal is a payment implies that an object of

type PayPal can be referred to as type payment GeneraliztionRight – Class – AssociationLeft ->

AssociateLeft

customerpayment

PayPal

credit card

1*PayPal

credit card

customer

1

1

*

*

customer

payment

PayPal

creditcard

1*

6

REASONING GENERALIZATION RULES

Subclass is an important classsubclass inherits relationships from

superclassbut with one exception…

payment

credit card

PayPal

Ø

GeneralizationRight – Class – GeneralizationLeft -> ØGeneralizationLeft – Class – GeneralizationRight -> Ø

No relationship between PayPal and credit card

7

REASONING GENERALIZATION RULES Superclass is an important class

If the subclass has a relationship to another class, then the superclass does not have such a relationship with that class.

If the subclass has a relationship from another class, then the superclass also has such a relationship with that class.

item

book

author

1..*

*

item author* 1..

*

GeneralizationLeft – class – Association -> AssociationLeft

8

GENERALIZATION RULES

GeneralizationRight – class – GeneralizationRight -> GeneralizationRight

GeneralizationRight – class – DependencyRight -> DependencyRight

GeneralizationRight – class – GeneralizationLeft -> Ø

GeneralizationLeft – class – AssociationLeft -> AssociationLeft

GeneralizationLeft – class – AssociationRight -> Ø

GeneralizationRight – class – Association - > AssociationLeft

……

There are 22 generalization rules…*

* For a complete list of the rules, refer to Alexander’s paper.

9

*

ASSOCIATION RULES

An association between shipment and shippingaddress describes calling operations among classes. e.g. a method of class shipment may call

methods of class shippingaddress AssociationRight – class – AssociationRight ->

AssociationRight

shipmentorder shippingaddress

1 11

shipment

order

shippingaddress

1

1

shipping addressorder

1

1

*

*

10

ASSOCIATION RULES

customer

order

shippingaddress

*

1

*

order

shippingaddress

*

*

Bidirectionality is replaced by unidirectional association when an unidirectional association is abstracted together with a bidirectional association.

Association – class – AssociationRight -> AssociationRight

*

11

WE GOT A PROBLEM SO FAR

They describe different abstract relationships

The solution is to maintain the ambiguity and use AND/OR annotation

addressorder

order address* *

Which one is correct?

customer

ordershippingaddress

shipment

*

1 *

*

1

1

* 1

1

*

customer

ordershippingaddress

shipment

*

1 *

*

1

1

shippingaddressorder

*

1

* *

* 1

AND/OR

12

ASSOCIATION RULES

AssociationRight – class – GeneralizationRight -> AssociationRight

AssociationRight – class – AssociationRight -> AssociationRight

AssociationLeft – class – AssociationRight -> Ø

AssociationLeft – class – AssociationLeft -> AssociationLeft

Association – class – GeneralizationLeft -> Association

Association – class – GeneralizationRight - > AssocaitionRight

……

There are 33 association rules…*

* For a complete list of the rules, refer to Alexander’s paper.

13

AGGREGATION RULEScustome

r

order orderline

customer

orderline1

*1..*

*1

AssociationLeft[Agg] –class – Association -> AssociationLeftor Association – class – [Agg]AssociationRight -> AssciationRight

order orderline

shopping cart

Ø

[Agg]AssociationRight – class – AssociationLeft[Agg] -> Ø

1..*

*

14

AGGREGATION RULES AND DEPENDENCY RULES

[Agg]AssociationRight – class – AssociationRight -> AssociationRight

AssociationLeft[Agg] – class – [GeneralizationLeft] -> AssociationLeft[Agg]

[Agg]Association – class – Association -> Association

……

There are 44 aggregation rules…*

DependencyRight – class – GeneralizationRight -> DependencyRight

DependencyRight – class – DependencyLeft -> Ø

DependencyLeft – class – Association[Agg] -> DependencyLeft

……

There are 22 dependency rules…*

* For a complete list of the rules, refer to Alexander’s paper.

15

ABSTRACTING CARDINALITIES

Revisiting the Customer-Order-Orderline examplecustome

r

order orderline

customer

orderline1

*

*1

Only association and aggregation relationships need to add cardinality information

There are always exactly two cardinalities for each relationship under consideration

Reasoning of this example A customer may place multiple orders, and each order may have multiple orderlines An orderline belongs to an order, and an order belongs to a customer

Cardinalities are calculated by separately multiplying them 1 * 1 = 1 [0..*] * [1..*] = [0..*] = [*]

1..*

16

CARDINALITY RULES (NOT COMPLETE)

CA

CA

CA

CA

CA

A B C

A B C

A B C

A B C

A B C

[x] [y]

[y]

[y]

[w] [z]

[w] [z]

[w] [z]

[z]

[z]

[x*w] [y*z]

[w] [z]

[w] [y*z]

[y*z]

[z]

17

SERIAL ABSTRACTION

Abstraction rules, if used individually, are not very powerful.

Serial abstractions: repeated use of these simple abstraction rules.

Use serial abstractions to remove a sequence of helper classes.

What if we are interested in the

relationship between

Customer and Book

customer

order orderline

item book

1

*

1..*

1

18

SERIAL ABSTRACTION

customer order orderline item book1 * 1..* 1

customer

order orderline

item book

1

*

1..*

1

customerorderline

item book

*

1

1

customer

item book

1

*

customer book1 *

19

ABSTRACTING THE EXAMPLE

shippingaddress

payment

credit card

PayPal

customer shipment

order orderline

hardware

address

shopping cart

1

*

1

*

*

1

*

1

1

1

*

1

1

*

1..*

billingaddress

item

book

software

*

*

1

1

20

ABSTRACTING THE EXAMPLE - PAYMENT AND CUSTOMER

Four paths are found between payment and customer

payment customer

payment

customer

order

payment

customer

order

orderlineshopping

cart

shippingaddress

payment

customer

shipment

order

1*

1

1

*1

1 1 1..*

*11

11 1 1

*1

* *

payment customer1*

payment customer1*

Ø

Ø

payment customer1*

21

ABSTRACTING THE EXAMPLE – CUSTOMER AND BOOK

Three paths are found between Customer and Book

customer order

orderline

itembook

shippingaddress

customer shipment

order

orderlineitembook

customer

orderline

shopping cart

itembook

1 *1..*

1

* * 1 * 11

1..*1

11 *

1

customer book1 *

Ø

customer book1 *

customer book1 *

22

ABSTRACTING THE EXAMPLE – THE WHOLE

payment

customer address

book

1

*

1

*

* *

By repeating previous approach to any other two classes, we can abstract the relationship between the any two classes. An unidirectional association between customer and address No relationship between payment and book No relationship between payment and address No relationship between book and address

23

AUTOMATION AND TOOL SUPPORT

The abstraction technique is automated by a tool called UML/Analyzer

Algorithm Concurrent abstraction

24

AUTOMATION AND TOOL SUPPORT

The abstraction technique is automated by a tool called UML/Analyzer

Algorithm Concurrent abstraction Abstracting single paths

Reuse

Merge

25

AUTOMATION AND TOOL SUPPORTBefore

abstraction

After abstractio

n

model for reuse

26

VALIDATION

Validation methods Validate against source code Validate against existing higher level class

diagrams By inspection

27

VALIDATION - CORRECTNESS

29

2936

323226

39

39 95029136

26

1913547

47

47

Number of

Original Classes

28

VALIDATION – COMPLEXITY OF ABSTRACTION

Without optimization 2(length of path - 3) final abstractions for each path (length of path - 1)* 2(length of path - 3) intermediate

abstractions for each path Two optimization techniques (in algorithm)

Intermediate abstraction results are reused Weaker or equivalent abstractions are merged

29

CONCLUSION

The abstraction technique exploits the semantic meaning of patterns of classes and their relationships to infer abstracted relationships.

The abstraction process is supported through the UML/Analyzer tool.

The abstraction technique is well suited for model understanding.