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 For specification and implementation perspectives, class details are often provided BankAccount 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 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

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})