1. Class Diagrams
• 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.
• You use class diagrams to model the static design
view of a system.
• Class diagrams are important not only for
visualizing, specifying, and documenting structural
models, but also for constructing executable
systems through forward and reverse
engineering.
2. Contents: Class diagrams commonly contain the
following things:
1. Classes
2. Interfaces
3. Collaborations
4. Dependency, generalization, & association
relationships.
Like all other diagrams, class diagrams may
contain notes and constraints.
• Note: Component diagrams and deployment diagrams are
similar to class diagrams, except that instead of containing
classes, they contain components and nodes, respectively.
• Class diagrams may also contain Packages or Subsystems.
3. Common Uses:
• we use class diagrams to model the static design
view of a system. This view primarily supports the
functional requirements of a system
• When you model the static design view of a
system, you'll typically use class diagrams in one
of three ways.
1. Modeling the vocabulary of a system.
2. To model simple collaborations.
3. To model a logical database schema.
4. 1.To model simple collaborations:
• No class stands alone. Rather, each works in
collaboration with others to carry out some
semantics greater than each individual.
• We also need to turn our attention to visualizing,
specifying, constructing, and documenting the
various ways these things in our vocabulary work
together. We use class diagrams to represent
such collaborations.
• When you create a class diagram, you just model a
part of the things and relationships that make up
your system's design view. For this reason, each class
diagram should focus on one collaboration at a
5. To model a collaboration:
1. Identify the mechanism you'd like to model. A
mechanism represents some function or
behavior of the part of the system you are
modeling.
2. For each mechanism, identify the classes,
interfaces, and other collaborations that
participate in this collaboration.
3. Identify the relationships among these things, as
well.
6. Modeling a Logical Database
Schema:
• Many of the systems we model will have
persistent objects, which means that they can be
stored in a database for later retrieval. The UML
is well-suited to modeling logical database
schemas, as well as physical databases
themselves.
• The UML's class diagrams are a superset of
entity-relationship (E-R) diagrams, a common
modeling tool for logical database design.
7. To model a schema:
1. Identify those classes in your model .
2. Create a class diagram that contains these
classes.
3. Expand the structural details of these classes.
4. Watch for common patterns that complicate
physical database design.
5. Consider also the behavior of these classes by
expanding operations that are important for data
access and data integrity.
6. use tools to help you transform your logical
design into a physical design.
8. Forward and Reverse Engineering:
• Modeling is important, but you have to remember
that the primary product of a development team
is software, not diagrams.
• Forward engineering is the process of
transforming a model into code, through a
mapping to an implementation language.
• Forward engineering results in a loss of
information, because models written in the UML
are semantically richer than any current object-
oriented programming language.
9. • Reverse engineering is the process of
transforming code into a model, through a
mapping from a specific implementation
language.
• Reverse engineering results in a flood of
information.
• At the same time, reverse engineering is
incomplete. There is a loss of information when
forward engineering models into code, and so
you can't completely recreate a model from code.
10. Object Diagrams:
• An object diagram is a diagram that shows a set of
objects and their relationships at a point in time.
Graphically, an object diagram is a collection of
vertices and arcs.
• Object diagrams model the instances of things
contained in class diagrams.
• We use object diagrams to model the static
design view or static process view of a system.
This involves modeling a snapshot of the system at
a moment in time and rendering a set of objects,
their state, and their relationships.
11. Object diagrams commonly contain:
1. Objects
2. Links
• Like all other diagrams, object diagrams may
contain notes and constraints.
• Object diagrams may also contain packages or
subsystems, both of which are used to group
elements of your model into larger chunks.
12. • When you model the static design view or static
process view of a system, we use object
diagrams in one way:
1. To model object structures. And also
2. Forward and Reverse Engineering .
