Page 128 - DCAP308_OBJECT_ORIENTED_ANALYSIS_AND_DESIGN

Object Oriented Analysis and Design

Notes flawed. One myth about UML and OOAD is that you need a complete design in order to write
code. But that is not right.

!

Caution You just need enough of the design to get you started.

Did u know? Designing and implementing software one usage scenario at a time, so that
users can provide feedback on the end product, is a smart way of fleshing out a better
design.

10.2.1 Issues in Complexity Modelling and Abstraction

Divide and Rule has been a fruitful technique of mastering complexity since ancient time. When
designing complex software system it is essential to decompose it into smaller and smaller parts
each of which we may then redefine independently. Object technologies leads to reuse and reuse
leads to faster software development and higher quality software products.
As Brooks suggests, “The complexity of software is an essential property, not an accidental one”.
We observe that this inherent complexity derives from four elements: the complexity of the
problem domain, the difficulty of managing the development process, the flexibility possible
through software, and the problems of characterizing the behavior of discrete systems.
The problems we try to solve in software often involve elements of inescapable complexity, in
which we find a myriad of competing, perhaps even contradictory, requirements. The external
complexity usually springs from the “communication gap” that exists between the users of a
system and its developers: Users generally find it very hard to give precise expression to their
needs in a form that developers can understand. In some cases, users may have only vague ideas
of what they want in a software system. This is not so much the fault of either the users or the
developers of a system; rather, it occurs because each group generally lacks expertise in the
domain of the other.

A further complication is that the requirements of a software system often change during its
development, largely because after seeing early products, such as design documents and
prototypes, and then using a system once it is installed and operational are forcing functions
that lead users to better understand and articulate their real needs. At the same time, this process
helps developers master the problem domain, enabling them to ask better questions that
illuminate the dark corners of a system’s desired behavior.
The fundamental task of the software development team is to shield users from this vast and
often arbitrary external complexity. Software offers the ultimate flexibility, so it is possible for
a developer to express almost any kind of abstraction. Engineers try to design the systems with
a separation of concerns, so that the behavior in one part of a system has minimal impact on the
behavior in another.

Generally, complexity takes the form of a hierarchy, whereby a complex system is composed of
interrelated subsystems that have in turn their own subsystems, and so on, until some lowest
level of elementary components is reached. It is important to realize that the architecture of a
complex system is a function of its components as well as the hierarchic relationships among
these components.
Complex systems have common patterns. These patterns may involve the reuse of small
components of larger structures

122 LOVELY PROFESSIONAL UNIVERSITY