1. Objects, Classes, and Basic Class Diagrams
CS/SWE 421
Introduction to Software Engineering
Dan Fleck
(Slides adapted from Dr. Stephen Clyde with permission)
Additional information:
Coming up: Introduction to Objects

2. Introduction to Objects
Objects are the fundamental building blocks of object-oriented systems
What is an object?
It represents any “thing”
It has a boundary in space and time
It is an abstraction
It encapsulates state and/or behavior
It has identity
Coming up: Introduction to Objects

3. Introduction to Objects
What aren’t objects?
Events (sometimes)
Relationships between objects (most of the time)
Behavior (most of the time)
Constraints (most of the time)
Coming up: Exercise - Object Hunt

4. Exercise - Object Hunt
Part 1 - List examples of objects in the Third National Bank Elevator System
Part 2 - List some concepts from this system that would not typically be modeled as objects
Coming up: Introduction to Classes

5. Introduction to Classes
Most systems have large numbers of objects that come and go throughout the systems’ lifetimes
Humans naturally classify similar things by their observable properties
Watch how little children reference things
Classes are abstractions that allow us to deal with whole collections of objects that share some commonalties
Coming up: Introduction to Classes

6. Introduction to Classes
Examples of classes in a Student Records Management System
Student
Course
College
Class Section
Instructor
Semester
Department
Major
Class Grade
Coming up: Three Perspectives

7. Three Perspectives
Objects and classes, as well as all other modeling components in UML, can be interpreted from different perspectives:
Three common perspectives:
Analysis - description of the problem domain
Specification - logical description of software system
Implementation - description of software components and their deployment
Coming up: Classes from different Perspectives

8. Classes from different Perspectives
Meaning from three perspectives
Analysis: sets of objects
Specifications: interfaces to encapsulated software representations of objects
Implementations: abstract data types
Analysis
Specification
Implementation
Student
Student
Student
{Joe, Sue, Mary, Frank, Tim, …}
Interface Student {…}
class Student {…}
Coming up: Class Syntax

9. Class Syntax A box divided into compartments Name Attributes
Operations
Responsibilities
Used-defined compartments
Student
major: String
gpa: Real
standing: String
add(Class Section)
drop(Class Section)
-- The set of students known to the registration system
-- An exception occurs if gpa falls below 2.0
Coming up: Class Names

10. Class Names The name should be a noun or noun phrase
The name should be singular and description of each object in the class
The name should be meaningful from a problem-domain perspective
“Student” is better than “Student Data” or “S-record” or any other implementation driven name
Avoid jargon in the names
Try to make the name descriptive of the class’s common properties
Coming up: Class Name Syntax

11. Class Name Syntax
A class name may be text consisting of any numbers, letters, and punctuation marks (except “:”)
Capitalize each word that makes up the name
A class name can include a path specification, if the class is part of a package.
“Records Management Package::Student”
More on packages later
Coming up: Exercise – Class Identification

12. Exercise – Class Identification
Identify meaningful classes in the Elevator System
Coming up: Return to Objects – Object Syntax

13. Return to Objects – Object Syntax
Object syntax is similar to class syntax, except
the name identifies specific or generic object
the name includes the class that the object belongs to
Remember, individual objects are instances of classes
joe: Student
major: String = “CS”
gpa: Real = 4.0
standing: String = “”
add(Class Section)
drop(Class Section)
Coming up: Object Name Syntax

14. Object Name Syntax
The name includes an the instance name and a class path, separated by a “:”
The instance name is typically lower case
The instance name be may blank, meaning an arbitrary object from the designated class
The class path name may include a path
The whole name is underlined
Coming up: Attributes

15. Attributes
Attributes represent characteristics or properties of objects
They are place holders or slots that hold values
The values they hold are other objects
The name of an attribute communicates its meaning
An attribute can be defined for individual objects or classes of objects
If defined for a class, then every object in the class has that attribute (place holder)
Coming up: Attributes from an Analysis Perspective

16. Attributes from an Analysis Perspective
An attribute relates an object to some other object
It has the same semantics as an association
joe: Student
Is basically the same as ...
name: String = “Joe Jones”
name
joe: Student
Joe Jones : String 1
Coming up: Attributes from a Specification Perspective

17. Attributes from a Specification Perspective
An attribute represents an obligation to provide or manage a certain (single) piece of information
For example, each Student object must be able to encapsulate a major, a GPA, and a standing
Student
major: String
gpa: Real
standing: String
Coming up: Attributes from an Implementation Perspective

