Transcript + + The Class Diagram

CSIS3600 Systems Analysis and
Design
Class Identification and Class
Diagrams
Objects
• In object oriented analysis, the world is modeled
in objects.
• Objects are entities that have a well-defined role
within the system.
• An object can be tangible or visible (i.e. person,
place or thing) or a concept of event (department,
registration, etc.) or an artifact of the design
process (user interface, scheduler, etc.).
• Objects are nouns.
Object Properties
• Objects are described both by their properties
(attributes and relationships) and by their behavior
(how the object acts and reacts).
• Objects represent categories while an object
instance is a specific occurrence of the object.
• To remove any confusion, some texts use the
terminology object class to refer to the set of
objects.
Object Defined
An object is an entity which has a state and a defined set of
operations which operate on that state. The state is
represented as a set of object attributes. The operations
associated with the object provide services to other objects
(clients) which request these services when some computation
is required. Objects are created according to some object class
definition. An object class definition serves as a template for
objects. It includes declarations of all the attributes and
services which should be associated with an object of that
class.
Ian Summerville, Software Engineering, 2000
Object Encapsulation
• Object encapsulation is the term used to describe the
representation of objects by their attributes and behavior.
• It is important to remember that an object is "solely
responsible for carrying out any functions or behaviors that
act on its own data."
• The internal workings of an object are private - other
objects can see only the interface.
• You should also note that the attributes of an object can be
other objects and the behavior of an object can use other
objects.
Object Classification
Objects are represented by classification and
class hierarchies. Several principles relate to
this process. These include:
 Class - an abstraction describing objects of the
same kind.
 Object - instance of a class. Objects contain
attributes - data property of an object (variable,
etc.) and methods - behavioral property of an
object (operation, function, etc.) Methods are
invoked by a call (message).
Object Classification continued
 Inheritance - relationship between a more specialized class
and its more generalized parent class.
 Generalization/specialization - Abstracting common
features (attributes and operations) among multiple classes
into a more general class.
 Supertype - class that stores attributes common to one or
more class subtypes of the object.
• Subtype - a class who inherits some common attributes
from a class supertype and adds attributes that are unique
to the subtype.
Understanding Classes
A class is a collection of objects with a common
structure, common behavior, common relationships
and common semantics.
– class name: noun representing the class domain.
– attributes: characteristics of the class - identified by
examining class definitions, problem requirements and
domain knowledge - current attribute values define an
object's state.
– behaviors: represents operations and functions and are
found by examining object interactions
Object Identification
• Identifying objects is the most difficult part of
object oriented design.
• There is no 'magic formula' for object
identification. It relies on the skill, experience .
and domain knowledge of system designers.
• Object identification is an iterative process. You
are unlikely to get it right first time.
Example of Single Class Diagram(s)
Classes are drawn as a rectangle with three compartments:
Class Name
Course
Attributes
…
…
Name
Number of
Credits
Methods
…
…
Open
AddStudent
Student
Name
StudentID
Year
...
Calc-age ()
Calc-gpa
Register for (course)
...
Object Instance Diagram
• An object diagram is also known as an instance
diagram or a graph of instances that are
compatible with a given class diagram.
UML Class and Object Diagrams
(a) Class Diagram
Showing Two Classes
(b) Object Diagram with
Two Instances
An office information system
• The Office Information Retrieval System (OIRS) is
an automatic file clerk which can file documents
under some name in one or more indexes, retrieve
documents, display and maintain document
indexes, archive documents and destroy
documents. The system is activated by a request
from the user and always returns a message to the
user indicating the success or failure of the request.
Document
Index
User
Name
Name
UserID
File
Retrieve
Archive
Destroy
Display
Delete entry
Add entry
Get command
Put message
Retrieval
System
User command
Preliminary Object Identification
Document
Index
User
Name
Name
UserID
File
Retrieve
Archive
Destroy
Display
Delete entry
Add entry
Get command
Put message
Retrieval
System
User command
• Nouns in the description give pointers to objects in the system.
• Verbs give pointers to operations associated with objects.
• Approach assumes that the designer has a common sense
knowledge of the application domain as not all objects and
services are likely to be mentioned in the description.
Operations
Operations are functions or services provided by all
instances of a class (calc-gpa, delete, display, etc.).
There are three types of operations:
– Constructor – creates a new instance of a class.
– Query – Accesses a state of an object but does not alter
the state.
– Update – it alters the state of an object.
Document
Index
Name
Name
File
Retrieve
Archive
Destroy
Display
Delete entry
Add entry
User
Retrieval
UserID
Get command
Put message
User command
A Word on Attributes
• Visibility of attributes may be shown
– Visibility relates to information hiding
• + public – not hidden from any other object
• # protected – hidden from all classes except its
immediate subclass
• - private – hidden from all other classes
Document
+Name
File
Retrieve
Archive
Destroy
Index
+Name
Display
Delete entry
Add entry
User
UserID
Get command
Put message
Retrieval
User command
The Class Diagram
The class diagram is a central modeling technique
that runs through nearly all object-oriented methods.
This diagram describes the types of objects in the
system and various kinds of static relationships
which exist between them.
There are three principal kinds of relationships:
–
associations (a customer may rent a number of
videos)
– subtypes (a nurse is a kind of person)
–
aggregation (an engine is part of an aircraft).
(note:one class can be part of many class diagrams.)
Example Class Diagram
Perspectives of Class Diagrams
There are three perspectives you can use in drawing class diagrams
 Conceptual: In this case you are drawing a diagram that represents the
