Objects, Classes, and Basic Class Diagrams

1
Objects, Classes, andBasic Class Diagrams

• CS/SWE 421
• Introduction to Software Engineering
• Dan Fleck
• (Slides adapted from Dr. Stephen Clyde with
  permission)

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

3
Introduction to Objects

• What arent objects?
• Events (sometimes)
• Relationships between objects (most of the time)
• Behavior (most of the time)
• Constraints (most of the time)

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

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

6
Introduction to Classes

• Examples of classes in a Student Records
  Management System

Student
Course
College
Class Section
Instructor
Semester
Department
Major
Class Grade
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

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
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
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 classs
  common properties

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 PackageStudent
• More on packages later

12
Exercise Class Identification

• Identify meaningful classes in the Elevator System

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

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)

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

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

20
Exercise Attributes

• Describe meaningful attributes for the key
  classes in the Elevator System

21
Operations

• Meaning from three perspectives
• Analysis Ways in which objects interaction
• Specification An obligation to provide a
  service
• Implementation A function member, a method

22
Operations
Student
Class Section
major String GPA Real standing String
name String capacity Integer
takesgt
add(Student) drop(Student) checkPrerequisites(Stud
ents)
add(Class Section) drop(Class Section)
lthas
Prerequisite
Course
23
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

24
Type of Relationships in Class Diagrams
A consolidated snippet of the UML Meta-model
Relation
Generalization
Association
Dependency
Binary Association
N-ary Association
Aggregation
25
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.

26
Associations
is registered forgt
Student
Semester
takesgt
is held duringgt
teachesgt
Class Section
Instructor
ltworks for
is instance ofgt
sponsorsgt
Course
Department
27
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

28
Navigation

• The navigation of associations can be
• uni-directional
• bi-directional
• unspecified

teachesgt
Class Section
Instructor
ltworks for
is instance ofgt
sponsorsgt
Course
Department
29
Navigation

• Bi-directional navigation means more than just
  being able to traverse the association in both
  directions

Instructor
If instructor x is associated with department y,
then department y must be associated with
instructor x
ltworks for
Department
30
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
• Why?

31
N-ary Associations

• Associations can connect more than one class
• Notation

Student
Advisor
Major

• How should we go about naming an n-ary
  association?

32
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
Student
Person
33
Generalization

• From a specification perspective, generalization
  can represent sub-typing, interface inheritance,
  type capability, and substitutability

Student
Person
major String GPA Real standing String
name String address String
add(Class Section) drop(Class Section)
changeAddress(new_address)
34
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)
35
Exercise Simple Associations

• From an analysis perspective
• Identify meaningful associations and
  generalization/specializations among classes in
  the Elevator System

36
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

37
Class Diagrams

• Class diagrams are collections of
• Classes and individual objects
• Associations, generalizations, and other kinds of
  relationships
• They can also include
• Grouping concepts like packages
• Constraints
• Various kinds of annotations

38
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

39
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

40
Multiplicity Constraints for Associations

• Multiplicity constraints define how many objects
  a given object can be linked to for a given
  association
• A multiplicity constraint is placed near the
  connection of an association to an object class

41
Multiplicity Constraints
is registered forgt
Student
Semester
1..
0..
1
takesgt
is held duringgt
0..8
1..
teachesgt
Class Section
Instructor
0..6
1..3
1..
ltworks for
is instance ofgt
1
sponsorsgt
1..
1
Course
Department
42
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

43
Dependencies
A consolidated snippet of the UML Meta-model
Relation
Generalization
Association
Dependency
Binary Association
N-ary Association
Aggregation
44
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)
45
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

46
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?

47
Aggregations (is part of)
A consolidated snippet of the UML Meta-model
Relation
Generalization
Association
Dependency
Binary Association
N-ary Association
Aggregation
48
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
1

1
Sauce Serving
Pizza
Order
1..3
1
1
Cheese Serving
4..
0..9
1
Topping Serving
Slice
49
Questions

• What do classes and associations in class
  diagrams really mean?
• Whats 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?

50
More Questions

• How does one choose a level of abstraction for
  modeling the objects of a system?
• 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?

51
More Questions

• How do you know when a class diagram is complete?
• How can you make the information captured in a
  class diagram more understandable? maintainable?
  reusable?
• 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?