Java Reference
In-Depth Information
since the introduction of subroutine libraries, so that the design and archi-
tecture of a software program represented a large part of the development
effort, and systematic reuse of design and architecture was not supported in
any way.
Such reuse is more difficult than code-level reuse, since a design is not
worth much in itself as a reusable artifact; the design, with its tradeoffs and
consequences, must be understood by the application developer so that the
necessary adaptations and changes can be performed. The challenge, there-
fore, was to find a good way of representing not only the design, but also the
design knowledge and expertise that led to that design. This has become pos-
sible with the introduction of design patterns and application frameworks in
software engineering.
An application framework may be roughly defined as a set of interacting
objects that, together, realize a set of functions. The set of functions defines
the area of “expertise” or “competencies” of the framework; we refer to it as
the domain of the framework. A
domain
may be either a subset of the
busi-
ness domain
(the problem space), or a subset of the
computing domain
(the
solution space). A banking application framework, for example, implements
functions with the business domain of banking. The Model-View-Controller
(MVC) framework, developed for the Smalltalk language, covers a subset of
the
computing domain
, and more specifically, the design domain. It does so
by addressing the problem of connecting business logic with graphical user
interface (GUI) logic in a way that minimizes the dependencies between the
two. Other computing domain frameworks address architectural issues, and
include artifacts such as middleware frameworks (e.g. CORBA, EJB and
COM).
Developing frameworks for a specific application domain requires a
careful requirements analysis, in order to recognize the stable entities and
relationships that can be captured by reusable assets. Two complementary
approaches are commonly followed by analysts: domain analysis and legacy
analysis. Domain analysis consists in identifying the enduring-business
themes (EBT) and processes that characterize a given business domain.
Typically, an EBT is concerned with a business issue; namely, “what is being
done”, not “how it is being done” (Fayad, Hamu and Brugali 2000). For
example, in the transportation industry, the EBT is concerned with moving
material from one location to another. Legacy analysis consists in identify-
ing common functional, architectural and implementation aspects in a
family of already existing software products that have been developed in the
past for the same application domain, but independently from each other.
This is obtained by insulating the homogeneous parts of the those software
products with regard to the driving factors of changes. The homogeneous
software modules become the core components of the framework. Those
changes that are required by every specific application built on the frame-
work will then be in the periphery, since the core was based on something
that has remained, and will remain, stable. Therefore, only these small
external modules need to be engineered.
