لطفا منتظر باشید ...
3.1 Classes and Objects
Class diagrams show classes that represent concepts, while object
diagrams show objects that represent specific instances of those
concepts. The next few sections talk in detail about the
representation of classes and objects in class and object diagrams.
3.1.1 Classes
As discussed in Chapter 2, a
class is a
general concept. For
example, the project management system involves various general
concepts, including projects, managers, teams, work products,
requirements, and systems.
A class defines a type of object and its
characteristics,
including structural features and behavioral features.
Structural features define what objects of the
class know, and behavioral features define what
objects of the
class can do. For example, in Chapter 2 you saw
that individuals of the Manager class have names
(something they know), and can initiate and terminate projects
(things they do). Structural features include attributes and
associations. Behavioral features include operations and methods.
The most crucial aspect of a class is that it has semantics: some
agreed upon meaning between whomever is communicating about it. For
example, when I discuss a project, what does a project mean to my
audience? Is it an effort that lasts one week or one year? Is it an
effort that requires a manager and other human resources? And so
forth. Such meaning is very specific to the audience and domain in
which the class is used.
In a UML class diagram, a class is shown as a solid-outline rectangle
with three standard compartments separated by horizontal lines. The
required top compartment shows the class name, the optional second
compartment shows a list of attributes, and the optional third
compartment shows a list of operations. The second and third
compartments need only show the specific information you want to
communicate using a given diagram. You don''t need to
show all of a class''s attributes and operations all
the time.
Figure 3-1 shows various fundamental classes
associated with the project management system in our case study,
including Worker, UnitOfWork,
and WorkProduct, using the most basic notation for
classes.
Figure 3-1. Classes
A worker is a person or group of people who perform work, including
project managers, resource managers, human resources, and system
administrators. A unit of work is a unit of effort, which includes
capturing and analyzing requirements, as well as designing,
implementing, testing, or deploying a system. A work product is
anything produced and used within a project, including the
requirements and the system. Notice that a class should be named
using a noun phrase. Classes, as you should recall from Chapter 2, represent concepts that you discover by
focusing on nouns.
3.1.1.1 Attributes
An attribute is what an
object
of a class knows. It''s an element of data maintained
by the object. For example, each object of the
Worker class of the project management system may
have a name, description, and so forth. These are all attributes.
In a class diagram, you list attributes in the second compartment for
a class. The simplest approach is to just list attribute names, but
the UML allows you to do much more than that. Consider an attribute
for holding a worker''s email address. You may start
by defining it using the following basic syntax:
EmailAddress
As you go through the development process, you can add detail to this
definition in each iteration by asking various questions and
capturing more detail about the attribute based upon the answers.
For example, you may ask how many email addresses a worker has.
Presuming that a worker may have up to five email addresses, you can
update the attribute definition to the following:
EmailAddress [1..5]
Next, you may ask if these email addresses are ordered, perhaps by
priority. Presuming that email addresses are not ordered, you can
update the attribute definition as follows:
EmailAddress [1..5 unordered]
You may decide to ask the type of data an email address attribute
needs to hold. You discover that an email address is a string of
characters, and you update the attribute definition to indicate that:
EmailAddress [1..5 unordered] : String
You might then ask if there should be a default value for a
worker''s email address. Your client suggests using a
default value of "No email address", so you update
the attribute definition to the following:
EmailAddress [1..5 unordered] : String = "No email address"
Finally, you may ask whether other objects are allowed to access a
Worker object''s email address.
Presuming the answer is that a Worker
object''s email address is not accessible by other
objects, you can update the attribute definition one last time by
preceding it with minus sign (-), as follows:
- EmailAddress [1..5 unordered] : String = "No email address"
To summarize, this final attribute definition communicates the
following information:
The - symbol
Indicates that the email address attribute is private to an object
and thus inaccessible by other objects.
1..5
Indicates that the email address attribute may have from one to five
values.
unordered
Indicates that the email address attribute values are not ordered
based on any specific criteria.
String
Indicates that email addresses are strings of characters.
"No email address"
Is the initial value of each email address.
Figure 3-2 shows the Worker
class from Figure 3-1 with its attributes. A worker
has an identification number (ID), a next
identification number (NextID), a name, up to five
email addresses that are unordered, any number of phone numbers that
are ordered, and a password. NextID is underlined
to indicate that it is one value, defined at the class level, shared
by all objects of the class. The system uses this shared value to
ensure that every Worker object has a unique ID
number.
Figure 3-2. Worker class with its attributes
In Figure 3-2, you''ll see some
syntax I haven''t described yet: a number sign
(#) at the front of the
Password attribute and the keyword
ordered in the PhoneNumber
attribute. This syntax is described in the next section, Section 3.1.1.2.
Figure 3-3 shows the UnitOfWork
class of Figure 3-1 with its attributes. A unit of
work has a name and description.
Figure 3-3. UnitOfWork class with its attributes
Figure 3-4 shows the WorkProduct
class of Figure 3-1 with its attributes. A work
product has a name, description, and a percentage of completion.
Figure 3-4. WorkProduct class with its attributes
3.1.1.2 Attribute syntax
In the UML, an attribute
is
described in a class''s second compartment expressed
using the following UML syntax:
visibility name [multiplicity ordering] : type = initial_value
in which:
visibility
Is optional, has no default value, and indicates whether the
attribute is accessible from outside the class. It may be one of the
following:
+
Public visibility; the attribute is accessible from outside its class.
-
Private visibility; the attribute is inaccessible from outside its
class.
#
Protected visibility; the attribute is accessible by classes that
have a generalization relationship (as discussed in Chapter 2) to its class, but is otherwise inaccessible
from outside its class.
Figure 3-2 through Figure 3-4 show that most attributes are private, except
a worker''s password is protected so that more
specific types of workers may use it in whatever manner in which they
handle security.
name
Is the name of the attribute you are describing.
multiplicity
Is optional, has a default value of 1, and indicates the number of
values an attribute may hold. If an attribute has only one value, the
multiplicity, ordering, and square brackets are not shown. Otherwise,
the multiplicity is shown as a lower-bound ..
upper-bound string in which a single asterisk indicates an
unlimited range; for example, 0..* allows from
zero up to an infinite number of values. Figure 3-2 through Figure 3-4 show that
all attributes except for EmailAddress and
PhoneNumber have one value only. A worker may have
up to five email addresses and any number of phone numbers.
ordering
Is optional, has a default value of unordered, and
is used where the multiplicity is greater than one to indicate
whether the values of an attribute are ordered or unordered. Use one
of the following keywords:
unordered
Indicates that the values are unordered.
ordered
Indicates that the values are ordered.
Figure 3-2 shows that a worker''s
five email addresses are unordered and that a
worker''s phone numbers are ordered.
type
Is optional, has no default value, and indicates the type of data an
attribute may hold. If you don''t show a type for an
attribute, you should omit the colon. The type of an attribute may be
another class. In addition, the UML provides the following data
types:
Boolean
A true or false value
Integer
An integer number
Real
A real number
String
A sequence of characters
Figure 3-2 through Figure 3-4 show that most of the attributes are strings
while a worker''s identification number
(ID) and next identification number
(NextID) are integers, and a work
product''s PercentComplete
attribute is a real number.
initial_value
Is optional, and indicates the initial value of an attribute. By
default, an attribute has no initial value. If you do not show an
initial value, you should omit the equal symbol
(=). Figure 3-2 through
Figure 3-4 show that most of the attributes have no
initial value. However, a worker''s next
identification number (NextID) has an initial
value of 1, a work product''s percent complete has an
initial value of 0, and email addresses have an initial value of
"No email address".
If you prefer, the UML also allows you to show an attribute using
pseudocode or another language. For example, you can use the syntax
of Java, C++, C#, or some other programming language.
If an attribute''s value is specific
to an object, it is known as
instance scoped or object
scoped. If an attribute is shared by all objects of a
class, it is known as class scoped. To indicate
that an attribute is class scoped, underline it. Figure 3-2 through Figure 3-4 show that
all the attributes are object scoped, except for the
worker''s next identification number
(NextID), which is class scoped.
3.1.1.3 Operations
Recall from Chapter 2 that an operation
is
what an object of a class can do. It is a specification of a service
provided by the object. Recall also that a method is how an object of
a class does its processing. It is an implementation of a service
provided by the object. For example, each class of the project
management system may provide getter and setter operations for its
attributes. These getter and setter operations retrieve and set the
values for the attributes of a worker, unit of work, work product,
and so forth.
Consider an operation for adding an email address to a worker. You
may start by defining it using the following basic syntax:
addEmailAddress
As you go through iterations of the development process, you can add
detail to this definition by asking questions and capturing
additional detail about the operation from the answers to those
questions.
For example, you may ask if the addEmailaddress
operation requires any parameters: data that is input to or output
from the operation. Presuming that the operation requires an email
address as input, you can update the operation definition to the
following:
addEmailAddress (theEmailAddress)
Next, you may ask what type of data may the email address hold?
Presuming that the email address is a string of characters, you can
update the operation definition to the following:
addEmailAddress (theEmailAddress : String)
Next, you may ask if there is a default value for the email address.
Presuming that the email address has a default value of an empty
string, or no characters, you can update the operation definition to
the following:
addEmailAddress (theEmailAddress : String = ")
You might then ask whether the email address is simply an input to
the operation, an output from the operation, or both. Presuming that
the email address is only input to the operation, and thus not
modified by the operation, you can add the in
keyword preceding the parameter name:
addEmailAddress (in theEmailAddress : String = ")
You may then ask whether the operation returns any type of data.
Presuming that the operation returns a Boolean true or false
indicating whether the operation was successful in adding the email
address to the worker, you can update the operation definition to the
following:
addEmailAddress (in theEmailAddress : String = ") : Boolean
Finally, you may ask whether other objects are allowed to access an
object''s addEmailAddress
operation. Presuming that an object''s
addEmailAddress operation is accessible by other
objects, you can precede the operation name in the definition with a
plus sign (+):
+ addEmailAddress (in theEmailAddress : String = ") : Boolean
To summarize, this operation definition communicates the following:
The + symbol
Indicates that the addEmailAddress operation is
public and is accessible by other objects. The expression inside the
parentheses indicates the parameters that hold the values passed to
the operation.
The in keyword
Indicates that the parameter is input and may not be modified by the
operation.
theEmailAddress : String = "
Indicates that an email address, which is a string with a default
value of an empty string, is passed to the operation.
The Boolean keyword
Indicates that the addEmailAddress operation
returns a value of true or
false, perhaps indicating whether there is room
for the email address to be added to the email address attribute
(which holds a maximum of five email addresses).
Figure 3-5 shows the Worker
class from Figure 3-1 and Figure 3-2 with its various attribute getter and setter
operations. Notice that the getter and setter operations for phone
numbers are based on the priority of the phone number such that you
specify the priority and set or get the corresponding phone number.
Also, notice that the getter operation for email addresses retrieves
all of a worker''s email addresses, while the setter
operation for email addresses simply adds one email address. The
create and destroy operations
create and destroy worker objects, respectively.
Figure 3-5. Worker class with its operations
Figure 3-6 shows the UnitOfWork
class from Figure 3-1 and Figure 3-3 with its various getter and setter operations
to set and retrieve attribute values, and with operations to create
and destroy UnitOfWork objects.
Figure 3-6. UnitOfWork class with its operations
Figure 3-7 shows the WorkProduct
class from Figure 3-1 and Figure 3-4 with its various getter and setter operations
for its attributes and operations to create and destroy work objects.
Notice that Figure 3-7 also shows the attributes of
the class.
Figure 3-7. WorkProduct class with its operations
3.1.1.4 Operation syntax
In the UML, an operation is
described in a
class''s third compartment using the following UML
syntax:
visibility operation_name (parameter_list) : return_type
in which:
visibility
Is optional, has no default value, and indicates whether the
operation is accessible from outside of the class.
It may be one of the following:
+
Public visibility; the operation is accessible from outside its class.
-
Private visibility; the operation is inaccessible from outside its
class.
#
Protected visibility; the operation is accessible by classes that
have a generalization relationship (as discussed in Chapter 2) to its class, but is otherwise inaccessible
from outside its class.
Figure 3-5, Figure 3-6,
and Figure 3-7 show that all the operations are
public, except that the operation to set a worker''s
password is protected so that more specific types of workers or
subclasses of the Worker class may use it in
whatever manner in which they handle security.
operation_name
Is the name of the operation you are describing.
parameter_list
Is optional, has no default value, and is a comma-separated list
indicating the parameters that hold the values passed to or received
from the operation. Each parameter is shown as a text string having
the following syntax:
kind name : type = default_value
kind
Is optional, has a default value of in, and may be
one of the following:
in
Indicates the parameter is input-only, and may not be modified by the
operation.
out
Indicates the parameter is output-only, and may be modified by the
operation to communicate information to the client that invoked the
operation.
inout
Indicates that the parameter is input and may in turn be modified by
the operation to communicate information to the client that invoked
the operation.
The type and default value are the same as for an
attribute''s type and initial value, described in the
previous section.
type
Is optional, has no default value, and indicates the type of data a
parameter may hold. If you don''t show a type for a
parameter, you should omit the colon. The type of a parameter may be
another class. In addition, the UML provides the following data
types:
Boolean
A true or false value.
Integer
An integer number.
Real
A real number.
String
A sequence of characters.
default_value
Is optional, and indicates the initial value of a parameter. By
default, a parameter has no initial value. If you do not show an
initial value, you should omit the equal symbol
(=).
Figure 3-5 shows an initial value for the parameter
to the addEmailAddress method.
return_type
Is optional, has no default value, and indicates the type of data the
operation returns to its caller. If you choose not to show the return
type of an operation, you should also omit the colon. Your choices
for return type are the same as for a parameter type. Many of the
operations shown in Figure 3-5 through
Figure 3-7 show a return type.
If you prefer, the UML also allows you to show an operation using
pseudocode or another language. For example, you can use the syntax
of Java, C++, C#, or some other programming language.
If an operation applies to a specific object,
it is known as instance
scoped or object scoped. If an
operation applies to the class itself, it is known as class
scoped. Figure 3-5 through Figure 3-7 show that most of the operations are object
scoped. The exceptions are the create operations,
which are class scoped. The create operations are
used to create objects of a class and are
known as
constructors. The destroy
operations are used to destroy objects of a class and
are known as
destructors. The create
operations are class scoped, because a class is used to create
objects of the class; if create were instance
scoped, you''d need to somehow create an object
before invoking its create operation to create it,
which makes no sense. The destroy operation, on
the other hand, is object scoped, because it is applied to a specific
object that is to be destroyed.
We can combine Figure 3-2 and Figure 3-5 or Figure 3-3 and
Figure 3-6 much the way that Figure 3-7 combines the attributes shown in Figure 3-4 with the class''s operations.
In this way, we can show any combination of attributes and operations
based upon what we want to communicate.
|
3.1.2 Objects
As discussed in Chapter 2, an
object is a
specific concept, or
instance of a class, having the characteristics defined by its class,
including structural features and behavioral features. For example,
the project management system involves various specific concepts,
including specific projects, managers, teams, work products,
requirements, systems, and so forth. Recall that structural features
define what the object knows, and that behavioral features define
what the object can do. Structural features included attribute values
and links. Behavioral features include operations and methods, which
are shared by all the objects of a class. The most crucial aspect of
an object is that it has its own identity. No two objects are the
same, even if they have the same values for their structural
features. For example, even if two worker objects have the same
values for their attributes, the objects are unique and have their
own identities.
In a UML object diagram, an object is shown as a solid-outline
rectangle with two standard compartments separated by horizontal
lines. The required top compartment shows the object name followed by
a colon followed by the object''s class name, and the
entire string is fully underlined. Both names are optional, and the
colon should only be present if the class name is specified. The
optional second compartment shows a list of attributes. The second
compartment need only show the specific information you want to
communicate using a given diagram; you need not show all of an
object''s attribute values all the time.
Figure 3-8 shows various objects associated with
the classes shown in the previous figures. These objects include the
following:
Nora and Phillip who are workers
Testing that is a unit of work
Test that is a work product
An anonymous unit of work with the name attribute,
Implementation
An anonymous work product with the name attribute,
System
XYZ that is an unspecified object.
Figure 3-8 introduces notation you
haven''t seen before: some objects have no names and
others have no class specified. Objects in a UML diagram that do not
have names are referred to as anonymous objects.
Objects for
which
a class has not been specified are referred to as
unspecified objects. You may
encounter
such notation depending on the specific methodology being used for a
project.
Note that the object names in Figure 3-8 are all
fully underlined. You''ll also see specific attribute
values. I''ll discuss attribute values further in the
next section.
Figure 3-8. Objects
3.1.2.1 Attribute values
An attribute value is the value an
object of a class knows for an
attribute. In the UML, an attribute value is described in an
object''s second compartment. For example, each
Worker object of the project management system may
have a value for its name.
Consider an attribute value for holding a worker''s
email addresses. You may define it using the following syntax:
- EmailAddress [1] : String = "ph@myorg.org"
This definition communicates the following:
The - symbol
Indicates that the email address attribute is private and accessible
only by the object.
[1]
Indicates that this is the first email address value, because there
are multiple email address values.
String
Indicates that the email address is a string of characters.
"ph@myorg.org"
Indicates the value of the email address attribute.
Following is the general syntax to use for defining attribute values:
visibility name [index] : type = value
The syntax elements are the same as for the attributes of a class.
3.1.2.2 Operations
Because the operations and methods
of a class are
shared by all the objects of the class, operations are not shown on
each object. For example, Figure 3-8 shows that
both Nora and Phillip are workers, and therefore they share the
operations and methods of the Worker class. There
is no need to show the operations on each object, as the operations
will be unnecessarily repeated each time. To determine the operations
of an object, refer to that object''s class.
