1. Class Diagrams – Part I
Chapter 3

2. Classes and Objects Classes are the descriptions
definitions
Objects are the things
instances

3. Objects What’s an object?
It’s a “thing” that interacts with other “things” to address the task at hand
It contains attributes (data items) which represent its current state
It contains methods (functions) which are used to manipulate it
CSC535

4. Objects What’s an object?
An object is a grouping of attributes and behaviors into a single entity
CSC535

5. Primary and Support Objects
What’s a primary object and what’s a support object?
Primary objects
Those that are obvious
Those that are fundamental to the system
Those on which all team members agree must be included in the system (without persuasion)
Support objects
Those that you really have to stretch to come up with
Those which cause debates among team members
Those which you’re just not sure about
CSC535

6. Primary and Support Objects
Identify primary objects early in the design process
This should be relatively easy
Leave the support objects for later (maybe even for the implementation phase)
Don’t hesitate to change the list of primary objects as the design progresses
Actually, it’s expected to change
Eventually, they’ll all be primary objects since they compose the running system and without them the system will fail [to compile/link/bind at runtime]
CSC535

7. Tangible and Intangible Objects
What’s a tangible object and what’s an intangible object?
Tangible objects generally represent things (nouns) within the system
Intangible objects generally represent calculations (verbs) within the system
It’s not important to specify whether an object is tangible or intangible
It is important to consider both types of object when identifying objects
CSC535

8. Object Identification
How do you identify objects?
Nouns
People
Places
Things
Things with multiple use
Things that store data or state
Things that are composites of other things
Things that are ancestors of other things
Things that perform a useful function
CSC535

9. Object to Object Relationships
How do objects relate to one another?
Inheritance (“is-a” relationship)
Association/Composition (“has-a” relationship)
Application specific (neither of the above)
CSC535

10. UML Class Symbol
Class
In the early stages of the design you should not be overly concerned (or concerned at all?) with the attribute and method fields
CSC535

11. UML Relationship Symbols
Inheritance (Generalization) (“is-a”)
CSC535

12. UML Relationship Symbols
Association/Composition (“has-a”)
Containing contains 1 Contained Class object
An instance of Contained Class may belong to either Containing Class 1 or 2 but not both
CSC535

13. UML Relationship Symbols
Association/Composition (“has-a”)
There is also something called aggregation which is nothing more than association
Most use the association arrow and not the aggregation diamond

14. UML Relationship Symbols
Application Specific (association)
Use this when two objects are related but not by a “has a” or “is a” – you shouldn’t really need to do this but you might
CSC535

15. UML Relationship Symbols
Dependency
CSC535

16. Class Diagram
The result of identifying objects (classes) and their relationships will be a UML Class Diagram
The Class Diagram represents the static (unchanging) nature of the system design
It represents compile-time relationships, not run-time usage
We will revisit class diagrams later, adding more detail
CSC535

17. Object Identification Guidelines
Eliminate all preconceived notions.
Don’t strive for perfection…yet.
Don’t get into heated debates over the inclusion or exclusion of a class…yet.
If you do debate, realize the difference between a debate and an argument
Debate – good
Argument – bad
Don’t get formal…yet.
Remember that UML can be used in “sketch”, “blueprint”, and “programming language” modes – concentrate on “sketch” right now
Don’t toss out far fetched ideas too soon.
Remember the difference between interface and implementation
Don’t think about the implementation right now.
Think about code reuse.
Keep in mind that this is an iterative process.
CSC535

18. Deliverables
Informal Scenarios
Scenarios
Use Case Diagram
CSC535