02-05-2012, 05:18 PM
Object-Oriented Design with UML and Java
Object-Oriented-Design-with-UML-and-Java.pdf (Size: 5.18 MB / Downloads: 127)
Object Technology
This book is concerned with Object-Oriented Design, the Unified Modelling Language
(UML) and the Java Programming Language. It seeks to demonstrate that a Java application,
no matter how small, can benefit from some design during its construction.
Various aspects of that design are captured and documented with the UML.
In this book we are primarily concerned with the middle ground between objectoriented
design and implementation. Many textbooks exist that are solely concerned
with the Java programming language (see the bibliography). These books give little or no
explicit consideration to the question of design. A much smaller number of analysis and
design books have been published. They often say little on the matter of realizing their
designs. Here, we seek to offer a bridge between the two.
The benefit from this approach is that there is a significant shift of emphasis away
from detailed programming issues on to the higher ground of analysing the meaning
and accuracy of the design. Further, as mappings from the design to the implementation
language are established, we recognize emerging and repeated patterns and consequently
much of the programming activity often collapses into a coding chore.
This introductory chapter offers a roadmap into the remainder of the book. Here, we
present the essence of object-oriented computing, and provide the necessary introductory
background. We examine the fundamentals of object-oriented computing including
modelling, analysis, design and implementation. The concepts are framed around
everyday illustrations in which we concentrate on introducing the vocabulary of objectoriented
systems.
Modelling
In the same manner that an architect’s blueprint presents design details for a building,
the UML allows software models to be constructed, viewed and manipulated during
analysis and design. Modelling is a proven technique used in a variety of disciplines.
For example, engineering models are used in the design and development of motor cars
(automobile engineering), aeroplanes (aero-engineering) and bridges (civil engineering).
Similarly, meteorologists have developed mathematical models to predict weather
patterns.
Models are central to many human activities. They provide a blueprint for some artefact
we wish to manufacture or understand. A blueprint offers a measure of repeatability
ensuring standardization of the product. This is as equally important to the software
customer as it is to a customer purchasing, say, household goods such as a television or
a washing machine.
Through a model we aim to provide a better understanding of the system under development.
Models aid our understanding of especially complex systems and help ensure
we have correctly interpreted the system under development. For example, automobile
engineers use models to design new motor cars that meet a number of criteria including
their aerodynamics. The cars can be prototyped in fibreglass and tested in wind tunnels.
A similar argument can be applied to software development whereby a model can be
used to ensure all its requirements are met.
UML
The UML defines a diagrammatic notation for describing the artefacts of an OOAD.
Through the UML we can visualize, specify, construct and document our software application.
As our software systems become ever larger and ever more complex we need
to manage that complexity and, in a sense, simplify it so we have a better understanding
of it. Often, visualizing the software graphically is more appropriate than struggling to
understand it in program code.
By inspecting our models we can identify deficiencies in our designs as well as
opportunities to enhance them. The UML acts as a specification language in which we
can precisely and unambiguously capture our design decisions.
Finally, from our UML diagrams we can derive programming language code. This is
referred to as forward engineering — the generation of code from UML models. This
is an approach we advocate through this textbook. The models are at the core of our
designs. The code is an outcome of that modelling activity and is itself a design document.
The models dictate the code that we ultimately produce.
Analysis and design models
An analysis model used in software development aims to document various facets of
the real world problem that we are modelling. In an object-oriented system development
this would typically involve identifying the significant application objects and the
application processing to be performed.
Development process
The UML is a modelling language. It has no notion of a development process, which
must accompany a method. The dictionary defines a method as a systematic or orderly
procedure. The authors of the UML understood this distinction and deliberately sought
to separate the language used to document a software design from the process used to
develop it. They recognized that processes are influenced by many considerations such
as the nature of projects and the culture of organizations.
Object-oriented design is usually conducted within an iterative process. This is vital
to ensure that we can revisit earlier decisions when corrections or modifications are
necessary. This is not unreasonable. After all, initial design decisions may require revision,
especially in new projects or in those that are less well understood by the development
team. The iterative process continues until the full system is developed.
In common with many object-oriented developers, an iterative process is also accompanied
by an incremental style of development. Each increment introduces some
additional functionality on to the previous stage. Often, the new increment only adds a
small feature so that we can fully test it and its effect on the existing system and its
architecture.
Classes: sets of similar objects
An object-oriented system is characterized as a set of interacting objects. It is therefore
common to have more than one object of any given kind. For example, a bank will certainly
have a number of customer accounts each of which carries out the same actions
and maintains the same kind of information. The single class Account (such as figure
1.5) could represent the entire collection of account objects (such as in figure 1.4). The
class contains the specification and definition of its operations (methods) and its attributes.
The actual accounts are represented by instances of this class, each with its own
unique identifier (say, acc1, acc2, …). Each instance contains data that represents its
own particular state. When an account receives a message to carry out one of its
operations, it uses the method definition for the operation given in its class and applies
it to its own attribute values.