Ch- 8.
Class Diagrams
• Class diagrams are the most common diagram found in
modeling object- oriented systems.
• Class diagrams are important not only for visualizing,
specifying, and documenting structural models, but also
for constructing executable systems through forward and
reverse engineering.
Class Diagram
• A class diagram is a diagram that shows a set of
classes, interfaces, and collaborations and their
relationships.
• Graphically, a class diagram is a collection of vertices
and arcs.
• Class diagrams commonly contain the following things:
Classes
Interfaces
Collaborations
Dependency, generalization, and association
relationships.
• Like all other diagrams, class diagrams may contain
notes and constraints.
• Class diagrams may also contain packages or
subsystems, both of which are used to group elements
of your model into larger chunks.
• Class diagrams are used to model the static design view
of a system. This view primarily supports the functional
requirements of a system- the services the system
should provide to its end users.
• When you model the static design view of a system, you'll
typically use class diagrams in one of three ways.
1. To model the vocabulary of a system
Modeling the vocabulary of a system involves making
a decision about which abstractions are a part of the
system under consideration and which fall outside its
boundaries. You use class diagrams to specify these
abstractions and their responsibilities.
2. To model simple collaborations
A collaboration is a society of classes, interfaces,
and other elements that work together to provide some
cooperative behavior that's bigger than the sum of all the
elements.
For example, when you're modeling the semantics of a
transaction in a distributed system, you can't just stare at
a single class to understand what's going on. Rather,
these semantics are carried out by a set of classes that
work together.
• Identify the mechanism you'd like to model. A mechanism represents some function
or behaviour of the part of the system you are modelling that results from the
interaction of a society of classes, interfaces, and other things.
• For each mechanism, identify the classes, interfaces, and other collaborations that
participate in this collaboration. Identify the relationships among these things as
well.
• Use scenarios to walk through these things. Along the way, you'll discover parts of
your model that were missing and parts that were just plain semantically wrong.
• Be sure to populate these elements with their contents. For classes, start with getting
a good balance of responsibilities. Then, over time, turn these into concrete
attributes and operations.
3. To model a logical database schema
Think of a schema as the blueprint for the conceptual
design of a database. In many domains, you'll want to
store persistent information in a relational database or in
an object-oriented database.
• The UML is well suited to modelling logical
database schemas, as well as physical databases
themselves.
• UML's class diagrams are a superset of entity-relationship
(E-R) diagrams, a common modelling tool for logical
database design.
• Whereas classical E-R diagrams focus only on data, class
diagrams go a step further by permitting the modelling of
behaviour as well.
• In the physical database, these logical operations are
generally turned into triggers or stored procedures.
To model a schema
• Identify those classes in your model whose state must transcend
the lifetime of their applications.
• Create a class diagram that contains these classes. You can define
your own set of stereotypes and tagged values to address
database-specific details.
• Expand the structural details of these classes. In general, this
means specifying the details of their attributes and focusing on
the associations and their multiplicities that relate these classes.
• Watch for common patterns that complicate physical database
design, such as cyclic associations and one-to-one associations.
Where necessary, create intermediate abstractions to simplify
your logical structure.
• Consider also the behaviour of these classes by expanding
operations that are important for data access and data integrity.
• Where possible, use tools to help you transform your logical
design into a physical design.
• The Figure shows a set of classes drawn from an information system for a
school. This figure expands upon an earlier class diagram, and you'll see
the details of these classes revealed to a level sufficient to construct a
physical database. Starting at the bottom-left of this diagram, you will find
the classes named Student, Course, and Instructor. There's an association
between Student and Course, specifying that students attend courses.
Furthermore, every student may attend any number of courses, and every
course may have any number of students.
Forward engineering
• Forward engineering is the process of transforming a model into
code through a mapping to an implementation language
Forward engineering
the classes in this diagram to Java is straightforward, using
atool.
Forward engineering the class
EventHandler yields the following code.
public abstract class EventHandler {
EventHandler successor;
private Integer currentEventID;
private String source;
EventHandler() {}
public void handleRequest() {}
}
Reverse engineering
• Reverse engineering is the process of transforming code into a
model through a mapping from a specific implementation
language
