1. Graphical Systems Modeling with UML / SysML Class diagrams
© Piotr Ciskowski

2. Case study – ATM – lecture plan:
Overview GO
Class – object GO
Class diagram elements GO
Relations GO
Associations GO
Aggregations GO
Generalizations GO
Dependencies & realizations GO
Suggestions GO
Summary GO
Examples GO
Case study GO
lecture plan

3. Perspectives - views: Dynamic View Logical view Use case view
architecture
class diagram
object diagram
composite structure diagram
package diagram
behavior
sequence diagram
activity diagram
state machine diagram
interaction overview diagram
communication diagram
timing diagram
package diagram
Dynamic View
Logical view
Use case view
Deployment View
system scope & functionality
use case diagram
package diagram
Implementation View
hardware
deployment diagram
package diagram
software
component diagram
package diagram

4. Class diagram best known – object oriented modeling / programing
static structure diagram
presents system’s structure
These are the most often used and also best known UML diagrams
Even people who don’t know much about UML, but know something about object oriented programming, have seen a class diagram
Class symbol (a rectangle with compartments) has been used for ages
Class diagram is the main building block, notion of object oriented modeling.
It is used both for general conceptual modeling of the semantics of the system, …
…ad for detailed modeling close to the code in a programing language

5. Class diagram best known – object oriented modeling / programing
static structure diagram
presents system’s structure
graphical representation of static elements of system’s domain and relations between them

6. Class diagram best known – object oriented modeling / programing
static structure diagram
presents system’s structure
graphical representation of static elements of system’s domain and relations between them
classes – generalization, type
objects – instance, exemplar
relations

7. Classes & objects

8. Object - class
object - each entity (a person, an animal, a being, a notion, a concept, a thing…) that is important in the domain of the system being modeled in the context of the problem being solved
structure, statics - atributes, features, fields
behavior, dynamics - operations, services, methods - object = instance of a class - object has its identity
class - a generalization of objects, - a set of objects with the same features, operations, relations, constraints – meaning - an abstract notion (not abstract class!)
Each object has its own individual identity:
we may distinguish it from a set of objects (of the same class)…
… even if all they have the same values of attributes
An object is distinguished by its existence – not by its features
human example: twins
software example: a table of objects / records, all with the same values of all fields / attributes
Class is an abstract idea, notion
not to be confused with the abstract class

9. Class name: noun symbol: rectangle (with compartments)
different levels of detail
Client
Account -
number
type
Reservation +
makeReservation()
confirmReservation()
cancelReservation()
verifyClient()
Credit Card
cardNumber : long
holderName : char
type : byte
expiryDate : date
authorize() : void
block() : void
We may include only the class name, …
… or the selected compartments - according to the specific needs of a given diagram:
only attributes
only operations
both
class responsibilities
exceptions
we do not have to specify exactly all the types, parameters, etc.
Credit Card – a class name with spaces – may be used at conceptual stage of design (later explained)
tool: Enterprise Architect

10. Class name: noun symbol: rectangle (with compartments)
different levels of detail
We may also show only the needed attributes or only the selected operations.
It all depends on the context and the aim of each diagram
tool: Visual Studio

11. Class type, kind, set of elements name: noun, capital letter
attibutes – features, characteristics of objects - static structure - name: small letter
operations - actions - services - messages - dynamics, behavior - name: small letter
attributes
operations
actions – that the class is able to perform – that other class, person is able to perform with the class
services – that you may ask its objects to provide
messages – you may send to its objects

12. Class - object class = type, set object = instance, exemplar, identity
WashingMachine -
brandName : char
model : char
serialNumber : int
load : byte
myWashingMachine
: WashingMachine
brandName = "WM8"
load = 10
model = „Big Franny”
serialNumber =
tool: Enterprise Architect