18. Attributes from an Implementation Perspective
Attributes from an implementation perspective are similar data members in C++ or Java
They are place holders with value semantics
Each object can have different values
Constraints can be placed on the attributes to restrict how and when the values can be changed
Coming up: Attribute Syntax

19. Attribute Syntax
[visibility] name [multiplicity] [:type] [=initial-value]
[{property-string}]
visibility: public “+”, protected “#”, or private “-”
name: capitalize first letter of each word that makes up the name, except for the first
multiplicity: number, range, or sequence of number or ranges.
type: build-in type or any user-defined class
initial-value: any constant and user-defined object
property-string: e.g, changeable, addOnly, frozen
Coming up: Exercise – Attributes

20. Operations Meaning from three perspectives
Analysis: Ways in which objects interaction
Specification: An obligation to provide a service
Implementation: A function member, a method
Coming up: Operations

21. Operations Student Class Section major: String GPA: Real
standing: String
name: String
capacity: Integer
takes>
add(Student)
drop(Student)
checkPrerequisites(Students)
add(Class Section)
drop(Class Section)
<has
Course
Prerequisite
Coming up: Operation Syntax

22. Operation Syntax [visibility] name [(parameter-list)] [:return-type]
[{property-strong}]
visibility: “+”, “#”, “-”
name: verb or verb phase, capitalize first letter of every word, except first
parameter-list: coma separated list of parameters
return-type: primitive type or user-defined type
property-string: isQuery, sequential, guarded, concurrent
Coming up: Type of Relationships in Class Diagrams

23. Type of Relationships in Class Diagrams
A consolidated snippet of the UML Meta-model
Relation
Generalization
Association
Dependency
Binary Association
N-ary Association
Aggregation
Coming up: Associations

24. Associations
An association is a structural relationship that specifies that objects of class may be connected to objects of another class
Meaning from three perspectives
Analysis: Links between objects
Specification: Obligation to provide a connection between objects
Implementation: Object pointers, references, linking structures, etc.
Coming up: Associations

25. Associations is registered for> Student Semester takes>
is held during>
teaches>
Class Section
Instructor
<works for
is instance of>
sponsors>
Department
Course
Coming up: Association Names

26. Association Names Associations may be named
The names should communicate the meaning of the links
The names are typically verb phases
The words that make up the name are typically all lowercase
The name should include an arrow indicating the direction in which the name should be read
Some kinds of associations have implied names
Coming up: Navigation

27. Navigation The navigation of associations can be uni-directional
bi-directional
unspecified
teaches>
Class Section
Instructor
<works for
is instance of>
sponsors>
Department
Course
Coming up: Navigation

28. Navigation
The navigation of association without an arrowhead is assumed to be undefined
Navigation has little value when modeling from a conceptual perspective
Why?
Navigation is more important from specification and implementation perspectives
Navigation provides information that helps optimize a design.
Coming up: N-ary Associations

29. N-ary Associations How should we go about naming an n-ary association?
Associations can connect more than one class
Notation:
Student
Advisor
Major
The names of n-ary associations should contain the names of all the classes, e.g. “Advisor advises Student in Major”.
How should we go about naming an n-ary association?
Coming up: Generalization

30. Generalization
Generalization is another kind of relationship in UML – see Meta Model
From an analysis perspective, it is a pure generalization/specialization concept, i.e., the specialization is a subset of the generalization
Graduate Student
Person
Student
Coming up: Generalization

31. Generalization
From a specification perspective, generalization can represent sub-typing, interface inheritance, type capability, and substitutability
Student
Person
major: String
GPA: Real
standing: String
The notations of sub-typing, interface inheritance, type capability, and substitutability are close related, but are distinction ideas. Their subtle differences probably go beyond the scope of this course.
name: String
address: String
add(Class Section)
drop(Class Section)
changeAddress(new_address)
Coming up: Generalization

32. Generalization
From an implementation perspective, a generalization can represent implementation inheritance (depending on developing environment)
Student
Person
major: String
GPA: Real
standing: String
name: String
address: String
add(Class Section)
drop(Class Section)
changeAddress(new_address)
Coming up: Exercise – Simple Associations

33. Exercise – Simple Associations
From an analysis perspective:
Identify meaningful associations and generalization/specializations among classes in the Elevator System
Coming up: Class Diagrams

