Ch - 4 Design Concepts

(1) Design Concepts and Principles

 Software design sits at the technical core of software engineering and is applied regardless of the software
process model that is used.
 The design task produces a data design, an architectural design, an interface design, and a component
design.
Data Design
 The data design transforms the information domain model created during analysis into the data
structures that will be required to implement the software.
 The data objects and relationships defined in the entity relationship diagram.
 Part of data design may occur in combination with the design of software architecture.
Architectural Design
 The architectural design defines the relationship between major structural elements of the software.
 The architectural design representation—the framework of a computer-based system—can be derived
from the system specification, the analysis model, and the interaction of subsystems defined within the
analysis model.
Interface Design
 The interface design describes how the software communicates within itself, with systems that
interoperate with it, and with humans who use it.
 An interface implies a flow of information (e.g., data and/or control) and a specific type of behavior.
Therefore, data and control flow diagrams provide much of the information required for interface design.
Component-level Design
 The component-level design transforms structural elements of the software architecture into a
procedural description of software components.
Design principles
1. The design process should not suffer from “tunnel vision.”
2. The design should be traceable to the analysis model.
3. The design should not reinvent the wheel.
4. The design should “minimize the intellectual distance” between the software and the problem as it exists
in the real world.
5. The design should exhibit uniformity and integration.
6. The design should be structured to accommodate change.
7. The design should be structured to degrade gently, even when abnormal data, events, or operating
conditions are encountered.
8. Design is not coding, coding is not design.
9. The design should be assessed for quality as it is being created, not after the fact.
10. The design should be reviewed to minimize conceptual (semantic) errors.

(2) Software architecture and software design

 Architectural design represents the structure of data and program components that are required to build a
computer-based system.
 It considers the architectural style that the system will take, the structure and properties of the components
 that constitute the system, and the interrelationships that occur among all architectural components of a
system.
 Representations of software architecture are an enabler for communication between all parties
(stakeholders) interested in the development of a computer-based system.
 The architecture highlights early design decisions that will have a reflective impact on all software
engineering work that follows and, as important, on the ultimate success of the system as an operational
entity.
 Architecture “constitutes a relatively small, intellectually graspable model of how the system is
structured and how its components work together”

1
 Architectural Design
The software that is built for computer-based systems also exhibits one of many architectural styles.
Each style describes a system category that encompasses
1) A set of components (e.g., a database, computational modules) that perform a function required by a
system.
2) A set of connectors that enable “communication, co-ordinations and cooperation” among components.
3) Constraints that define how components can be integrated to form the system.
4) Semantic models that enable a designer to understand the overall properties of a system by analyzing the
known properties of its constituent parts.
Data-centered architecture style
 A data store (e.g., a file or database) resides at the center of this architecture and is accessed frequently
by other components that update, add, delete, or otherwise modify data within the store.
 Client software accesses a central repository.
 In some cases the data repository is passive.
 That is, client software accesses the data independent of any changes to the data or the actions of other
client software.

Figure: Data-centered architecture

Data-flow architectures
 This architecture is applied when input data are to be transformed through a series of computational or
manipulative components into output data.
 A pipe and filter pattern has a set of components, called filters, connected by pipes that transmit data
from one component to the next.
 Each filter works independently of those components upstream and downstream, is designed to expect
data input of a certain form, and produces data output (to the next filter) of a specified form.
 However, the filter does not require knowledge of the working of its neighboring filters.

Figure: Data-flow architectures

2
Call and return architecture
This architectural style enables a software designer (system architect) to achieve
a program structure that is relatively easy to modify and scale.
A number of sub styles exist within this category:
 Main program/subprogram architectures. This classic program structure
decomposes function into a control hierarchy where a “main” program invokes a
number of program components, which in turn may invoke still other components.
 Remote procedure call architectures. The components of a main program/
subprogram architecture are distributed across multiple computers on a network.
Object-oriented architecture
 The components of a system encapsulate data and the operations that must be
applied to manipulate the data.
 Communication and coordination between components is accomplished via message
passing.
Layered architecture
 A number of different layers are defined, each accomplishing operations that
progressively become closer to the machine instruction set.
 At the outer layer, components service user interface operations.
 At the inner layer, components perform operating system interfacing.
 Intermediate layers provide utility services and application software functions.

(3) Component-Level Design or Procedural Design

 Component-level design, also called procedural design, occurs after data,
architectural, and interface designs have been established.
 Component-level design defines the data structures, algorithms, interface
