1. Chapter 16 UML Class Diagrams
“To iterate is human, to recurse, divine.” - anonymous
Objectives
Provide a reference for frequently used UML class diagram notation.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

2. Introduction
The UML includes class diagrams to illustrate classes, interfaces, and their associations.
“Static object modeling”
This chapter is a reference, it summarizes the notation, irrespective of the perspective (conceptual or software)
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

3. Fig 16.1 Common UML class diagram notation.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

4. Design Class Diagrams (DCD)
The UML has notation for showing design details in static structure: Class Diagrams.
The definition of design class diagrams occurs within the design phase.
The UML does not specifically define design class diagram.
The creation of design class diagrams is dependent upon the prior creation of:
Interaction diagrams identifies the SW classes that participate in the solution, plus the methods of classes.
Conceptual model adds detail to the class definitions.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

5. Fig. 16.2 UML class diagrams in two perspectives.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

6. Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

7. As we can see….
A design class diagram illustrates the specifications for SW classes and interfaces.
Typical information included:
Classes, associations, and attributes
Interfaces, with their operations and constants
Methods
Attribute type information
Navigability
Dependencies
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

8. Fig. 16.3 Attribute text vs. Association line notation for a UML attribute.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

9. Fig. 16.4 Idioms in association notation usage in different perspectives.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

10. Fig. 16.5 Applying the guidelines to show attributes in two notations.
public class Register {
private int id;
private Sale currentSale;
private Store location; }
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

11. How to make a DCD
Identify all the classes participating in the SW solution by analyzing the interaction diagrams.
Draw them in a class diagram.
Duplicate the attributes from the associated concepts in the conceptual model.
Add method names by analyzing the interaction diagrams.
Add type information to the attributes and methods.
Add the associations necessary to support the required attribute visibility.
Add navigability arrows to the associations to indicate the direction of attribute visibility.
Add dependency relationship lines to indicate non-attribute visibility.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

12. Creating the NextGen POS DCD
Identify SW classes and illustrate them.
Register Sale ProductCatalog ProductSpecification Store SalesLineItem Payment
Draw a class diagram for
these classes.
Include the attributes
previously identified
in the domain model.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

13. Creating the NextGen POS DCD (2)
Add method names
from
interaction diagrams
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

14. Method Names: Issues
The following special issues must be considered with respect to method names:
Interpretation of the create() message.
Depiction of accessing methods.
Interpretation of messages to multi-objects.
Language-dependent syntax.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

15. <<constructor>> SuperclassFoo(Long)
Method names: create
The “create” message is the UML language independent form to indicate instantiation and initialization.
When translating the design to an OOPL, it must be expressed in terms of its idioms for instantiation and initialization.
<<constructor>> SuperclassFoo(Long)
Class Name
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

16. Method names: Accessing Methods
Accessing methods are those which retrieve (accessor method - get) or set (mutator method) attributes.
It is common idiom to have an accessor and mutator for each attribute, and to declare all attribute private (to enforce encapsulation).
They are also called getter and setter methods.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

17. Method names: Multi-Objects
A message to a multi-object is interpreted as a message to the container/collection object
Java’s map, C++’s map, Smalltalk’s dictionary.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

18. Fig. 16.6 Two ways to show a collection attribute in the UML.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

19. Method Names: Language Dependent Syntax
The basic UML format for methods:
methodName(parameterList)
The type of the attributes, method parameters, and method return values may all optionally be shown.
The design class diagram should be created by considering the audience.
If it is being created in a CASE tool with automatic code generation, full and exhaustive details are necessary.
If it is being created for SW developers to read, exhaustive low-level detail may adversely effect the noise-to-value ratio.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

20. Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

21. Adding Associations and Navigability
Navigability is a property of the role which indicates that it is possible to navigate uni-directionally across the association from objects of the source to target class.
Navigability implies visibility.
Navigability is identified from Interaction Diagrams.
Most, if not all, associations in design-oriented class diagrams should be adorned with the necessary navigability arrows.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