34. Class Diagrams Class Diagrams describe
the types of objects in a system
their properties (attributes and operations)
relationships between objects
Class Diagrams are similar to entity-relationship (ER) data models, but show classes instead of data entities
Coming up: Class Diagrams

35. Class Diagrams Class diagrams are collections of They can also include
Classes and individual objects
Associations, generalizations, and other kinds of relationships
They can also include
Grouping concepts like packages
Constraints
Various kinds of annotations
Coming up: Class Diagrams

36. Class Diagrams
Class Diagrams are like the paragraphs of a technical paper
each diagram should focus on a specific topic
a diagram provides supporting detail for the main concept(s) that it is trying to communicate
the level of the abstraction used in the diagrams should be consistent
Together, all the diagrams for a system comprise a “model” of that system
Coming up: Class Diagrams

37. Class Diagrams Pitfalls of Class Diagrams:
Using class diagrams alone can cause developers to focus too much on structure and ignore behavior
Using the wrong (or a mixed) perspective can lead to misunderstanding
Using the wrong level of abstraction can be confusing to the target audience
Using mixed levels of abstraction can reduce the usefulness of diagram
Coming up: Multiplicity Constraints

38. Multiplicity Constraints
is registered for>
Student
Semester
1..*
0..* 1
takes>
is held during>
0..8
1..*
teaches>
Class Section
Instructor
1..3
0..6
1..*
<works for
is instance of> 1
sponsors> 1
1..*
Department
Course
Coming up: Multiplicity Constraints

39. Multiplicity Constraints
A multiplicity constraint can be
a single number
a “*”, meaning an arbitrarily large number or simply “many”
a range, denoted by “min..max”
a sequence of single numbers and ranges
Coming up: Dependencies

40. Dependencies A consolidated snippet of the UML Meta-model Relation
Generalization
Association
Dependency
Binary Association
N-ary Association
Aggregation
Coming up: Dependencies

41. Dependencies A dependency is a type of relationship
It says that one modeling component “uses” another.
If the later changes then, the former may have to change as well
Student
Prerequisite
add(Course)
drop(Course)
Coming up: Dependencies

42. Dependencies Meaning from three perspectives
Analysis: physical or logical dependency between the connected classes
Specification: a “uses” relationship at an interface level
Implementation: a “uses” relationship at an implementation level.
Some kinds of dependencies can be inferred if the component definitions are complete
Coming up: Dependencies

43. Dependencies
Syntax:
a dashed link with an straight-line arrowhead point to a component on which there is a dependency
Dependencies can be defined among: classes, notes, packages, and other types of components
Can dependencies go both ways?
Any problems with having lots of dependencies?
Coming up: Aggregations (is part of)

44. Aggregations (is part of)
A consolidated snippet of the UML Meta-model
Relation
Generalization
Association
Dependency
Binary Association
N-ary Association
Aggregation
Coming up: Aggregation

45. Aggregation
Aggregation: is a special kind of association that means “part of”
Aggregations should focus on single type of composition (physical, organization, etc.)
Crust 1 1 1
Sauce Serving 1 1
Pizza *
Order
1..3 1 1
Cheese Serving
0..9 1
4..*
Topping Serving
Slice
Coming up: Composition (very similar to aggregation)

46. Composition (very similar to aggregation)
Think of composition as a stronger form of aggregation. Composition means something is a part of the whole, but cannot survive on it’s own.
Room
Building
Coming up: Using a class diagram

47. Validating a class diagram
One of the most important, and often overlooked issues is how to validate a class diagram.
Given a specification or a use-case, can you look at the class diagram and use features of it to manually “execute” the use case.
Lets try it for the WeGrow class diagram
Coming up: Questions

48. Questions
What do classes and associations in class diagrams really mean?
What’s the difference between an attribute and an association with another class? For example, should “grade” be an attribute or a link to another class called “Grade”?
How can we show relationships involving more than two classes?
When during the software engineering life cycle should you build classes diagrams?
Ended here on 2/6/08
Coming up: More Questions

49. More Questions
How does one decide how to break up the responsibilities of a system into meaningful classes?
How do you know if you have identified the best classes for a system?
How do you know where in a class hierarchy a particular attribute or operation bests fit?
Coming up: More Questions

50. More Questions How do you know when a class diagram is complete?
How can you manage change control on all the class diagrams for project?
What do you do with class diagrams after a system has been built and delivered?
Coming up: More Questions