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