22. Showing navigability, or attribute visibility
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

23. Association with navigability
Define an association with a navigability adornment from A to B:
A sends a message to B.
A creates an instance B.
A needs to maintain a connection to B
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

24. Associations with Navigability Adornments
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

25. Adding dependency relationships
Dependency relationship indicates that one element (of any kind, including classes, use cases, and so on) has knowledge of another element.
A dependency is a using relationship that states a change in specification of one thing may affect another thing that uses it, but not necessarily the reverse.
The dependency relationship is useful to depict non-attribute visibility between classes.
Parameters
Global or local visibility
A dashed arrow line
A dashed directed line
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

26. Dependency Relationships Non-Attribute Visibility
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

27. Notation for Method Bodies in DCDs
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

28. Interfaces The UML has several ways to show interface implementations.
Timer
getTime()
Clock1
getTime( )
The UML has several ways to show interface implementations.
Since both the socket line notation and the dependency line notation used curved lines not common in drawing tools, most people use a dependency arrow and the «interface» stereotype.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

29. UML stereotypes
A stereotype represents a refinement of an existing modeling concept and is defined within a UML profile.
UML uses stereotypes encapsulated in guillemots (« and », not << and >> ) to extend many diagram symbols.
Guillemots can be found in the latin-1 symbol set in Windows Insert Symbol command)
Examples:
«interface»
«extends»
«includes»
«actor»
«create»
«destroy»
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

30. Fig. 16.8 Stereotype declaration and use.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

31. Association Navigation
An association is a structural relationship that specifies that objects of one thing are connected to objects of another.
Navigation
Navigability is a property of the role which indicates that it is possible to navigate uni-directionally across the association from objects of the source to target class.
Navigability implies visibility.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

32. Dependency
A dependency is a using relationship, specifying that a change in the specification of one thing may affect another thing that uses it.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

