class and sequence diagrams uml notation se-2030 dr. mark l. hornick 1

Class and Sequence diagrams

UML notation

SE-2030Dr. Mark L. Hornick

1

Domain modeling will identify multiple classes

Taken together, a class diagram gives a good overview of a system’s structure

Including how the various classes are related to one another


2

Identifying class relationships

Go back to the Use Cases, and look for possessive terms relating one object to another “account’s credentials” “order’s entries” “path’s coordinates”


3

Possessive terms usually indicate a stronger form of relationship thana simple association

Many classes within an application usually exhibit some type of Association between one another

Associations represent permanent relationships between instances of classes:An Order has Entries

An Order is billed to an Account

A Login Screen is a type of Dialog

An Invoice corresponds to each Order


4

A Simple Association merely shows a general-purpose relationship


5

class Class Model

Inv oice Order

The single-line connector doesn’t indicate anything specific – thatis, it’s an unspecified association.

About all we can say is that objects of these classes are somehow interrelated – perhaps an Invoice somehow holds a reference to an Order object (or vice versa).

An association can indicate multiplicity – that is, how many objects of one class correspond to objects of the other


6

This association indicates that there is a one-to-one correspondence between Invoice instances and Order instances; that is, for every Invoice object, there is a corresponding Order object, and vice versa.

class Class Model

Inv oice Order

1 1

Associations can indicate various degrees of multiplicity


7

This Simple Association indicates that for every Order object, there is at least one corresponding Entry object.

Here, any number (including zero) of Entry objects correspond to each Order object

class Class Model

Order Entry

1 1..*

class Class Model

Order Entry

1 *

Associations can indicate navigability – that is, whether an object holds a reference to the other


8

This one-way association indicates that an Invoice object holds a reference to a single Order object.

class Class Model

Inv oice Order

1 1

class Class Model

Inv oice Order

1 1

This bi-directional association indicates that Invoice and Order objects hold references to each other.

End Roles indicate that an association is maintained via a specific attribute defined within a class


9

This one-to-one, one-way association with End Role acct indicates that an Order object holds a reference to a single Account object via a private Account attribute named acct.

Here is a less illustrative way of showing the same relationship.

class Class Model

Order

- acct: Account

Account

class Class Model

Order Account

1

-acct

1

End Roles can indicate specific bi-directional references


10

This bi-directional association indicates that an Order object holds a reference to a single Account object via a private Account attribute named acct, and that an Account object holds a reference to a single Order object via a private Order attribute named ord.

class Class Model

Order Account-ord

1

-acct

1

Here is a less illustrative way of showing the same relationship.

class Class Model

Order

- acct: Account

Account

- ord: Order

Associations can imply that a reference is a collection of objects


11

This one-way association indicates that an Order object holds a reference to a collection of zero or more Entry objects via a private attribute named items.

The same association, less illustratively.

class Class Model

Order Entry

1

-items

*

class Class Model

Order

- items: ArrayList<Entry>

Entry

Stereotypes indicate a logical function of an association


12

This stereotype specifies “containment” of an collection of Entry objects by an Order object.

Stereotypes are usually verbs that indicate the specific type of usage.

class Class Model

Order Entry

1 «contains»

-items

*

Composition is a stronger form of an association that implies containment and lifetime


13

By “stronger”, we mean that the semantics of the association are more specific.

Composition indicates that the Entry objects cannot exist independently of the Order object; that is, if the Order object is deleted, all the Entries are deleted as well.

class Class Model

Order Entry+items

*1

Aggregation is a stronger form of an association that implies containment, but not lifetime


14

Aggregation indicates that the Order object can exist independently of the Invoice object; that is, if the Invoice object is deleted, the Order can still exist (maybe it can be fulfilled free of charge).

However, the Composition association in the other direction indicates that if an Order is deleted, the associated Invoice must be deleted as well (you shouldn’t invoice someone for an Order that doesn’t exist!)

class Class Model

Inv oiceOrder

-inv

11

+ord

1 1

Inconsistent terminology between strict UML and EA

UML Aggregation A is composed of B; B can exist

without A EA refers to this as Shared

Aggregation

UML Composition A is composed of B; B cannot exist

without A EA refers to this as Composite

Aggregation


15

Generalization is another form of association that implies that a class inherits behavior defined and implemented in another class


16

Here, the Generalization association implies that the LoginClass inherits the behavior (and attributes) of the JFrame class. Objects of the LoginClass are also JFrame objects.

class Class Model

JFrame LoginScreen

class Class Model

JFrame

LoginScreenGeneralization can be illustrated in the alternate notation shown if the parent class is not present in the class diagram

Realization is a form of association that implies that a class implements, but does not inherit, the behavior defined in another class


17

Here, the Realization association implies that the LoginClass implements the behavior of the Serializable class (which in Java is called an Interface). Objects of the LoginScreen class are also Serializable objects.

class Class Model

LoginScreen«interface»Serializable

In EA, the Association Properties dialog controls the semantics of an association


18

Showing recursion in a Sequence Diagram


19

sd Sequence

anInvoice :Invoice :EntryanOrder :Order

*[foreach( Entry in Order)]: entry= getEntry() :Entry

getInfo()

getOrderID()

Showing selection in a Sequence Diagram


20

sd Sequence

anInvoice :Invoice :EntryanOrder :Order

*[getFirstEntry]: entry= getEntry() :Entry

[if( entry != null )]:getInfo()

getOrderID()

[if( entry == null )]:reset()

class and sequence diagrams uml notation se-2030 dr. mark l. hornick 1

Documents

single order object

invoice object

corresponding order

single account object

order instances

bidirectional association

entriesan order

order objectse