characteristics, and communication mechanisms allocated to each software
component.
 The intent is to translate the design model into operational software.
 But the level of abstraction of the existing design model is relatively high, and the
abstraction level of the operational program is low.
 Component a modular, deployable, and replaceable part of a system that
encapsulates implementation and exposes a set of interfaces.”

Function Oriented Approach

The following are the salient features of a typical function-oriented design approach:

3
 1. A system is viewed as something that performs a set of functions. Starting
at this highlevel view of the system, each function is successively refined
into more detailed functions.
For example, consider a function create-new-library member which
essentially creates the record for a new member, assigns a unique
membership number to him, and prints a bill towards his membership
charge. This function may consist of the following sub-functions:
̶ assign-membership-number
̶ create-member-record
̶ print-bill
Each of these sub-functions may be split into more detailed sub-functions and so
on.
2. The system state is centralized and shared among different functions, e.g.
data such as member- records is available for reference and updating to
several functions such as:
̶ create-new-member
̶ delete-member
̶ update-member-record
Object Oriented Approach
• In the object-oriented design approach, the system is viewed as collection of
objects (i.e. entities). The state is decentralized among the objects and each
object manages its own state information.
• For example, in a Library Automation Software, each library member may be a
separate object with its own data and functions to operate on these data. In fact,
the functions defined for one object cannot refer or change data of other objects.
• Objects have their own internal data which define their state. Similar objects constitute
a class.
• In other words, each object is a member of some class. Classes may inherit
features from super class. Conceptually, objects communicate by message
passing.
Function-Oriented Vs. Object-Oriented Design
• Unlike function-oriented design methods, in OOD, the basic abstraction are not
real world functions such as sort, display, track, etc., but real-world entities such
as employee, picture, machine, radar system, etc.
• For example in OOD, an employee pay-roll software is not developed by
designing functions such as update-employee record, get-employee-address, etc.
but by designing objects such as employees, departments, etc.
• In object-oriented design, software is not developed by designing functions such
as update-employee- record, get-employee-address, etc., but by designing objects
such as employee, department, etc.
• In OOD, state information is not represented in a centralized shared memory
but is distributed among the objects of the system.
• For example, while developing an employee pay-roll system, the employee data
such as the names of the employees, their code numbers, basic salaries, etc. are
usually implemented as global data in a traditional programming system;
whereas in an object-oriented system these data are distributed among different
employee objects of the system.
• Objects communicate by passing messages. Therefore, one object may discover
the state information of another object by interrogating it. Of course, somewhere
or the other the real-world functions must be implemented.

4
 • Function-oriented techniques such as SA/SD group functions together if, as a
group, they constitute a higher-level function. On the other hand, object-oriented
techniques group functions together on the basis of the data they operate on.

(4) Cohesion and Coupling

• Cohesion is an indication of the relative functional strength of a module.
• A cohesive module performs a single task, requiring little interaction with
other components in other parts of a program. Stated simply, a cohesive module
should (ideally) do just one thing.
• Cohesion is a measure of functional strength of a module.
• A module having high cohesion and low coupling is said to be functionally
independent of other modules. By the term functional independence, we mean
that a cohesive module performs a single task or function.
• Coupling is an indication of the relative interdependence among modules.
• Coupling depends on the interface complexity between modules, the point at
which entry or reference is made to a module, and what data pass across the
interface.
• A module having high cohesion and low coupling is said to be functionally
independent of other modules. If two modules interchange large amounts of data,
then they are highly interdependent.
• The degree of coupling between two modules depends on their interface complexity.
 Classification Cohesion

Coincidental cohesion
• A module is said to have coincidental cohesion, if it performs a set of tasks that
relate to each other very loosely, if at all.
• In this case, the module contains a random collection of functions. It is likely
that the functions have been put in the module out of pure coincidence without
any thought or design.
• For example, in a transaction processing system (TPS), the get-input, print-
error, and summarize- members
• functions are grouped into one module.
Logical cohesion
• A module is said to be logically cohesive, if all elements of the module
perform similar operations, e.g. error handling, data input, data output, etc.
• An example of logical cohesion is the case where a set of print functions
generating different output reports are arranged into a single module.
Temporal cohesion
• When a module contains functions that are related by the fact that all the
functions must be executed in the same time span, the module is said to exhibit
temporal cohesion.
• The set of functions responsible for initialization, start-up, shutdown of some
process, etc. exhibit temporal cohesion.
Procedural cohesion
• A module is said to possess procedural cohesion, if the set of functions of the
module are all part of a procedure (algorithm) in which certain sequence of steps