33. Figure 16.10 Showing dependency.
Public class Foo {
Public void doX( ) {
System.runFinalization( );
. . . }
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

34. Figure 16.11 Optional dependency labels in the UML.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

35. Interfaces – Different Notations
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

36. Generalization
A generalization is a relationship between a general thing (called the super class or parent) and a more specific kind of that thing (called the subclass or child).
is-a-kind-of relationship.
Is this the same as OO PL inheritance?
In donain modeling, no.
In software modeling, yes.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

37. Aggregation and Composition
Aggregation – (seldomly used)
Whole/part relationship
Has-a relationship
Composition is a type of aggregation and a strong kind of whole/part relationship:
1. An instance of the part belongs to only one composite instance at a time.
2.The part must always belong to a composite, and
3.The composite is responsible for the creation and deletion of its parts. (If the composite is destroyed, its parts must either be destroyed, or attached to another composite.)
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

38. Constraints
A UML constraint is a restriction or condition on a UML element.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

39. Qualified Association
A Qualified Association has a qualifier that is used to select an object (or objects) from a larger set of related objects, based upon the qualifier key.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

40. Association Class
An association class allows you treat an association itself as a class, and model it with attributes, operations, and other features.
You will see that it is necessary to use an association class in modeling of some cases.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

41. Figure 16.17 Showing a singleton.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

42. User Defined Compartments
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

43. Active Class
An active object runs on and controls its own thread of execution. The class of an active object is an active class.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

44. Realization
A realization is a semantic relationship between classifiers in which one classifier specifies a contract that another classifier guarantees to carry out.
We use realization in two circumstances:
In the context of interfaces.
In the context of collaborations.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

45. When to create DCDs? Although this presentation of design class diagrams follows the creation of interaction diagrams, in practice they are usually created in parallel.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

46. Phases Inception Elaboration Construction
The Design Model and DCDs will not usually be started until elaboration because it involves detailed design decisions, which are premature during inception
Elaboration
During this phase, DCDs will accompany the UC realization interaction diagrams; they may be created for the most architecturally significant classes of the design.
CASE tools can reverse-engineer (generate) DCDs from source code
Construction
DCDs will continue to be generated from the source code as an aid in visualizing the static structure of the system
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

47. Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

48. Chapter 18 Designing for Visibility
“A mathematician is a device for turning coffee into theorems.” - Paul Erdös
Objectives
Identify four kinds of visibility.
Design to establish visibility.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

49. Introduction
Visibility is the ability of one object to see or have reference to another.
Q. When is visibility necessary?
A. To send a message from one object to another, the receiver object must be visible to the sender, so the sender has to have a pointer or reference to the receiver.
Those new to object design sometimes don’t think about and design to achieve necessary visibility.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

50. Q.If A sends messages to B, which must be visible to which?
A. “B is visible to A” means “A can send a message to B”.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

51. Visibility Visibility is related to the scope:
Is one resource (such as an instance) within the scope of another?
The motivation to consider visibility:
For an object A to send a message to an object B, B must be visible to A.
How visibility can be achieved from object A to object B:
Four kinds of visibility:
Attribute visibility - B is an attribute of A
Parameter visibility - B is a parameter of a method of A
Local visibility - B is a local object in a method of A
Global visibility - B is in some way globally visible.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

52. Attribute Visibility
Attribute visibility from A to B exists when B is an attribute of A.
Relatively permanent visibility because it persists as long as A and B exist
Most common form of visibility
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

53. Parameter Visibility
Parameter visibility from A to B exists when B is passed as a parameter to a method of A.
Relatively temporary visibility because it persists only within the scope of the method.
The second most common form of visibility in the OO systems.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

54. Parameter to Attribute Visibility
It is common to transform parameter visibility into attribute visibility
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

55. Local Visibility
Local visibility from A to B exists when B is declared as a local object within a method of A.
Relatively temporary visibility since it persists only within the scope of the method.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

56. Local Visibility
There are two common means by which local visibility is achieved:
Create a new local instance and assign it to a local variable.
Assign the returning object from a method invocation to a local variable.
A variation of this method does not explicitly declare a variable, but one implicitly exists as the result of a returning object from a method invocation
Ex: anObject.getAnotherObject.doSomething();
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

57. Global Visibility
Global visibility from A to B exists when B is global to A.
Relatively permanent visibility since it persists as long as A and B exist.
The least common form of visibility in OO Systems.
Ways to achieve global visibility:
Assign an instance to a global variable.
Use the Singleton pattern
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

58. Singleton Pattern (Gang of Four)
Problem:
Exactly one instance of a class is needed. Objects need a single point of access.
Solution:
Define a class method that returns the singleton object, instantiating it if it does not exist.
Example:
A print queue—many programs must access one queue.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

59. Illustrating Visibility in the UML
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

60. Visibility in the UML Public:
Any outside classifier with visibility to the given classifier can use the feature; specified by pre-pending the symbol “+”.
Protected:
Any descendant of the classifier can use the feature; specified by pre-pending the symbol “#”.
Private:
Only the classifier itself can use the feature; specified by pre-pending the symbol “-”.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

61. Terms: Classifier and Feature
A classifier is a mechanism that describes structural and behavioral features.
Modeling elements that can have instances are called classifiers.
Classifiers include classes, interfaces, datatypes, signals, components, nodes, use cases, and subsystems.
A classifier has structural feature (in the form of attributes), as well as behavioral features (in the form of operations).
A feature is a property, such as operations or attributes that is encapsulated within entity such as an interface, a class, or a datatype.
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005

62. Questions & Answers
Q. Which would you use if you wanted a relatively permanent connection?
A. attribute, or global
Q. Which would you use if you didn't want a permanent connection?
A. parameter, or local
Q. How would you create a local visibility?
A. create a new instance - use result of a method call
Q. How would you achieve a global visibility?
A. use a global variable in C++, static (or class) variable (in C++ or Java) - use the Singleton pattern (a static method that returns the object)
Dr. Kivanc Dincer
CS319 Week 7 - Oct.24,2005