Class Diagram Details
Download
Report
Transcript Class Diagram Details
Class Diagram Details
CS 124
Perspectives
Level of detail in UML diagrams is often
dependent on perspective taken
Perspectives
Conceptual: Analysis; focus on domain, mapping
with code not strict
Specification: Design; focus on interfaces, implicit
code consequences
Implementation: Development; focus on code
details
Class Details
For conceptual perspective, class names are
often sufficient
BankAccount
For specification and implementation
perspectives, class details are often provided
BankAccount
deposit()
withdraw()
BankAccount
balance:double
deposit()
withdraw()
Attributes
visibility name:type = initial-value
Example
- balance:double = 0
means a balance variable is private, of type double, and is
initialized to 0
Some portions (e.g., visibility, type, or initial value)
may be suppressed depending on perspective and
emphasis
Visibility: + public, - private, # protected
/ means the attribute can be derived from other
attributes or associations
Operations / Methods
visibility name(parameter-list):return-type
Examples
+ withdraw( amount: double )
+ getBalance(): double
Some portions may be suppressed
depending on perspective and emphasis
Visibility: + public, - private, # protected
Attribute and method
specifiers/constraints
Underline name and type if attribute or method
is static (class-level)
Use property-list (enclosed in curly braces) to
provide further specifications (also called
constraints)
BankAccount
balance: double
minBalance: double = 1000 {frozen}
addAccount()
deposit()
withdraw()
getBalance() {query}
Class variations
If the class is an interface
Italicize class name and prefix with <<interface>>
Or, use lollipop notation
Implementing classes connected using a
realization (like generalization but with dotted line)
For abstract classes
Italicize and indicate {abstract}
Italicize abstract methods
Associations
There are several options when specifying
associations
Particularly for many-to-many associations
Using an association class
Using a qualified association
Promote the association class to a full class
Attributes versus associations
Aggregations
Aggregation (hollow diamond) versus
composition (filled diamond)
Composition: part lives and dies with the
whole
Possibility of having a * multiplicity on the
side of the composite
Perhaps an association is better in this case
Safest way through: always use aggregation
even when the parts are strict
Generalization
Single versus multiple classifications
Use of discriminators for multiple
classifications
Constraints (e.g., {complete})