13. Class stereotypes, responsibilities
+ wash
+ dry
- selfCleaning
# diagnose
- measureLoad
+ setProgram
- brandName
- model
- load
WashingMachine
«market info»
«tech info»
«clothes»
«maintenance»
+ wash
+ dry
- selfCleaning
# diagnose
- measureLoad
+ setProgram
- brandName
- model
- load
WashingMachine
«market info»
«tech info»
«clothes»
«maintenance»
take dirty clothes, clean them, dry them, do not ruin’em!!!!
Stereotypes are a comfortable and versatile tool for enhancing the functionality of UML elements and diagrams
Here we divided attributes and operations into categories using sterotypes
the way of grouping attributes and operations by sterotypes is not supported in main UML modeling tools
it is just an idea from the book „UML dla każdego” – but we may use it while sketching diagrams
We could group the classses using stereotypes
e.g. when modeling an intelligent house we could have such categories of classes as: «appliances», «media», «light», «heating», etc.
this method is supported byall tools
Responsibilities section gives us a opportunity to clearly and briefly state what objects of the class should be able to do – what services they should provide
It is often used at an early stage of design – before specifying exactly the attributes and operations of the class

14. Class diagram elements

15. Class diagram level of complexity
conceptual - only key entities analytic - no details - informal names of classes, attributes and operations
implementation - «implementation class» - proper names - plus: data types responsibilities visibility scope multiplicities association classes compositions and aggregations generalizations dependencies realizations
Depending on
the stage of our modeling project
aim and audience of a specific diagram
different levels of complexity may be used on diagrams
taht is – more or less detailed the diagrams may be
implementation classes may be stereotyped as «implementation class» (but not necessarrily)

16. Class diagram naming conventions – classes:
conceptual level: auction trading session żądanie
implementation level: Auction TradingSession Zadanie
naming conventions – attributes:
conceptual level: temporary disk free space, adres wysyłki, cell phone no.
implementation level: tempDiskFreeSpace, adresWysylki, PhoneNoCellular
naming conventions – operations:
conceptual level: block SIM card send an SMS
implementation level: blockSIMcard() sendSMS()
all names at conceptual level – common language, spaces, special characters
at implementation level – strict rules, noe spaces, according to the implemenatation language specification

17. Class diagram additional elements:
constraints - conditions, limitations of a given element - text, formula, pseudo-code, OCL (Object Constraint Language) - in French brackets
WashingMachine -
brandName :char
model :char
serialNumber :int
load :byte +
setProgram() :void
wash() :void
dry() :void
selfCleaning() :void
diagnose() :void
measureLoad() :void
constraints
{load = 8, 9 or 10kg}
Constraints are a general extension mechanism in UML
they are used not only with classes
with any concept
tools: Enterprise Architect, Visual Paradigm, Visual Studio

18. Class diagram additional elements: notes - anywhere
Notes are also a widely used extension mechanism
may be attached to any diagram, element of the diagram, a class, an attribute, a relation – anything
They are often used for sketches, for capturing requirements
tool: Visual Studio

19. Class diagram additional elements:
responsibilities - auxiliary - after preliminary scenarios analysis - before full implementation (attributes, operations)
CRC card - responsibilities + collaboration
WashingMachine
responsibilities
wash dirty clothes, dry them, do not damage
A class with specified responsibilities is then transformed into a full class with attributes and operations
A class specified only by its responsibilities and a list of cooperating classes – CRC card (Class-Responsibility-Collaboration Card)
tool: Enterprise Architect

20. Class diagram additional elements:
visibility: + public - private # protected ~ packet
Auction -
auctionID +
title
askingPrice
startTime
closingTime ~
deliveryType
addAuction() :void
closeAuction() :void
modifyAuction() :void #
getArticleDescritpion() :void
In some packages the visibility is referred to as the scope
+ public – all objects in the system may access an attribute or an operation
- private – only objects of this class may access an attribute or an operation
# protected – only objects inherited after this class may access an attribute or an operation
~ packet – only objects inside this class packet may access an attribute or an operation
tools: Visual Studio, Enterprise Architect, Visual Paradigm

21. Class diagram additional elements:
visibility: + public - private # protected ~ packet
rule: - attributes + operations: getters & setters
popular rule
attributes are private
access through public methods – getters & setters
Visual Studio arranges attributes and operations alphabetically – but grups them by visibility
Visual Paradigm arranges attributes and operations as you wish
Enterprise Architect lets you choose

22. Class diagram additional elements:
scope: instance - classifier static attributes and operations
attributes:
instance – individual for each instance, values vary for each instance
classifier (static) – common for the whole class = for all objects of this class, value equal for all instances
e.g. common multiplier, currency exchange rate, common symbol, etc.
methods:
instance - its invocation affects instant attributes
classifier – its invocation does not affect instant attributes

23. Details

