1. Class Diagram Details
CS 124

2. 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

3. Class Details
For conceptual perspective, class names are often sufficient
For specification and implementation perspectives, class details are often provided
BankAccount
BankAccount
deposit()
withdraw()
BankAccount
balance:double
deposit()
withdraw()

4. 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

5. 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

6. 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}

7. Class variations If the class is an interface For abstract classes
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

8. 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

9. 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

10. Generalization Single versus multiple classifications
Use of discriminators for multiple classifications
Constraints (e.g., {complete})