5
 have to be carried out for achieving an objective, e.g. the algorithm for decoding
a message.

Communicational cohesion
• A module is said to have communicational cohesion, if all functions of the
module refer to or update the same data structure, e.g. the set of functions
defined on an array or a stack.
Sequential cohesion
• A module is said to possess sequential cohesion, if the elements of a module
form the parts of sequence, where the output from one element of the sequence is
input to the next.
• For example, in a TPS, the get-input, validate-input, sort-input functions are grouped
into one module.

Functional cohesion
• Functional cohesion is said to exist, if different elements of a module cooperate
to achieve a single function. For example, a module containing all the functions
required to manage employees’ pay-roll exhibits functional cohesion.
• Suppose a module exhibits functional cohesion and we are asked to describe
what the module does, then we would be able to describe it using a single
sentence.
 Classification of Coupling

Data coupling
• Two modules are data coupled, if they communicate through a parameter. An
example is an elementary data item passed as a parameter between two modules,
e.g. an integer, a float, a character, etc.
• This data item should be problem related and not used for the control purpose.
Stamp coupling
• Two modules are stamp coupled, if they communicate using a composite data
item such as a record in PASCAL or a structure in C.
Control coupling
• Control coupling exists between two modules, if data from one module is used to
direct the order of instructions execution in another.
• An example of control coupling is a flag set in one module and tested in another
module.
Common coupling
• Two modules are common coupled, if they share data through some global data items.
Content coupling
• Content coupling exists between two modules, if they share code, e.g. a branch
from one module into another module.

(5) User Interface Design

 User interface design creates an effective communication medium between a human and
a computer.

6
 Following a set of interface design principles, design identifies interface
objects and actions and then creates a screen layout that forms the basis for a
user interface prototype.

Design Rules for User Interface

(1) Place the User in Control
During a requirements-gathering session for a major new information system, a key
user was asked about Following are the design principles that allow the user to
maintain control:
̶ Define interaction modes in a way that does not force a user
into unnecessary or undesired actions.
An interaction mode is the current state of the interface. For example, if spell
check is selected in a word-processor menu, the software moves to a spell-
checking mode. There is no reason to force the user to remain in spell-
checking mode if the user desires to make a small text edit along the way.
̶ Provide for flexible interaction.
Because different users have different interaction preferences, choices
should be provided. For example, software might allow a user to interact via
keyboard commands, mouse movement, a digitizer pen, a multi touch screen,
or voice recognition commands.
̶ Allow user interaction to be interruptible and undoable.
Even when involved in a sequence of actions, the user should be able to
interrupt the sequence to do something else.
̶ Streamline interaction as skill levels advance and allow the interaction to be
customized.
Users often find that they perform the same sequence of interactions repeatedly.
̶ Hide technical internals from the casual user.
The user interface should move the user into the virtual world of the
application. The user should not be aware of the operating system, file
management functions, or other arcane computing technology.
̶ Design for direct interaction with objects that appear on the screen.
The user feels a sense of control when able to manipulate the objects that
are necessary to perform a task in a manner similar to what would occur if
the object were a physical thing.
(2) Reduce the User’s Memory Load
The more a user has to remember, the more error-prone the interaction
with the system will be. Following are the design principles that enable
an interface to reduce the user’s memory load:
̶ Reduce demand on short-term memory.
When users are involved in complex tasks, the demand on short-term
memory can be significant. The interface should be designed to reduce the
requirement to remember past actions, inputs, and results.
̶ Establish meaningful defaults.
The initial set of defaults should make sense for the average user, but a user
should be able to specify individual preferences. However, a “reset” option
should be available, enabling the redefinition of original default values.
̶ Define shortcuts that are intuitive.
When mnemonics are used to accomplish a system function, the mnemonic
should be tied to the action in a way that is easy to remember.
̶ The visual layout of the interface should be based on a real-world metaphor.
This enables the user to rely on well-understood visual cues, rather than
memorizing an arcane interaction sequence.

7
 ̶ Disclose information in a progressive fashion.
The interface should be organized hierarchically. That is, information about
a task, an object, or some behavior should be presented first at a high level of
abstraction.

(3) Make the Interface Consistent

