Java Reference
In-Depth Information
reasons, we aim to arm the reader with a basic UML proficiency in the balance
of this chapter. UML also provides the best method we know of to describe the
object design used in the rest of this chapter. So we must introduce a basic level
of familiarity with UML just to convey the distributed computing ideas discussed
here.
Perhaps the most important concept in object-oriented analysis and design is
the skillful assignment of responsibilities to software components, and UML is
arguably the best tool to describe and visualize that assignment. We introduce
only the essential UML features needed to describe a relatively simple distributed
application. The description below is not even intended to be rigorously accurate
with UML terms. Instead, we freely switch between the common Java names
and the generic UML names and notations for certain items. Furthermore, we
do not intend to produce a formal or even informal tutorial on UML. Instead, we
introduce some simple UML diagrams for our distributed application and explain
what they mean. A hands-on minimalist UML training session, if you will, or
on-the-job training.
16.3.1 UML interaction diagrams
One of the most commonly seen features of UML is the class diagram, though
it is not necessarily the most useful and probably should not be the first diagram
that one thinks of when analyzing a problem and designing a solution. A class
diagram depicts the software classes and the relationships among them (e.g.
the Java extends and implements relationships) in an object-oriented
system. A class diagram also shows the operations and attributes of a class, or,
in Java terminology, the methods and variables , respectively. We explain class
diagrams further in Section 16.6.3, below.
Before designing classes, though, one should create a conceptual model of
the problem at hand. A conceptual model represents real-world concepts, not
software components. For complex systems, a disciplined OOAD approach has
proven to be a very useful technique to create good models and good solutions
to real-world problems. Formal OOAD is beyond the scope of this topic and is
typically not needed for most scientific problems. For simple systems, OOAD
begins with a conceptual model that can be sketched out on paper without a lot
of rigor. A block diagram of the parts of the real-world system along with some
lines connecting them with perhaps some notations about how the various parts
interact is a good starting point. Creating such a block diagram forces you to
identify explicitly the various parts of a system and the roles that they play. Once
a conceptual model is in hand, you can begin designing a software solution.
UML interaction diagrams are useful for depicting the software implementa-
tion of a real-world conceptual model. As is obvious from the name, these dia-
grams depict the interactions among objects. There are two types of interaction
Search WWH ::




Custom Search