24. Class diagram
data types - depend on modeling tool e.g. Rational Rose .NET
logic Boolean Boolean
fixed point Byte Byte Integer Short Long Integer Long
floating point Single Single Doble Double Decimal
character String String Char
other Date Date Object Object Currency Variant
data types to be used with attributes or returned values – depend on the modeling tool we use and final implementation language set in this tool
various CASE tools offer different set of types
we may alway define our own types, e.g. enumerations, subsets
and our own classes, used as types

25. Class diagram attributes notation – implementation level
[< + - ~ # >] [ / ] <name> [ : <type> ] [ [ <multiplicity> ] ] [ = <initial value> ] [ { <property> } ]
/ - derived attribute - formula usually in attached note
properties: ordered , [not] unique, readOnly etc.
formula for calculating a derived attribute is usually placed in a note, attached to the class symbol
derived attributes are usually read only
type may be a reference or a pointer
multiplicity – will have a separate slide:
[0..1] – zero or one
[0..*] – zero or more (no limit)
[1..*] – at least one element
[*] – any number (same as: zero or more)
properties – most often used:
ordered – for attributes of multiplicity more than 1 – elements should be sorted
(not) unique – also for attributes with multiplicity more than 1 – elements of that attribute may (not) be unique (in the scope of that attribute)
readOnly – changing the initial value is not allowed

26. Class diagram attributes notation – implementation level
[< + - ~ # >] [ / ] <name> [ : <type> ] [ [ <multiplicity> ] ] [ = <initial value> ] [ { <property> } ]
/ - derived attribute - formula usually in attached note
properties: ordered , [not] unique, readOnly etc.
methods notation – implementation level
[ < + - ~# > ] <name> [ ( <parameter list> ) ] [ : <property> ]
parameter list – with commas

27. Class diagram attributes notation – implementation level
[< + - ~ # >] [ / ] <name> [ : <type> ] [ [ <multiplicity> ] ] [ = <initial value> ] [ { <property> } ]
/ - derived attribute - formula usually in attached note
properties: ordered , [not] unique, readOnly etc.
methods notation – implementation level
[ < + - ~# > ] <name> [ ( <parameter list> ) ] [ : <property> ]
parameter list – with commas
parameters notation – implementation level
[ in out inout return ] <name> [ : <type> ] [ [ <multiplicity> ] ] [ = <initial value> ] [ { <property> } ]
parameters notation – analogically as for attributes
first, instead of visibility and / - optional in /out / inout / return
default is in – parameter is passed to the method, which modifies it (or not)
out – parameter is returned from the method
inout – parameter is first passed to the method, which modifies it and return the same way
return – as inout, but returned with return

28. Class diagram
attributes, methods, parameters notation – implementation level
Option -
premium : Single = 10000
volume : Double =
tick : Percent = 0,01
tickValue :Byte = 25 +
countTicks (sellPrice:Double, buyPrice:Double) : Single
execute(ticks:Single, tickValue:Byte, contracts:Integer) : Double
tool: Enterprise Architect, example based on: Wrycza et al., Język UML 2.0 w modelowaniu…

29. Class diagram
attributes, methods, parameters notation – implementation level
Visual Studio allows you to write attributes and operations easily at one go
VS will then break down the whole line into e.g. method’s name, its parameters and types
in this example I wrote the whole line – the whole method’s specification
and VS undestood everything
tool: Visual Studio, example based on: Wrycza et al., Język UML 2.0 w modelowaniu…

30. Relations

31. Relations types of relations: association generalization dependency
realization
without relations – any class diagram would only be a set of rectangles

32. Relations
Associations

33. Relations
association - a link between elements - a semantic relation between classes - binary - n-ary
pure, simple association – main kind of relations on class diagrams
binary associations are most often used

34. Relations
association - a link between elements - a semantic relation between classes - binary - n-ary
Project
Manager
a simple example, based on Wrycza
tool: Enterprise Architect

35. Relations
association - a link between elements - a semantic relation between classes - binary - n-ary
Project
Manager
an example with some more elements – name, roles and multiplicities
image: Wikipedia

36. Relations
association - a link between elements - a semantic relation between classes - binary - n-ary
Project
Manager
an example with one role - which should rather be the name of the association
image: Sparx Systems - UML 2 Tutorial

37. Relations
association - a link between elements - a semantic relation between classes - binary - n-ary
extras: - name - roles - navigation - multiplicity - aggregation
an example with one role - which should rather be the name of the association

38. Relations
association - a link between elements - a semantic relation between classes
named - unnamed
Project
Manager
Project
Manager
is led by
Project
Manager
◄leads

39. Relations
association - a link between elements - a semantic relation between classes
named - unnamed
Player
Team
plays in►

40. Relations
association - a link between elements - a semantic relation between classes
named – unnamed
navigation - direction - of interpretation - of sending messages
Usually associations are bi-directional
But sometimes it is worth specifying the direction
usually it is the direction of sending messages
but it does not exclude the possibility of sending messages the other way – e.g. around
Project
Manager
◄leads

41. Relations
association - a link between elements - a semantic relation between classes
roles - obligations towards the other class
Project
Manager
+task
is lead by
+leader

42. Relations
association - a link between elements - a semantic relation between classes
multiplicity
multiplicity – how many instances of class A may be related to instances of class B

43. Relations
association - a link between elements - a semantic relation between classes
multiplicity 1 - exactly one n - exactly n * - many zero or one 0..* - zero or more 0..n - zero to n 1..n - one to n 1..* - one or more n..m - between n and m n..* - more than n n,m,p,q - n or m or p or q
multiplicity – notation

44. Relations - examples associations – names, directions, multiplicity:
Teacher
Student
Customer Service
Client
House
Chimney
Tricycle
Wheel
Egg Container
Egg 1
teaches *
serves
1..*
has
0,1 3
contains
6,12,24
we may think of other relations describing husband and wife ;-)
in case of house – maybe an aggregation should be used?
same with tricycle

45. Relations – example original: Wrycza et al., Język UML 2.0…
Mobile network - associations and roles
class Mobile network client
Client
Telephone
SIMcard
RatePlan
Mail
Billing
Invoice
Showroom
+owner
uses▲
+tel. no
+price-list
◄is assigned
+memory
card
buys►
+product
◄receives
+form of
communiations
+documents
contains▲
+list of calls
contains▼
+settlement
+sales point
offers▲
an example – to be discussed
my remarks – nice diagram, but:
relation Client – Mail – why is is named owner
role of SIMcard – both roles (in both relations) are strange to me
relation SIMcard – RatePlay – I would leave it unnnamed
relations named contains – will be replaced with aggregations later on (by Wrycza himself – in the book (not only my suggestion))
tool: Enterprise Architect

46. Relations – example original: Wrycza et al., Język UML 2.0…
Mobile network - associations and roles and multiplicity
class Mobile network client
Client
Telephone
SIMcard
RatePlan
Mail
Billing
Invoice
Showroom
+owner 1
uses▲
+tel. no
1..*
+price-list
◄is assigned
+memory
card
0..*
buys►
+product
◄receives
+form of
communiations *
+documents
contains▲
+list of calls
contains▼
+settlement
+sales point
offers▲
10.*
an example – to be discussed
tool: Enterprise Architect

47. Relations – example my suggestion
Mobile network - associations and roles and multiplicity
class Mobile network client
Billing
Mail
Invoice
Client
SIMcard
RatePlan
MobileDevice
SalesPoint
+owner 1
uses▲
1..*
+price-list
0..*
buys►
+product
offers▲
10..*
◄receives *
+documents
contains▲
+list of calls
contains▼
+settlement
an example – to be discussed
tool: Enterprise Architect

48. Relations
association - a link between elements - a semantic relation between classes
special kinds:
multiple
Participant
Auction
+seller
sells
bids
+winner
buys
multiple associations – not to be confused with multiplicity
multiplicity – more objects of the same class are in relation with more than one object of the other class
multiple associations – more roles that an object of one class can play in relation with an object of the other class

49. Relations
association - a link between elements - a semantic relation between classes
special kinds:
multiple
recursive
Car
Automobile
the weight of the
haulted car may not
exceed the weight of
the haulting car!
+platform
transports 1
haults
recursive = to itself
a plataform car transports cars to a dealer
one car hauls another car
I couldn’t use another Car symbol on the same diagram (EA), therefore Automobile
only one car can hault one car at one moment
weights of both cars – see the note

50. Relations
association - a link between elements - a semantic relation between classes
special kinds:
multiple
recursive
qualified
Auction
Seller
sellerID
1..*
qualified
an object of one class can search for objects of the qualified class
done by a qualifier – an attribute or a list of attributes which order the objects of the qualified class that are involved in that association
qualifier – attached to the class which performs search
Receptionist
Reservation -
reservationNumber :int
reservationNumber
1..*
0..*

51. Relations
association - a link between elements - a semantic relation between classes
special kinds:
multiple
recursive
qualified
qualified association
implemented as simple association
we add a method that returnes the searched object, given the value of the qualifier
images: Enterprise Architect help

52. Relations
association - a link between elements - a semantic relation between classes
special kinds:
multiple
recursive
qualified
Given a company and a social security number (SSN) at most one employee could be found
Given a library and author name none to many books could be found
images:

53. Relations association class precise description of association
association itself – has some attributes
association = class:
name
attributes
operations
one association – one object of association class
provides precise description of an association between classes
when the association itself – has some features, attributes
not only the objects, but also the relation is described by attributes
one relation between two objects and another relation between two other objects
both relations are described by some attributes
these attributes are different for both relations
many obejcts of both classes may be associated with each other
each such association = one object (instance) of association class
each such association = only one object of association class

54. Relations association class precise description of association
association itself – has some attributes
association = class:
name
attributes
operations
Manager
Project
Contract -
deadline : date
salary : int
bonus : int
completed : %
a good example – manager and project linked with by the contract
- moja wątpliwość (rozwiązana) – umowa o pracę i umowa o dzieło – dwa powiązania, każde z klasą asocjacyjną

55. Relations association class precise description of association
association itself – has some attributes
association = class:
name
attributes
operations
an employee may be working on several projects at the same time and have different job titles and security levels on each
image: Sparx Systems – UML 2 Tutorial

56. Relations association class precise description of association
association itself – has some attributes
association = class:
name
attributes
operations
Player
Team
Contract -
salary : millions of dollars ;-)
Manager
plays in
negotiated by

57. Relations
Aggregations

58. Relations aggregation - „has a” - part-whole
a type of association – more specific
a variant of „has a” relationship

59. Relations
aggregation - „has a” - part-whole - binary - contained class – container - segment – aggregat
Aggregation can occur when a class is a collection or container of other classes
but where the contained classes do not have a strong life cycle dependency on the container
essentially, if the container is destroyed, its contents are not. (Wikipedia)

60. Relations aggregation - „has a” - part-wholePC
Central unit
Keyboard
Mouse
Display
Speakers 1
We may say that a PC is made of the case and some peripherals
We might add some multiplicity values (I forgot)

61. Relations aggregation - „has a” - part-wholePC
Central unit
CPU
Memory
Keyboard
Mouse
Display
Speakers
Case
PowerSupply
Disk
GraphicCard
SoundCard 1
The central unit is made of a few components
In this case we can see a stronger type of aggregation – composition
If we remove any of the components – the central unit will not work (more or less e.g. in case of the sound card)

62. Relations
composition - „owns a” - part-whole

63. Relations
composition - „owns a” - part-whole
Table
Tabletop
Leg 1 4

64. Relations composition - „owns a” - part-whole
difference: - object are made of other objects
aggreation - weak: components can exist alone - independent
composition - strong: destroy the object = destroy components
in both cases – objects are made of other objects
Aggregation can occur when a class is a collection or container of other classes, but where the contained classes do not have a strong life cycle dependency on the container - if the container is destroyed, its contents are not
Composition usually has a strong life cycle dependency between instances of the container class and instances of the contained class(es) – if the container is destroyed, normally every instance that it contains is destroyed as well

65. Relations composition - „owns a” - part-whole
difference: - object are made of other objects
aggreation - weak: components can exist alone - independent
composition - strong: destroy the object = destroy components
a nice example from Wikipedia
after Wikipedia:
When attempting to represent real-world whole-part relationships, e.g., an engine is a part of a car, the composition relationship is most appropriate.
However, when representing a software or database relationship, e.g., car model engine ENG01 is part of a car model CM01, an aggregation relationship is best, as the engine, ENG01 may be also part of a different car model.
Thus the aggregation relationship is often called "catalog" containment to distinguish it from composition's "physical" containment.
The whole of a composition must have a multiplicity of 0..1 or 1, indicating that a part must belong to only one whole; the part may have any multiplicity.
For example, consider University and Department classes.
A department belongs to only one university, so University has multiplicity 1 in the relationship.
A university can (and will likely) have multiple departments, so Department has multiplicity 1..*.
image: Wikipedia

66. Relations aggregation or attribute simple components - attributes
complex components – aggregations
what to use?
how to represent aggregation on a diagram?
as an aggregation association
or just as an attribute or a collection of atributes
it depends on the diagram’s complexity, perspective and its aim
do we really want to emphasize, that two classes are associated with aggregation
or do we just want to show how the container class is built
we may also use this thumb rule:
simple components – as attributes in container class
complex components – as aggregation association

67. Relations
Examples

68. Relations – example 1
Mobile network – associations, roles, multiplicity
class Mobile network client
Billing
Mail
Invoice
Client
SIMcard
RatePlan
MobileDevice
SalesPoint
+owner 1
uses▲
1..*
+price-list
0..*
buys►
+product
offers▲
10..*
◄receives *
+documents
contains▲
+lit of calls
contains▼
+settlement
an example – to be discussed
tool: Enterprise Architect, example: based on Wrycza et al., Język UML 2.0 w modelowaniu… (modified)

69. Relations – example 1
Mobile network – associations, roles, multiplicity, aggregations and compositions
class Mobile network client
Billing
Mail
Invoice
Client
SIMcard
RatePlan
MobileDevice
SalesPoint
+owner 1
uses▲
1..*
+price-list
0..*
buys►
+product
offers▲
10..*
◄receives *
+documents
contains▲
+lit of calls
contains▼
+settlement
new version – with aggregations and compositions
Mail may contain billing(s) and invoice(s) – may or may not, customers are sent other types of mail, too
billings and invoices can exist independently of the mail
but a sales item on an invoice – cannot exist alone
if we destroy an invoices, all its items are also destroyed
that’s how it is implemented in most accounting systems
client must use at least one SIMcard
each card is associated with a rate plan (exactly one)
however there may exist a rate plan that is not associated with any SIMcard – e.g. an old one, unused now and kept for historical reasons
+list
contains►
Item
1..* 1
tool: Enterprise Architect, example: my suggestion based on Wrycza, UML 2.0…

70. Relations- example 2 aggregation - compositionPC
Central unit
CPU
Memory
Keyboard
Mouse
Display
Speakers
Case
PowerSupply
Disk
GraphicCard
SoundCard 1
The central unit is made of a few components
In this case we can see a stronger type of aggregation – composition
If we remove any of the components – the central unit will not work (more or less e.g. in case of the sound card)

71. Relations- example 2 aggregation - compositionPC
CPU
Memory
Keyboard
Mouse
Display
Speakers
Case
PowerSupply
Disk
GraphicCard
SoundCard 1
We may omit the class Central unit by attaching all its components to the PC – with composition
Of course in this case „destroying” the PC does not automatically mean physical destroying of CPU, memory, disk and so on.

72. Relations
Constraints

73. Relations aggregation constraints Meal Soup Salad MainMeal Dessert
{or}
MainMeal
Dessert

74. Relations constraints
by the way – constraints may be used not only for aggregations
but also for all kinds of elements on UML diagram
e.g. class attributes
or associations
the symbol for a constraint is the same as for a note
images:

75. Relations
Generalizations

76. Relations generalization inheritance – class hierarchy
superclass – subclass parent - child
root – leaf
abstract classes

77. Relations generalization
object of the child class is a kind of an object of the parent class
if not - association

78. Relations
generalization
image:

79. Relations
generalization
image: Sparx Systems - UML 2 Tutorial

80. Relations generalization constraints: {complete} – {incomplete}
Report
DailyReport
WeeklyReport
MonthlyReport
QuarterlyReport
AnnualReport
{complete}
complete – all Report’s child classes are depicted on this diagram
incomplete – there may exist a class that inherits from Receiver, not shown on this diagram
Receiver TV
Radio
Modem
{incomplete}
example: based on Wrycza et al., Język UML 2.0 …

81. Relations generalization
constraints: {complete} – {incomplete} {disjoint} – {overlapping}

82. Dependencies & realizations
Relations
Dependencies & realizations

83. Relations dependency one class depends on the other
changing one class  changes in the other independent dependent

84. Relations dependency one class depends on the other
changing one class  changes in the other independent dependent
Delivery -
deadline :Date
carrier :meansOfTransport
Article
weight :float
length :float
width :float
height :float
System +
showForm() :void
Form
image: based on Wrycza, UML 2.0 … and UML dla każdego

85. Relations
dependency
object of one class among parameters of other class operation
objects of one class send messages to objects of the other class
objects of one class contain objects of the other class
scale of changes
dependencies show the scale of changes in the system
if I change this class – how many classes will I have to change

86. Relations realization class – interface
interface - a set of operations - services provided by class - a contract
using class - dependency providing class - implementation «realize»
abstract class - class without objects interface - class without implementation

87. Relations realization Book Cart example: based on Wrycza, UML 2.0-
author : String
title : String
ISBNnumber : long
publishingDate : Date
netPrice : float
VATrate : % +
addItem()
removeItem()
calculateGrossPrice()
emptyCart()
search()
«interface»
Cart
total : double
example: based on Wrycza, UML 2.0

88. Suggestions

89. Class diagram – suggestions:
do not over… …draw …relate …detail - moderate notation
big picture  details
use many diagrams:
for different: needs, perspectives, fragments, detail levels
not all classes, not all details
structure + behavior
business - technical
We do not need to place all classes (and details: relations, attributes, types, operations, multiplicity, etc.) in one diagram
It is better to use many diagrams:
one or a few general diagram – with only class names, most important associations, informal names – just to show the idea of the system
a few more detailed diagrams – with several chosen classes and relations – just to show a piece of the whole system
implementation diagrams – only these should include all the details (attributes, operations, full specifications)

90. Summary

91. Class diagram Steps: identify and name classes
define their responsibilities
link classes with relations – associations
specify attributes operations
add details to associations: names, roles navigations, multiplicities aggregation,s compositions, qualifications, etc.
identify other relations: generalizations dependencies realizations
full specifications of attributes operations parameters, etc.
object diagram
Steps – based on Wrycza, Język UML 2.0… with my suggestions
responsibilities – not necessary
object diagram – if needed
object diagram
system structure in a specific moment of its operation
a snapshot of the system

92. Class diagram After interview with the client:
identify nouns  classes  attributes
find verbs  operations
general class list with responsibilities
analyse relations
add details
and more details …
Steps – based on UML dla każdego, with my suggestions

93. Examples

94. Examples for discussion e-(book)store. original: Wrycza et al
Examples for discussion e-(book)store original: Wrycza et al., Język UML 2.0…

95. Examples for discussion e-(book)store modified, based on: Wrycza et al., Język UML 2.0…
Order -
orderNumber :Long
orderDate :Date
paymentMethod :PaymentMethods
status :OrderStatus +
prepare()
calculate()
changeOrderDetails()
changeStatus()
«enumeration»
PaymentMethods
OrderStatus
Client #
telephoneNumber :String
street :String
zipCode :Integer
city :String
update()
CorporateClient
companyName :String
TaxIdNumber :String
PrivateClient
firstName :String
lastName :String
User
String
login :String
password :String
Administrator
authorizationLevel :Byte
setRights()
CreditCard
cardType :Byte
cardNumber :Long
cardholderName :String
expiryDate :Date
verify()
charge() :Integer
Delivery
deliveryType :DeliveryTypes
netValue :Single
VATrate :%
calculateGrossPrice()
DeliveryTypes
Invoice
invoiceNumber :String
invoiceDate :Date
paymentDate :Date
paid :Bool
Book
author :String
title :String
publisher :String
ISBNnumber :Long
publishingDate :Date
netPrice :Double
addItem()
removeItem()
emptyCart()
«interface»
Cart
total :Double 1
0..*
1..3
1..*
we might, e.g.
put client’s address in a one parameter – type: Address (new class)
change the types of book’s author, publisher, etc. (to create relations in database tables) …

96. Examples for discussion bookstore – domain model diagram. source: www
Examples for discussion bookstore – domain model diagram source:

97. Examples for discussion bookstore – diagram of implementation classes
Examples for discussion bookstore – diagram of implementation classes source:

98. Examples for discussion bookstore – object diagram. source: www
Examples for discussion bookstore – object diagram source:

99. Case study

100. Case study my system - interview

101. Case study my system - nouns

102. Case study my system - classes

103. Case study my system - verbs

104. Case study my system - relations – conceptual class diagram

105. Case study my system - details - implementation class diagram