Page 132 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes to do it right. You also gain knowledge about how to do it right again. If you do think about
something and still do it wrong, it becomes valuable experience. A side effect of thinking is
learning to recognize when you do not know something, at which point you can research the
answer. When clear thought has gone into a system, value comes out. Applying the first six
Principles requires intense thought, for which the potential rewards are enormous.
The following other some points in Principles of Functional Design
• The design process should not suffer from tunnel vision.
• The design should be traceable to the analysis model.
• The design should not reinvent the wheel.
• The design should “minimize the intellectual distance” between the SW and the problem
as it exists in the real world.
• The design should exhibit uniformity and integration.
• The design should be structured to accommodate change.
• The design should be structured to degrade gently.
• Design is not coding.
• The design should be assessed for quality.
• The design should review to minimize conceptual errors.
• External quality factors: Observed by users.
• Internal quality factors: Important to engineers.

6.3 Abstraction

Abstraction is a very influential concept that is used in all engineering disciplines. It is a tool
that permits a designer to think a component at an abstract level without worrying about the
details of the implementation of the component. Any component or system provides some armed
forces to its environment. An abstraction of a component describes the external behavior of that
component without bothering with the internal details that produce the behavior. Presumably,
the abstract definition of a component is much simpler than the component itself.
When we consider a modular solution to any problem, many levels of abstraction can be posed.
At the highest level of abstraction, a solution is stated in broad terms using the language of the
problem environment. At lower levels of abstraction, a more procedural orientation is taken.
Problem-oriented terminology is coupled with implementation oriented terminology in an effort
to state a solution. Finally, at the lowest level of abstraction, the solution is stated in a manner
that can be directly implemented. Each step in the software process is a refinement in the level
of abstraction of the software solution. During system engineering, software is allocated as
an element of a computer-based system. During software requirements analysis, the software
solution is stated in terms “that are familiar in the problem environment.” As we move through
the design process, the level of abstraction is reduced. Finally, the lowest level of abstraction is
reached when source code is generated. As we move through different levels of abstraction, we
work to create procedural and data abstractions. A procedural abstraction is a named sequence
of instructions that has a specific and limited function. An example of a procedural abstraction
would be the word open for a door. Open implies a long sequence of procedural steps (e.g.,
walk to the door, reach out and grasp knob, turn knob and pull door, step away from moving
door, etc.). A data abstraction is a named collection of data that describes a data object. In the
context of the procedural abstraction open, we can define a data abstraction called door. Like
any data object, the data abstraction for door would encompass a set of attributes that describe
the door (e.g., door type, swing direction, opening mechanism, weight, dimensions). It follows
that the procedural abstraction open would make use of information contained in the attributes
of the data abstraction door.

126 LOVELY PROFESSIONAL UNIVERSITY