Page 134 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes As we move from requirements towards the development of the solution for the user
requirements, a new form of abstraction takes place. The new form of abstraction is necessitated
due to the fact that the solution world includes the computing machines and other logical
constructs that may not exist in the original user requirements. One of the first artifacts from the
solution side is the software architecture and high level design of the software system. At this
point, the abstraction, once again, should not include all the details. The inter-transformation
of the requirements models of abstraction to the design models of abstraction is shown as the
horizontal arrow. Note that the box labelled “Design Models of Abstraction” is the result of
two types of transformations:
1. Inter-transformation from the requirements domain and
2. Intra-transformation within the design solution domain.
The “Implementation Models of Abstraction” box is represents the packaging/loading models of
the processes, information and control of the mechanical execution of the solution in the form of
source code to satisfy the functionalities and the system attributes described in the requirements
and design documents. Thus it is a result of the inter-transformations from requirements models
of abstraction through the design models of abstractions and the intra-transformations from the
actual software execution domain.
The “Implementation Code” box is the specification of this abstraction. The actual execution of
the Implementation Code and the interactions with the users formulate the final deployment of
the source code abstraction or the “Executing Software System” box. Thus the employment of
various abstractions and the transformations of these abstract entities are crucial, integral parts
of software engineering.
• Abstraction is a tool that permits a designer to consider a component at an abstract level
without worrying about the details of the implementation of the component.
• An abstraction of a component describes the external behaviour of that component without
bothering with the internal details that produce the behaviour.
• Abstraction is an indispensable part of the design process and is essential for problem
partitioning.
There are two common abstraction mechanisms for software systems:
Functional Abstraction: A module is specified by the function it performs.
For example, a module to compute the log of a value can be abstractly represented by the
function log. Similarly, a module to sort an input array can be represented by the specification
of sorting. Functional abstraction is the basis of partitioning in function-oriented approaches.
The decomposition of the system is in terms of functional modules.
Data Abstraction: Any entity in the real world provides some services to the environment
to which it belongs. Data is not treated simply as objects, but is treated as objects with some
predefined operations on them. The operations defined on a data object are the only operations
that can be performed on those objects.

6.4 Modularity

The genuine power of partitioning comes if a system is partitioned into modules so that the
modules are solvable and adjustable unconnectedly. It will be even better if the modules are also
separately compliable (then changes in a module will not require recompilation of the whole
system). A system is considered modular if it consists of circumspect components so that each
component can be implemented separately, and a change to one component has minimal impact
on other components. Modularity is a clearly a desirable property in a system. Modularity helps
in system debugging—isolating the system problem to a component is easier if the system is
modular; in system repair—changing a part of the system is easy as it affects few other parts;
and in system building–a modular system can be easily built by “putting its modules together.”

128 LOVELY PROFESSIONAL UNIVERSITY