1. UML Class Diagrams

2. Unified Modeling Language (UML)
Set of MANY (visual) modeling techniques
use case diagram
class diagram
object diagram
component diagram
deployment diagram
sequence diagram
collaboration diagram
statechart diagram
activity diagram
Only 20% are necessary to represent 80% of most systems
Static Views
Dynamic Views

3. Unified Modeling Language (UML)
Set of MANY (visual) modeling techniques
use case diagram
class diagram
object diagram
component diagram
deployment diagram
sequence diagram
collaboration diagram
statechart diagram
activity diagram
Only 20% are necessary to represent 80% of most systems
Static Views
Dynamic Views

4. Historical Note: Entity Relationship Diagrams
name
age
student
gender
entities n
student ID
enrolled in
attributes
relationship
between
entities m
subject
class
course ID
max-enroll 4

5. Class Diagrams Entity Relationship SimpleWatch 1 1 1 1 2 1 2 1
PushButton
state
push() release()
LCDDisplay
Battery
load()
Time
now()
blinkIdx
blinkSeconds()
blinkMinutes()
blinkHours()
stopBlinking()
referesh()

6. Class Diagrams - Entities
Entities are abstractions of elements with common characteristics; at the finest-grained level they correspond to classes
Entities have three basic components:
Name
Attributes
Operations
zone2price
getZones()
getPrice()
TariffSchedule
Name
Attributes
Operations
Instance
zone2price = {
{‘1’, .20}, {‘2’, .40},
{‘3’, .60}}
tariff_1974:TarifSchedule

7. Relationships Between Classes
Classes are related to each other via:
Generalization
Association
Aggregation

8. Generalization Generalization is implemented via “Inheritance”
Children inherit attributes and operations of parent; the parent “generalizes” attributes and operations that apply to the children
Generalization eliminates redundancy, and supports incrementality

9. Associations
Associations are relations between entities, and can be named
Endpoints can note “multiplicity constraints”
Potential multiplicity values: 1
0..1
0..n
1..n *
1..*

10. Aggregation
Aggregation is a special case of an association, and defines a “part of” relationship
The aggregate is a parent class, the components are children classes
Multiplicity can be used here too
Exhaust System
Part-Of 1
0..2
Muffler
Tailpipe 34

11. Mapping to Ghezzi’s Terms
Inheritance, Association, and Aggregation are all forms of USES
Representation of IS_COMPONENT_OF is done via the package notation

12. Packages
Organize classes into packages to simplify complex class diagrams
A package is a collection of logically related UML elements.

13. Entities (Expanded) Person + name : String - ssn : String
Visibility
+ public
# protected
- private
Person
+ name : String
- ssn : String
# birthday : Date
age : int
+getName : String
-calculateAge : int
Visibility AttributeName:Type = Initial Value
Visibility MethodName (Parameter List) : Return-List
Protected = visible to classes that are inherited from this one

14. Visibilities
Public (+): Any outside class can use the feature (method or data)
Private (-): Only the class itself can use the feature
Protected (#): Any descendant of the class can use the feature (pertains to the generalization relationship)

15. Aggregation (Expanded)
Simple Aggregation
Composite Aggregation
With composite aggregation, the
part objects may belong to only one
whole, and are expected to live and
die with the whole.

16. Self-relations
manages
employee

17. Navigabilities Bi-Directional Navigability:
An Order has a responsibility
to tell me which Customer it
is for, and a Customer has a
responsibility to tell me which
Orders it has.
Customer
Order ID
Date
price
Name
Address
Ordered by *  1 
Uni-Directional Navigability:
An Order has a responsibility
to tell me which Customer it
is for, but a Customer has no
responsibility to tell me which
Orders it has.
Customer
Order ID
Date
price
Name
Address
Ordered by *  1 

18. Navigabilities
Some people choose to interpret an association edge with no navigability arrows on it as being Bi-directional. Others choose to interpret such an edge as saying that navigability is not yet specified.
The latter interpretation facilitates the specification of conceptual models; navigabilities can be added when we move to the specification/implementation models.

19. Association Classes Book Patron Checks Out Association Class
are attributes of relationships
between classes; there can
be only one instance of
the association class between
any two participating objects
Association
Class

20. Levels of Class Diagrams
Conceptual perspective – represents concepts in the domain under study
Specification perspective – adds interfaces into the picture; what do classes export? How are associations kept track of?
Implementation perspective – adds other elements
An incremental refinement process moves you from the first to the last
We start with initial analysis to create a high-level conceptual or domain model of the application. This typically contains just classes and maybe a few attributes.
At the specification level, we complete all the major attributes, the public methods and understand the class relationships and their cardinalities.
At the implementation level, we have translated all the relationships and cardinalities to data structures, and have identified additional classes necessary for implementation.

21. Constructing Class Diagrams
Identify objects
Construct conceptual perspective – concepts in the domain under study
Refine to specification perspective – add interfaces into the picture and specify relationships more precisely
Refine to implementation perspective – add other elements
We start with initial analysis to create a high-level conceptual or domain model of the application. This typically contains just classes and maybe a few attributes.
At the specification level, we complete all the major attributes, the public methods and understand the class relationships and their cardinalities.
At the implementation level, we have translated all the relationships and cardinalities to data structures, and have identified additional classes necessary for implementation.

22. Object Identification
No “magic formula”
It relies on the skill, experience and domain knowledge of system designers
Iterative process. Unlikely to get it right first time
Approaches for identification
Use a grammatical approach
Identify tangible things
Identify objects based on participation in behaviours
Use a scenario-based analysis
Use domain knowledge for refinement

23. Library Checkout System: Conceptual Level
Patron
Book
Checks Out id
name
age
isbn
title
author
outDate
returned
fines

24. From Conceptual Level to Specification Level
Book
Patron
Book
Checks Out id
name
age
isbn
title
author
outDate
returned
fines
Author
isbn:string
title:string
name:string
written by
1..5 * 1
Patron
BookCopy
id:int
name:string
age:int 1
0..5
copy_num : int
1..*
represented by
Checks Out
outDate:date
returned:date
fines:currency

25. From Specification Level to Implementation Level
Book
Author
#isbn:string
#title:string
#name:string
written by
1..5 *
Author
Book
#isbn:string
#title:string
#writtenby[5]: Author
#name:string
# writtenby :List<Book>

26. From Implementation Level to Code
Author
public class Author {
protected:
std::string name;
std::list<Book> writtenby; }
public class Book {
std::string isbn;
std::string title;
Author writtenby[5];
#name:string
# writtenby :List<Book>
Book
#isbn:string
#title:string
#writtenby[5]: Author

27. Class Diagram Hints
Use initially to provide an abstraction of the problem domain, then refine further
Keep a clear separation between specification and implementation
Keep them understandable
Beware of cyclical generalization
Use associations where there are relationships

28. Example: Simple Online Bookstore
Customers search for and select books, order them, provide credit card information to pay for them, and provide delivery information. Information on valid sales (sales for which the credit card is approved) is forwarded to a warehouse where ordered books are collected and shipped. Invalid sales are declined.

29. Examples of Class Diagram
e.g.,
e.g.,