Terms and Concepts A class is a description of a set of objects
that share the same attributes, operations, relationships, and
semantics. Graphically, a class is rendered as a rectangle.
Slide 3
Names A class name must be unique Every class must have a name
that distinguishes it from other classes. A name is a textual
string. simple name; a path name is the class name prefixed by the
name of the package in which that class lives.
Slide 4
Simple and Path Names
Slide 5
Note A class name may be text consisting of any number of
letters, numbers, and certain punctuation marks and may continue
over several lines. In practice, class names are short nouns or
noun phrases drawn from the vocabulary of the system we are
modeling. Typically, we capitalize the first letter of every word
in a class name, as in Customer or TemperatureSensor.
Slide 6
Attributes An attribute is a named property of a class that
describes a range of values that instances of the property may
hold. A class may have any number of attributes or no attributes at
all. An attribute represents some property of the thing we are
modeling that is shared by all objects of that class. For example,
every wall has a height, width, and thickness;
Slide 7
We might model customers in such a way that each has a name,
address, phone number, and date of birth. An attribute is therefore
an abstraction of the kind of data or state an object of the class
might encompass. At a given moment, an object of a class will have
specific values for every one of its class's attributes
Slide 8
Slide 9
Operations An operation is the implementation of a service that
can be requested from any object of the class to affect behavior. A
class may have any number of operations or no operations at all.
For example, in a windowing library such as the one found in Java's
awt package, all objects of the class Rectangle can be moved,
resized, or queried for their properties.
Slide 10
Slide 11
Organizing Attributes and Operations To better organize long
lists of attributes and operations, we can also prefix each group
with a descriptive category by using stereotypes
Slide 12
Responsibilities A responsibility is a contract or an
obligation of a class. When we create a class, we are making a
statement that all objects of that class have the same kind of
state and the same kind of behavior. At a more abstract level,
these corresponding attributes and operations are just the features
by which the class's responsibilities are carried out.
Slide 13
A Wall class is responsible for knowing about height, width,
and thickness; FraudAgent class, as we might find in a credit card
application, is responsible for processing orders and determining
if they are legitimate,suspect, or fraudulent; TemperatureSensor
class is responsible for measuring temperature and raising an alarm
if the temperature reaches a certain point
Slide 14
Techniques like CRC cards and use case-based analysis are
especially helpful here. A class may have any number of
responsibilities, although, in practice, every well-structured
class has at least one responsibility and at most just a handful.
As we refine models,we will translate these responsibilities into a
set of attributes and operations that best fulfill the class's
responsibilities.
Slide 15
Slide 16
Other Features Attributes, operations, and responsibilities are
the most common features Sometimes, we need to visualize or specify
other features, such as the visibility of individual attributes and
operations; Language-specific features of an operation, such as
whether it is polymorphic or constant;
Slide 17
Even the exceptions that objects of the class might produce or
handle. These and many other features can be expressed in the UML
Sometimes, we will want to separate the implementation of a class
from its specification, and this can be expressed in the UML by
using interfaces Finally, classes rarely stand alone. When we build
models, we will typically focus on groups of classes that interact
with one another. In the UML, these societies of classes form
collaborations and are usually visualized in class diagrams
Slide 18
Common Modeling Techniques Modeling the Vocabulary of a System
Modeling the Distribution of Responsibilities in a System Modeling
Nonsoftware Things Modeling Primitive Types
Slide 19
Modeling the Vocabulary of a System
Slide 20
To model the vocabulary of a system, Identify those things that
users or implementers use to describe the problem or solution. Use
CRC cards and use case-based analysis to help find these
abstractions. For each abstraction, identify a set of
responsibilities. Make sure that each class is crisply defined and
that there is a good balance of responsibilities among all your
classes. Provide the attributes and operations that are needed to
carry out these responsibilities for each class.
Slide 21
Modeling the Distribution of Responsibilities in a System
Slide 22
To model the distribution of responsibilities in a system,
Identify a set of classes that work together closely to carry out
some behavior. Identify a set of responsibilities for each of these
classes. Look at this set of classes as a whole, split classes that
have too many responsibilities into smaller abstractions, collapse
tiny classes that have trivial responsibilities into larger ones,
and reallocate responsibilities so that each abstraction reasonably
stands on its own.
Slide 23
Consider the ways in which those classes collaborate with one
another, and redistribute their responsibilities accordingly so
that no class within a collaboration does too much or too
little.
Slide 24
Modeling Nonsoftware Things
Slide 25
To model nonsoftware things Model the thing you are abstracting
as a class. If we want to distinguish these things from the UML's
defined building blocks, create a new building block by using
stereotypes to specify these new semantics and to give a
distinctive visual cue. If the thing we are modeling is some kind
of hardware that itself contains software, consider modeling it as
a kind of node, as well, so that you can further expand on its
structure.
Slide 26
Modeling Primitive Types
Slide 27
To model primitive types, Model the thing you are abstracting
as a type or an enumeration, which is rendered using class notation
with the appropriate stereotype. If you need to specify the range
of values associated with this type, use constraints.