The interface should present and acquire
information in a consistent fashion. Following are
the design principles that help make the interface
consistent:
̶ Allow the user to put the current task into a meaningful context.
Many interfaces implement complex layers of interactions with dozens of
screen images. It is important to provide indicators that enable the user to
know the context of the work at hand.
̶ Maintain consistency across a family of applications.
A set of applications should all implement the same design rules so that
consistency is maintained for all interaction.
̶ If past interactive models have created user expectations, do not make
changes unless there is a compelling reason to do so.
Once a particular interactive sequence has become a de facto standard, the user
expects this in every application he encounters.
User Interface Design Models
Four different models come into play when a user interface is analyzed and designed.
1. User profile model – Established by a human engineer or software engineer
̶ Establishes the profile of the end-users of the system Based on age,
gender, physical abilities, education, cultural or ethnic background,
motivation, goals, and personality.
̶ The underlying sense of the application; an understanding of the functions
that are performed, the meaning of input and output, and the objectives of
the system Categorizes users as
Novices: No syntactic knowledge of the system, little semantic knowledge of the
application, only general computer usage.
Knowledgeable, intermittent users: Reasonable semantic knowledge of the
system, low recall of syntactic information to use the interface.
Knowledgeable, frequent users:
Good semantic and syntactic knowledge (i.e., power user), look for shortcuts and
abbreviated modes of operation.
2. Design model – Created by a software engineer
̶ Derived from the analysis model of the requirements Incorporates data,
architectural, interface, and procedural representations of the software.
̶ Constrained by information in the requirements specification that helps
define the user of the system.
3. Implementation model – Created by the software implementers
̶ Consists of the look and feel of the interface combined with all
supporting information (books, videos, help files) that describe system
syntax and semantics.
̶ Strives to agree with the user's mental model; users then feel comfortable
with the software and use it effectively.
4. User's mental model – Developed by the user when interacting with the application
̶ Often called the user's system perception. Consists of the image of the
system that users carry in their heads.
̶ Accuracy of the description depends upon the user’s profile and overall
familiarity with the software in the application domain.

8
The role of the interface designer is to merge these differences and derive a consistent
representation of the interface.

(6) Web Application Design

Design for WebApp encompasses technical and nontechnical activities that include:
establishing the look and feel of the WebApp, creating the aesthetic layout of the
user interface, defining the overall architectural structure, developing the content and
functionality that reside within the architecture, and planning the navigation that
occurs within the WebApp.
WebApp Design Quality Requirement
Design is the engineering activity that leads to a high-quality product. This leads
us to a recurring question that is encountered in all engineering disciplines.

Web App Interface Design

The objectives of a WebApp interface are to:
(1) Establish a consistent window into the content and functionality provided by the
interface.
(2) Guide the user through a series of interactions with the WebApp.
(3) Organize the navigation options and content available to the user.

9
Aesthetic Design
 Aesthetic design, also called graphic design, is an artistic endeavor that
complements the technical aspects of WebApp design.
 Without it, a WebApp may be functional, but unappealing. With it, a WebApp
draws its users into a world that embraces them on a primitive, as well as an
intellectual level.
Content Design
 Content design focuses on two different design tasks, each addressed by
individuals with different skill sets.
 First, a design representation for content objects and the mechanisms required
to establish their relationship to one another is developed.
 In addition, the information within a specific content object is created.
 The latter task may be conducted by copywriters, graphic designers, and others
who generate the content to be used within a WebApp.
Architecture Design
 Architecture design is tied to the goals established for a WebApp, the content to
be presented, the users who will visit, and the navigation philosophy that has
been established.
 In most cases, architecture design is conducted in parallel with interface
design, aesthetic design, and content design.
 Because the WebApp architecture may have a strong influence on navigation,
the decisions made during this design action will influence work conducted
during navigation design.
Navigation Design
Once the WebApp architecture has been established and the components (pages,
scripts, applets, and other processing functions) of the architecture have been
identified, you must define navigation pathways that enable users to access WebApp
content and functions.
Component-Level Design
Modern WebApps deliver increasingly sophisticated processing functions that
1. Perform localized processing to generate content and navigation capability in a
dynamic fashion,

10
 2. Provide computation or data processing capability that are appropriate for
the WebApp’s business domain.
3. Provide sophisticated database query and access.
Establish data interfaces with external corporate systems.

 Coding
 The coding is the process of transforming the design of a system into a computer
language format. This coding phase of software development is concerned with software
translating design specification into the source code.

 It is necessary to write source code & internal documentation so that conformance of the