concepts in the domain under study. These concepts will naturally relate to
the classes that implement them, but it is often not a direct mapping.
Indeed the model is drawn with little or no regard for the software that
might implement it.
 Specification: In this case, you are looking at software, but you are
looking at the interfaces of the software, not the implementation. We are
thus looking at types rather than classes.
 Implementation: In this view we really do have classes and we are laying
the implementation base. This is probably the most often used perspective
in the design phase of systems development, but in many ways the
specification perspective is often a better one to take.
Perspective continued
• Understanding the perspective is crucial to drawing and reading the
class diagram.
• The perspective determines its use.Remember OOAD is iterative.The
conceptual diagram is refined for specification and implementation.
Basic Elements of Class Diagrams
On a class diagram, it is recommended that
only the most often needed elements be listed
These include
 Class
 Relationship:
Generalization
Associations
 Multiplicity
Symbols of the Class Diagram
• Box – Represents the class.Broken down into 3 parts –
Name, attributes and operations
• Line – represents association with number representing
multiplicity.Line with an arrow represents navigation
• Connecting lines with arrows – represent generalization of
superclass – subclass
• {} - constraints or rules – provided for major constraints
only
• open diamond – shows aggregation (closed diamond
shows composition)
• Box with flipped edge depicts notes
Representing Notes (business rules)
Class Relationships
• Relationships between classes are
discovered by examining interactions
between objects.
• If two objects must 'talk,' there must be a
pathway for communication.
Types of Relationships
There are three primary types of relationships
 Generalization – enables inheritance of attributes and
operations. Shown as connecting lines with arrows
 Association - a bi-directional connection between classes.
Shown as a line connecting related classes.
 Aggregation - stronger from of relationship between a
whole and its parts. Shown as a line connecting the related
classes with a hollow diamond next to the class representing
the whole.
 Dependency - weaker form of relationship showing a
relationship between a client and a supplier where the client
does not have a semantic knowledge of the supplier. Shown
as a dashed line pointing from the client to the supplier.
Association Naming on Class
Diagrams
• Associations are named - use verbs that have
meaning – ie is-contained
• Sometimes they imply messages to be sent
• Roles (each end of the association) are named if
needed or if the association is between objects of
the same class
Diagram role naming
Derived Attributes, Associations
and Roles
• Derived attribute, association or role is one
that can be computed or derived from other
attribute, associations and roles.
• A derived element is shown by placing a
slash / before the name of the element
Derived Attribute, Association, and Role
• Age is derived attribute of student – calculated from date of birth and
current date – shown in braces.
• Takes is derived because it can be inferred from the other relationships
Registers-for and Schedule-for
• Participants is derived because it can be derived from other roles.
Relationship Attributes/Operations
• Some relationships
have attributes and
operations.
• They are added as an
association class and
depicted with a dashed
line.
• The association class
does not exist without
the original association.
Performer
Performance
Performance
Contract
Relationship Association Example
Purchase
Customer
/ total
service charge
delivery charge
facility charge
sales tax
name
addresss
credit card
area code
phone no.
calculate total()
sum purchase price()
receive payment ()
claculate change()
add item()
Charge
exiration date
account number
issuer
authorize credit ()
Aggregation
Aggregation - stronger from of relationship between
a whole and its parts. Shown as a line connecting the
related classes with a hollow diamond next to the
class representing the whole.
 a stronger form of aggregation is composition (depicted
with a solid diamond). Composition is used when a part
object belongs t only one whole object and lives and
dies with the whole object – room in a building.
Aggregation and Composition
(a) Class Diagram
(b) Object Diagram
Adding Inheritance
• Inheritance is a relationship between a
superclass and its subclasses.
• There are two ways to find inheritance generalization and specialization.
• Inheritance identifies common attributes,
operations and/or relationships and places
them at the highest level in the hierarchy.
• Inheritance reduces redundancy and
improves efficiency.
Abstract
• An abstract class is a class that has no direct
instances(Concrete class is a class that has
direct instances).
– Examples include university students who must
be identified by their standing.The abstract
class is student but student does not have any
direct instances. Student descendants –
Graduate and Undergraduate have instances.
• Abstract classes are shown in italics or
{abstract} with the word abstract in braces.
Adding Multiplicity
• Multiplicity is also shown between class relationships (as
is done with cardinality in ER diagrams).
• Multiplicity defines how many objects participate in a
relationship. Multiplicity is bi-directional - one for each
end of the relationship. When thinking of multiplicity, you
define it as the number of instances of one class related to
the ONE instance of the other class.
• While associations and aggregation are bi-directional by
default, is often desirable to restrict navigation to one
direction. If this is done, an arrowhead is added to indicate
the direction of the navigation.
Examples of Association Relationships of
Different Degrees
Object Diagrams
• A method used to quickly identify
relationships is the Object Diagram.
• In its simplest form, an Object Diagram
depicts classes and their relationships to
other classes without adding detail.
• The object diagram is used as a tool upon
which the Class Diagram can be built.
Example Object Diagram
Once Again – Rules on Modeling
Class diagrams are the backbone of OO methods soused quite
frequently. The trouble is that they are so rich that they can be
overwhelming. Here are a few tips to remember:
 Don't try to use all the various notations. Start with the
