Class Diagram
Class Diagram
• A class diagram shows the existence of classes and their relationships in the logical view of the system.
• Graphical presentation of the static view.
Classes
• A class is represented as a three-part box• Class Name• Attributes
– At conceptual level it is a piece of information associated with the class that can be accessed and possibly modified
– Corresponds to a field at the implementation level
• Operations
- The processes the class can carry out (methods at implementation level)
- Basic operations (such as getValue) on attributes can be omitted (they can be inferred)
Classes
CustomerName address
Class Name
Attributes
Operations +creditRating():String
Attribute syntax: visibility name: type = defaultValue
Operation syntax: visibility name(parameter-list): return-type
Visibility:
- public +- protected #- private –
Class Names:- Simple - Path name (Package-name :: Class-name)
Window
Banking :: CheckingAccount
For abstract classes, class name is written in italic: Customer
Abstract Class
Abstract Operation
Class Diagram - Relationship
• Association: bi-directional semantic relationship• Aggregate: a whole and part relationship• Generalization: inheritance relationship• Dependency: single-directional relationship
between a client class and a supplier class/interface• Realize: single-directional relationship. A class
realizes the operations offered by the interface.
Construct Description Syntax
association a relationship between two or more classifiers that involves connections among their instances.
aggregation A special form of association that specifies a whole-part relationship between the aggregate (whole) and the component part.
generalization a taxonomic relationship between a more general and a more specific element.
dependency a relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element).
Structural Modeling: Core Relationships
Construct Description Syntax
realization a relationship between a specification and its implementation.
Structural Modeling: Core Relationships (cont’d)
Associations
Associations are shown as lines between classes
• An association shows a relationship between instances of two classes
– Each association has two roles (one for each direction)
– A role can be explicitly named with a label
– Roles have multiplicity showing how many objects participate in the relationship
Associations can have multiplicities:
•A fixed value (such as 1 or 3)
•Many denoted by * (unlimited number)
•A range of values 0..1 or 3..*
•A set of values 2,4,8
• Adds attributes and operations to an association– Allows exactly one instance of the association
class between any two objects– Can use an actual class instead, if you need
more
Association Class
StudentCourse0..4 10..20
Grade
PersonCompany0..* 1..*
Job
descriptiondateHiredsalary
employeeemployer
Clerk ReservationConfirmation Number
1
qualifier
*finds
Qualified Association
• Association can be keyed by the value of the qualifier.
• A qualifier is used to reduce the scope of an association.
• A qualifier in an association solves the lookup problem.
Constraints
Bank TellerServes
Customer
{ordered }
High SchoolStudent
Chooses
Chooses{ or }
Academic
Commercial
• Represent further restrictions on associations or classes• A constraint is shown as a text string enclosed in braces
{ }.• A constraint is a restriction on one or more values of
(part of) an object-oriented model or system.
Meal
Soup Salad Main Course Dessert
- - - - - - - - { or } - - - - - - - - - - - - - - { precedes } - - - -1 1 1 1
Person Committee
1
* *
*
{ subset }
Member-of
Chair-of
ATM_WithdrawlATM_WithdrawlATM_WithdrawlATM_Withdrawl
customer : idcustomer : idamount : Moneyamount : Money{amount is multiple of $20}{amount is multiple of $20}
customer : idcustomer : idamount : Moneyamount : Money{amount is multiple of $20}{amount is multiple of $20}
AccountAccountAccountAccount
customer : idcustomer : idbalance : Moneybalance : Moneycustomer : idcustomer : idbalance : Moneybalance : Money
Aggregation and Composition
• Aggregation is a part-of relationship.
• Composition is also a part-of relationship, but part and whole live and die together
• In aggregation, parts may be added or removed, they may survive even after the whole is dead while in composition parts are contained in the whole and die with the container.
• Aggregation is more loosely coupled than composition.
Computer
Speaker CPU Keyboard Monitor Mouse
12 1 1 1
showsaggregation
Table
showscomposition
Table Top Leg
41
Generalization
• Sharing mechanism based on
a hierarchical relationship between classes.
• Subtype is a specialization
of the supertype.• Is-kind-of Relationship
CorporateCustomer
contactNamecreditRatingcreditLimit
remind()billForMonth(Int)
Customer
nameaddress
creditRating():String
PersonalCustomer
creditCardNumber
indicatesgeneralization
Generalization Relationship
vehicle
car shipamphibian
vehicle
water vehicleland vehicle
Dependency Relationship
Realization Relationship
• Realization is the relationship between a class and an interface. The class is said to realize the operations in the interface.