Modularity: –

Software is divided into separately named and addressable components which are
called modules. Those are integrated to satisfy problem requirements. Modularity is a single
attribute of software that allows a program to be intellectually manageable.

Monolithic software i.e. a large program composed of a single module cannot be easily
readable the number of control paths, spend of referential number of variables and overall
complexity would make understanding close of impossible.

It is easier to solve a complex problem when you break it into manageable PCs
(Modules). When we divide software in to modules then development effort also decreased.

From above graph we can show that as the number of modules grows the effort or cost
associated with integrating the module also grows.

These characteristics leads to a total cost or effort which shown in above figure. This is a
M of modules that would result in minimum development cost and here another important
question arises when modularity is consider how do we define an appropriate module of a given
size? The answer lies in the method use to define modules within a system.

Functional independence is evaluated using two criteria:

1. Cohesion

Cohesion is a measure of the relative functional strength of a module.

2. Coupling

Coupling is a measure of the relative interdependence among modules.

Cohesion

Cohesion: Cohesion is the measure of strength of the association of elements within a

module. A cohesive module performs a single task within a software procedure, which has less
interaction with procedures in other part of the program. In practice, designer should avoid low-
level of cohesion when designing a module. Generally, low coupling results in high cohesion and
vice versa.

The various types of cohesion are listed below:

• Functional cohesion:

In this, the elements within the modules contribute to the execution of one and only one
problem related task.

Sequential cohesion:

In this, the elements within the modules are involved in activities in such a way that
output data from one activity serves as input data to the next activity.
Communicational cohesion:

In this, the elements within the modules perform different functions, yet each function
references the same input or output information.

Procedural cohesion:

In this, the elements within the modules are involved in different and possibly unrelated
activities.
Temporal cohesion:

In this, the elements within the modules contain unrelated activities that can be carried
out at the same time.

Logical cohesion:

In this, the elements within the modules perform similar activities, which are executed
from outside the module.

Coincidental cohesion:
In this, the elements within the modules perform activities with no meaningful relationship to one another.
Coupling:

In software engineering, coupling is the degree of interdependence between software

modules; a measure of how closely connected two routines or modules are the strength of the
relationships between modules.

Coupling can be "low" (also "loose" and "weak") or "high" (also "tight" and "strong").
Some types of coupling, in order of highest to lowest coupling, are as follows:

A module here refers to a subroutine of any kind, i.e. a set of one or more statements
having a name and preferably its own set of variable names.
 1. Content coupling:

Two modules are content coupled if one module changes a statement in another module,
one module references or alters data contained inside another module, or one-module branches
into another module. In the below figure, Modules B and Module D are content coupled.

2. Common coupling:

Two modules are common coupled if they both share the same global data area. In
Figure, Modules C and Module N are common coupled.
 3. Control coupling:

Two modules are control coupled if they communicate (passes a piece of information
intended to control the internal logic) using at least one ‘control flag’. The control flag is a
variable that controls decisions in subordinate or superior modules. In below figure , when
Module 1 passes control flag to Module 2, Module 1 and Module 2 are said to be control
coupled.

4. Stamp coupling:

Two modules are stamp coupled if they communicate through a passed data structure that
contains more information than necessary for them to perform their functions. In below figure,
data structure is passed between modules 1 and 4. Therefore, Module 1 and Module 4 are stamp
coupled.

5. Data coupling:

Two modules are data coupled if they communicate by passing parameters. In below
figure, Module 1 and Module 3 are data coupled.

6. No direct coupling:

Two modules are no direct coupled when they are independent of each other. In below
figure, Module 1 and Module 2 are no directly coupled.
 Data flow-Oriented design

• A Data Flow Diagram (DFD) is traditional visual representation of the information flows
within a system. A neat and clear DFD can represent a good amount of the system
requirements graphically. It can be manual, automated, or combination of both.

• It shows how information enters and leaves the system, what changes the information and
where information is stored.

• The purpose of a DFD is to show the scope and boundaries of a system as a whole. It may
be used as a communications tool between a systems analyst and any person who plays a
part in the system.

DFD should not be confused with a flowchart. A DFD represents the flow of data
whereas flowchart depicts the flow of control. Also, a DFD does not represent the information
about the procedure to be used for accomplishing the task. Hence, while making DFD,
procedural details about the processes should not be shown. DFD helps a software designer to
describe the transformations taking place in the path of data from input to output.

DFDs only involve four symbols. They are:

 Process
 Data Object
 Data Store
 External entity

There are several notations of the data flow diagrams. In the following, four different shapes are
explained.