simple: classes, associations, attributes, and
generalization. Introduce other notations only when you
need them.
 Don't draw models for everything, concentrate on the
key areas. It is better to have a few diagrams that you
use and keep up-to-date than many forgotten, out-ofdate models.
Rules continued
• Modeling is iterative.
• Sort out which perspective you are drawing
the models from.
– If you are in analysis draw conceptual models.
– When working with software concentrate on
specification models.
– Draw implementation models only when you
are illustrating a particular implementation
technique.
Identifying Classes
• Identifying objects/classes is the most difficult part of
OOAD.
• There is no magic formula.
• It relies on skill, experiences and knowledge of the system
domain.
• It is an iterative process.
• Objects/classes can be identified throughout the OOAD
process.
Suggested Approaches to Object
Identification
• Use a grammatical approach based on a natural
language description of the system.
• Base the identification on tangible things in the
application domain.
• Use a behavioral approach and identify objects
based on what participates in what behavior
• Use a scenario-based analysis (use case
descriptions).
Object Identification
• Textual analysis of use-case information
– Nouns suggest classes
– Verbs suggest operations
• Creates a rough first cut
• Common object list
• Incidents
• Roles
PowerPoint Presentation for Dennis, Wixom & Tegardem
Systems Analysis and Design
Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.
Patterns
• Useful groupings of classes that recur in various
situations
• Transactions
– Transaction class
– Transaction line item class
– Item class
– Location class
– Participant class
PowerPoint Presentation for Dennis, Wixom & Tegardem
Systems Analysis and Design
Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.
Other ideas for Classes
• Templates for creating instances or objects
– Concrete
– Abstract
• Typical examples:
–
–
–
–
–
–
–
Application domain
user interface
data structure
file structure
operating environment
Document
and multimedia classes
PowerPoint Presentation for Dennis, Wixom & Tegardem
Systems Analysis and Design
Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.
Approaches to identification
• A good place to start the identification of system
classes and objects is by analyzing use cases. You
can begin by simply finding all the nouns and then
assessing whether they really are an object or
simply an attribute.
• Another commonly used technique relies on 'roleplay' to act out use cases. A class of objects is
identified and then what the class does and whom
it does it with are identified. The results are
reported on a Class Responsibility Collaboration
(CRC) card.
Steps for Object Identification and Structural
Modeling
1. Create CRC cards by performing textual analysis on the use-cases.
2. Brainstorm additional candidate classes, attributes, operations, and
relationships by using the common object list approach.
3. Role-play each use-case using the CRC cards.
4. Create the class diagram based on the CRC cards.
5. Review the structural model for missing and/or unnecessary classes,
attributes, operations, and relationships.
6. Incorporate useful patterns.
7. Review the structural model.
PowerPoint Presentation for Dennis, Wixom & Tegardem
Systems Analysis and Design
Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.
Example CRC Card
CLASS [class name]
Responsibilities
Collaborators
List of things class must
know and do
List of other classes
which help this
class fulfill its
responsibilities
Course Registration System
CLASS [Student]
Responsibilities
Collaborators
Remember name and
major
Course Offerings
Remember the selected
Course Offerings
Course Registration System Example
CLASS [Registration Form]
Responsibilities
Collaborators
Display Student Info
Registrar
Display available courses RegistrationManager
Display chosen courses
A CRC Card
Front:
Class name:
ID:
Type:
Description:
Responsibilities:
Collaborators:
Back:
Attributes:
Relationships:
Generalization (a-kind-of):
Aggregation (has-parts):
Other Associations:
PowerPoint Presentation for Dennis, Wixom & Tegardem
Systems Analysis and Design
Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.
CRC Resources
• For a description of how to play the CRC game
visit
http://members.aol.com/humansandt/techniques
/crc.htm
• CRC Tutorial:
http://www.csc.calpoly.edu/~dbutler/tutorials/win
ter96/crc_b/
http://ftp.ics.uci.edu/pub/arch/uml/tours/bdClass
Diagram.html
Quote of the Week:
It is difficult to introduce both novice and experienced
procedural programmers to the anthropomorphic
perspective necessary for object-oriented.We introduce CRC
cards, which characterize objects by class name,
responsibilities and collaborators, as a way of giving
learners a direct experience of objects.
Kent Beck and Ward Cunningham, inventors of the CRC
card approach.