Objects, Classes, and Basic Class Diagrams - PowerPoint PPT Presentation

About This Presentation
Title:

Objects, Classes, and Basic Class Diagrams

Description:

Objects, Classes, and Basic Class Diagrams CS/SWE 421 Introduction to Software Engineering Dan Fleck (Slides adapted from Dr. Stephen Clyde with permission) – PowerPoint PPT presentation

Number of Views:135
Avg rating:3.0/5.0
Slides: 51
Provided by: Preferr1856
Learn more at: https://cs.gmu.edu
Category:

less

Transcript and Presenter's Notes

Title: 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
  • 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?

30
N-ary Associations
  • Associations can connect more than one class
  • Notation

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

31
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
32
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)
33
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)
34
Exercise Simple Associations
  • From an analysis perspective
  • Identify meaningful associations and
    generalization/specializations among classes in
    the Elevator System

35
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

36
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

37
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

38
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

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

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

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

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

Building
Room
48
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

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 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 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?
Write a Comment
User Comments (0)
About PowerShow.com