Process
A process is a business activity or function where the manipulation and transformation of data
takes place.

External Agent

• External systems which are outside the boundary of this system, these are represented
using the squares

Data Store

A data store represents the storage of persistent data required and/or produced by the
process. Here are some examples of data stores: membership forms, database table, etc.

• Where data is being stored for later retrieval.

• Provides input to the process

• Outputs of the processes may be going into these data stores.

Data Flow

• A data flow represents the flow of information, with its direction represented by an arrow
head that shows at the end(s) of flow connector.

• Where the data is flowing.

• Represents the movement of the data in a data flow diagram.

Data Flow Model – Bank Account Management System

• In the following, we are presenting a data flow model that describes an accounts
management system for a bank.
 • This data flow diagram consists of the following entities.

Description:

• First we shall discuss ‘withdraw funds from an account’ process. In this process,
information about the accounts and account transactions is retrieved (from the data
stores) and bank releases the funds. After this, it sends this information to ‘reconcile
account balance’ process which prepares a monthly account statement. In this statement,
information regarding bank accounts and account transactions are described.

• Next is the ‘pay a bill’ process through which a creditor pays his dues and the
corresponding accounts are updated against the cash transaction. A receipt is issued back
to the creditor.

• The fourth process is ‘deposits funds in an account’ in which an employer deposits

salaries of his employees and the salary information is deposited in the corresponding
bank accounts of the employees. Similarly, income received through other income
sources is also received and deposited in the corresponding bank accounts.

User interface design:

What is User Interface Design?

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

Interface design focuses on three areas of concern:

1. The design of interfaces between software components,

2. The design of interfaces between the software and other nonhuman producers and
consumers of information (i.e., other external entities), and
3. The design of the interface between a human (i.e., the user) and the computer.

The Golden Rules

Theo Mandel coins three “golden rules”:

1. Place the user in control.

2. Reduce the user’s memory load.

3. Make the interface consistent.

These golden rules actually form the basis for a set of user interface design principles that guide this
important software design activity.

1. Place the User in Control

a. Define interaction modes in a way that does not force a user into unnecessary or
undesired actions

The user shall be able to enter and exit a mode with little or no effort

b. Provide for flexible interaction

The user shall be able to perform the same action via keyboard commands, mouse movement, or voice
recognition

c. Allow user interaction to be interruptible and "undo“ able

The user shall be able to easily interrupt a sequence of actions to do something else (without losing
the work that has been done so far)

The user shall be able to "undo" any action

d. Streamline interaction as skill levels advance and allow the interaction to be

customized.

The user shall be able to use a macro mechanism to perform a sequence of repeated interactions and
to customize the interface

e. Hide technical internals from the casual user

The user shall not be required to directly use operating system, file management, networking. etc.
commands to perform any actions. Instead, these operations shall be hidden from the user and performed
"behind the scenes"

f. Design for direct interaction with objects that appear on the screen

The user shall be able to manipulate objects on the screen in a manner similar to what would occur
if the object were a physical thing (e.g., stretch a rectangle, press a button, move a slider)

2. Reduce the User's Memory Load

The more a user has to remember, the more error-prone interaction with the system will be. Good
interface design does not tax the user’s memory. System should remember pertinent details and assist the
user with interaction scenario that assists user recall.

a. Reduce demand on short-term memory

The interface shall reduce the user's requirement to remember past actions and results by providing
visual cues of such actions

b. Define shortcuts that are intuitive (spontaneous)

The user shall be provided mnemonics (i.e., control or alt combinations) that tie easily to the action
in a way that is easy to remember such as the first letter.
 c. The visual layout of the interface should be based on a real world metaphor

The screen layout of the user interface shall contain well-understood visuals that the user can relate
to real-world actions

d. Disclose information in a progressive fashion

When interacting with a task, an object or some behavior, the interface shall be organized
hierarchically by moving the user progressively in a step-wise fashion from an abstract concept to a
concrete action (e.g., text format options format dialog box)

3. Make the Interface Consistent

a. The interface should present and acquire information in a consistent fashion

 All visual information shall be organized according to a design standard that is

maintained throughout all screen displays

 Input mechanisms shall be constrained to a limited set that is used consistently

throughout the application

 Mechanisms for navigating from task to task shall be consistently defined and
implemented

b. Maintain consistency across a family of applications

A set of applications performing complimentary functionality shall all implement the same design
rules so that consistency is maintained for all interaction

c. 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 (e.g., alt-S to save a file),
the application shall continue this expectation in every part of its functionality