code to its specification can be easily verified.

Goals of Coding

1. To translate the design of system into a computer language format: The coding is
the process of transforming the design of a system into a computer language format,
which can be executed by a computer and that perform tasks as specified by the
design of operation during the design phase.
2. To reduce the cost of later phases: The cost of testing and maintenance can be
significantly reduced with efficient coding.
3. Making the program more readable: Program should be easy to read and
understand. It increases code understanding having readability and understandability
as a clear objective of the coding activity can itself help in producing more
maintainable software.

Some general rules or guidelines in respect of programming style:

1. Clarity and simplicity of Expression: The programs should be designed in such a manner
so that the objectives of the program is clear.

2. Naming: In a program, you are required to name the module, processes, and variable, and
so on. Care should be taken that the naming style should not be cryptic and non-
representative.

For Example: a = 3.14 * r * r

area of circle = 3.14 * radius * radius;

3. Control Constructs: It is desirable that as much as a possible single entry and single exit
constructs used.

4. Information hiding: The information secure in the data structures should be hidden from
the rest of the system where possible. Information hiding can decrease the coupling between
modules and make the system more maintainable.

5. Nesting: Deep nesting of loops and conditions greatly harm the static and dynamic
behavior of a program. It also becomes difficult to understand the program logic, so it is
desirable to avoid deep nesting.

6. User-defined types: Make heavy use of user-defined data types like enum, class, structure,
and union. These data types make your program code easy to write and easy to understand.

11
7. Module size: The module size should be uniform. The size of the module should not be too
big or too small. If the module size is too large, it is not generally functionally cohesive. If the
module size is too small, it leads to unnecessary overheads.

8. Module Interface: A module with a complex interface should be carefully examined.

9. Side-effects: When a module is invoked, it sometimes has a side effect of modifying the
program state. Such side-effect should be avoided where as possible.

Structured Programming

In structured programming, we sub-divide the whole program into small modules so that the
program becomes easy to understand. The purpose of structured programming is to linearize
control flow through a computer program so that the execution sequence follows the sequence
in which the code is written. The dynamic structure of the program than resemble the static
structure of the program. This enhances the readability, testability, and modifiability of the
program. This linear flow of control can be managed by restricting the set of allowed
applications construct to a single entry, single exit formats.

Why we use Structured Programming?

 We use structured programming because it allows the programmer to understand the

program easily.

 If a program consists of thousands of instructions and an error occurs then it is

complicated to find that error in the whole program, but in structured programming, we
can easily detect the error and then go to that location and correct it.

 This saves a lot of time.

These are the following rules in structured programming:

Rule 1 of Structured Programming: A code block is structured, as shown in the figure. In

flow-charting condition, a box with a single entry point and single exit point are structured.
Structured programming is a method of making it evident that the program is correct.

Rule 2 of Structured Programming: Two or more code blocks in the sequence are
structured, as shown in the figure.

12
Rule 3 of Structured Programming: The alternation of two code blocks is structured, as
shown in the figure.

An example of an entry condition for an alternation method is: register $8 includes a signed
integer. The exit condition may be: register $8 includes the absolute value of the signed
number. The branch structure is used to fulfill the exit condition.

Rule 4 of Structured Programming: The iteration of a code block is structured, as shown in

the figure.

Rule 5 of Structured Programming: A structure (of any size) that has a single entry point
and a single exit point is equivalent to a code block. For example, we are designing a program
to go through a list of signed integers calculating the absolute value of each one. We
may (1) first regard the program as one block, then (2) sketch in the iteration required, and
finally (3) put in the details of the loop body, as shown in the figure.

13
The other control structures are the case, do-until, do-while, and for are not needed. However,
they are sometimes convenient and are usually regarded as part of structured programming. In
assembly language, they add little convenience.

Types Of Software Documentation :

1. Requirement Documentation: It is the description of how the software shall perform
and which environment setup would be appropriate to have the best out of it. These are
generated while the software is under development and is supplied to the tester groups
too.
2. Architectural Documentation: Architecture documentation is a special type of
documentation that concerns the design. It contains very little code and is more focused
on the components of the system, their roles, and working. It also shows the data flow
throughout the system.
3. Technical Documentation: These contain the technical aspects of the software like
API, algorithms, etc. It is prepared mostly for software devs.
4. End-user Documentation: As the name suggests these are made for the end user. It
contains support resources for the end user.

14