|
|
Design Software
Design is
the process of producing a specification for constructing
something. A “logical design” focuses on a system's
behavior, which may include details of external interfaces,
but overlooks many of the internal workings of the system.
A logical design is different from a requirements specification
in that a design begins to address how requirements
are accomplished. It need not (should not) reiterate those
requirements.
A design needs to precisely specify what the system
does, however the inputs and outputs, and the transformations
or algorithms that are relevant to the application.
These may appear in the system's requirement. The
design makes decisions about how the requirements
are to be implemented. If the requirements contain
algorithm specifications or procedures, the design
addresses the form these will take in the system.
The design will specify components which provide
these algorithms or procedures.
A logical design is merely an abstraction of the
system, with many details left out. In a logical design
many decisions about implementation are postponed, in
order to create a first-cut design that can be understood
and verified by domain experts, and serve as the basis
for a prototype. There is really no other qualitative
or substantive difference between logical and detailed
system designs, except the level of abstraction and postponement
of decisions which hinge on detailed design analysis and
technology choices. A logical design may therefore be
viewed as a model, since it describes a hypothetical and
simplified implementation.
Most projects employ a “detailed design” phase
prior to coding. In a detailed design, features and terminology
should match actual components and constructs in the real
system to be built, and for this reason a detailed design
is sometimes referred to as a “physical design.” In contrast,
only the behavior of the major components of a logical
model need match the actual system. A detailed design
begins with a specification of the actual top-level physical
architecture of the planned system. A detailed design
specification must also include decisions on issues that
are postponed in a logical model; in a detailed design,
no major issues are postponed. The level of detail to
be included in the logical and detailed design—and even
whether to separate these tasks or combine them—is a critical
decision. It has been my experience that if a proof-of-concept
and technology evaluation prototype is developed during
the logical design phase, the knowledge gained can be
used to produce a highly complete detailed design, and
drastically reduce risk for the project.
UML
—A Universal Modeling Language
We are fortunate that there has finally been a convergence
in the various object oriented system modeling notations.
Universal Modeling Language (UML), which has rapidly become
the accepted standard for specifying object-oriented systems,
defines a set of diagrammatic conventions for representing
virtually every aspect of a system. The different kinds
of diagrams specified by UML are:
Use case diagram
—Identifies actors and the functions (use cases)
they perform in a diagrammatic manner. Useful for showing
the roles users play in a system, in terms of which use
cases they interact with. Appropriate for giving an overview
of work processes.
Class diagram
—Identifies interfaces and classes, their attributes
and operations (i.e., methods), and the cardinal, compositional,
and derivational relationships between them. Most applications
will have a core object model expressed with class diagrams.
In a database application, certain classes will be labeled
persistent.
Sequence diagram, collaboration diagram
—Time-based diagramming techniques to show the messaging
behavior of a system. A sequence diagram is a two dimensional
chart showing the flow of messages between objects versus
time. A collaboration diagram does not impose a two-dimensional
organization, but identifies the sequence of message flows
by assigning them numbers that increase with time. A collaboration
diagram has somewhat the appearance of a data flow diagram,
and can be used effectively to give a high-level view
of what is happening in a system. Often object instances
will be represented instead of classes, to show a “typical”
scenario.
Package diagram
—Shows system partitioning. This is directly applicable
to a Java application, since Java has a very analogous
package construct. This is perhaps the hardest diagram
to do right, although on the surface it looks like the
simplest kind of Universal Modeling Language diagram. The challenge is that in
many systems—even some well designed ones—everything uses
everything, and one can end up with a package diagram
that has lines between every component.
Implementation diagram
—Similar to a class diagram, but for large-grain
components. This can be used to show communication between
large-grain components, such as a server object and clients.
It can also be used to show how a software system is configured
or deployed, in terms of which components reside in which
machines.
Activity diagram, statechart diagram
—State-based diagramming techniques for showing concurrent
behavior. These are very useful for specifying aspects
of a design that uses multithreading. Let’s now look at
what goes into a Java design, and which of these modeling
diagrammatic formats can help.
Extract from "Advanced Java Development for Enterprise
Application"
written by Clifford J. Berg
Published by Prentice Hall PTR New Jersey 1998 |
|
|
|
|
