Module 3

Software Design

Design
Design engineering encompasses the set of principals, concepts, and practices that lead to
the development of a high- quality system or product. Design concepts must be understood
before the mechanics of design practice are applied and Design practice itself leads to the
creation of various representations of the software that serve as a guide for the construction
activity that follows.

What is design: Design is what virtually every engineer wants to do. It is the place where
creativity rules – customer‘s requirements, business needs, and technical considerations all come
together in the formulation of a product or a system. Design creates a representation or model of
the software, but unlike the analysis model, the design model provides detail about software data
structures, architecture, interfaces, and components that are necessary to implement the system.

Why it is important: Design allows a software engineer to model the system or product that Is
to be built. This model can be assessed for quality and improved before code is generated, tests
are conducted, and end – users become involved in large numbers. Design is the place where
software quality is established.

The goal of design engineering is to produce a model or representation that exhibits firmness,
commodity, and delight. To accomplish this, a designer must practice diversification and then
convergence. Another goal of software design is to derive an architectural rendering of a system.
The rendering serves as a framework from which more detailed design activities are conducted.

The Design Process

Software design is an iterative process through which requirements are translated into a
“blueprint” for constructing the software. That is, the design is represented at a high level of
abstraction—a level that can be directly traced to the specific system objective and more detailed
data, functional, and behavioral requirements. As design iterations occur, subsequent refinement
leads to design representations at much lower levels of abstraction. These can still be traced to
requirements, but the connection is more subtle.

Software Quality Guidelines and Attributes:

Throughout the design process, the quality of the evolving design is assessed with a series of
technical reviews. The three characteristics that serve as a guide for the evaluation of a good
design:

 The design must implement all of the explicit requirements contained in the requirements
model, and it must accommodate all of the implicit requirements desired by stakeholders.

1
  The design must be a readable, understandable guide for those who generate code and for
those who test and subsequently support the software.

 The design should provide a complete picture of the software, addressing the data,
functional, and behavioral domains from an implementation perspective.

Quality Guidelines: In order to evaluate the quality of a design representation, the software
team must establish technical criteria for good design. Guide lines are as follows
1. A design should exhibit an architecture that (1) has been created using recognizable
architectural styles or patterns, (2) is composed of components that exhibit good design
characteristics (these are discussed later in this chapter), and (3) can be implemented in an
evolutionary fashion, thereby facilitating implementation and testing.
2. A design should be modular; that is, the software should be logically partitioned into elements
or subsystems.
3. A design should contain distinct representations of data, architecture, interfaces, and
components.
4. A design should lead to data structures that are appropriate for the classes to be implemented
and are drawn from recognizable data patterns.
5. A design should lead to components that exhibit independent functional characteristics.
6. A design should lead to interfaces that reduce the complexity of connections between
components and with the external environment.
7. A design should be derived using a repeatable method that is driven by information obtained
during software requirements analysis.
8. A design should be represented using a notation that effectively communicates its meaning.

Quality Attributes. Hewlett-Packard developed a set of software quality attributes that has been
given the acronym FURPS—functionality, usability, reliability, performance, and supportability.
The FURPS quality attributes represent a target for all software design:
• Functionality is assessed by evaluating the feature set and capabilities of the program, the
generality of the functions that are delivered, and the security of the overall system.
• Usability is assessed by considering human factors, overall aesthetics, consistency, and
documentation.
• Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of
output results, the mean-time-to-failure (MTTF), the ability to recover from failure, and the
predictability of the program.
• Performance is measured by considering processing speed, response time, resource
consumption, throughput, and efficiency.
• Supportability combines the ability to extend the program (extensibility), adaptability,
serviceability—these three attributes represent a more common term, maintainability—and in
addition, testability, compatibility, configurability, the ease with which a system can be installed,
and the ease with which problems can be localized.

2
Data Design

Data design is the first design activity, which results in less complex, modular and efficient
program structure. The information domain model developed during analysis phase is
transformed into data structures needed for implementing the software. The data objects,
attributes, and relationships depicted in entity relationship diagrams and the information stored in
data dictionary provide a base for data design activity. During the data design process, data types
are specified along with the integrity rules required for the data. For specifying and designing
efficient data structures, some principles should be followed. These principles are listed below.

 The data structures needed for implementing the software as well-as the operations that
can be applied on them should be identified.

 A data dictionary should be developed to depict how different data objects interact with
each other and what constraints are to be imposed on the elements of data structure.

 Language used for developing the system should support abstract data types.

 Stepwise refinement should be used in data design process and detailed design decisions
should be made later in the process.

 Only those modules that need to access data stored in a data structure directly should be
aware of the representation of the data structure.

 A library containing the set of useful data structures along with the operations that can be
performed on them should be maintained.

The structure of data can be viewed at three levels, namely, program component level,
application level, and business level. At the program component level, the design of data
structures and the algorithms required to manipulate them is necessary, if high-quality software
is desired. At the application level, it is crucial to convert the data model into a database so that
the specific business objectives of a system could be achieved. At the business level, the
collection of information stored in different databases should be reorganized into data
warehouse, which enables data mining that has an influential impact on the business

3
Architectural Design

The software architecture of a program or computing system is the structure or structures of the
system, which comprise software components, the externally visible properties of those
components, and the relationships among them. The architecture is not the operational software.
Rather, it is a representation that enables you to

(1) Analyze the effectiveness of the design in meeting its stated requirements
(2) Architectural alternatives at a stage when making design changes is still relatively easy
(3) Reduce the risks associated with the construction of the software.

This definition emphasizes the role of “software components” in any architectural representation.
In the context of architectural design, a software component can be something as simple as a
program module or an object-oriented class, but it can also be extended to include databases and
“middleware” that enable the configuration of a network of clients and servers. The properties of
components are those characteristics that are necessary for an understanding of how the
components interact with other components. At the architectural level, internal properties (e.g.,
details of an algorithm) are not specified. The relationships between components can be as
simple as a procedure call from one module to another or as complex as a database access
protocol.

Why Is Architecture Important?: Three key reasons that software architecture is important:
• 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 profound 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”.

Architectural Styles

Architectural 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, coordination and cooperation” among
components;
(3) Constraints that define how components can be integrated to form the system; and
(4) Semantic models that enable a designer to understand the overall properties of a system by
analyzing the known properties of its constituent parts.

The use of architectural styles is to establish a structure for all the components of the system.

4
Taxonomy of Architectural Styles:

Although millions of computer-based systems have been created over the past 60 years, the vast
majority can be categorized into one of a relatively small number of architectural styles:

1. Data centered architectures:

A data store will reside at the center of this architecture and is accessed frequently by the
other components that update, add, delete or modify the data present within the store.

The figure illustrates a typical data centered style. The client software access a central
repository. Variation of this approach is used to transform the repository into a blackboard
when data related to client or data of interest for the client change the notifications to client
software.

This data-centered architecture will promote inerrability. This means that the existing
components can be changed and new client components can be added to the architecture
without the permission or concern of other clients.

Data can be passed among clients using blackboard mechanism.

2. Data flow architectures:

a. This kind of architecture is used when input data to be transformed into output data through
a series of computational manipulative components.
b. The figure represents pipe-and-filter architecture since it uses both pipe and filter and it has
a set of components called filters connected by pipes.
c. Pipes are used to transmit data from one component to the next.
d. Each filter will work independently and is designed to take data input of a certain form and
produces data output to the next filter of a specified form. The filters don’t require any
knowledge of the working of neighboring filters.
5
 e. If the data flow degenerates into a single line of transforms, then it is termed as batch
sequential. This structure accepts the batch of data and then applies a series of sequential
components to transform it.

3. Call and Return architectures:

It is used to create a program that is easy to scale and modify. Many sub-styles exist within
this category. Two of them are explained below.
a. Remote procedure call architecture: This components is used to present in a main
program or sub program architecture distributed among multiple computers on a network.
b. Main program or Subprogram architectures: The main program structure decomposes
into number of subprograms or function into a control hierarchy. Main program contains
number of subprograms that can invoke other components.

4. Object Oriented architecture:

The components of a system encapsulate data and the operations that must be applied to
manipulate the data. The coordination and communication between the components are
established via the message passing.
6
5. Layered architecture:
a. A number of different layers are defined with each layer performing a well-defined set of
operations. Each layer will do some operations that becomes closer to machine instruction
set progressively.
b. At the outer layer, components will receive the user interface operations and at the inner
layers, components will perform the operating system interfacing(communication and
coordination with OS)
c. Intermediate layers to utility services and application software functions.

7
Component Level Design

Component-level design defines the data structures, algorithms, interface characteristics, and
communication mechanisms allocated to each software component. A component is a modular
building block for computer software. More formally, component is “a modular, deployable, and
replaceable part of a system that encapsulates implementation and exposes a set of interfaces.”
In addition, it specifies an interface that may be used to access the functionality of all the
software components.

The component-level design can be represented by using different approaches. One approach is
to use a programming language while other is to use some intermediate design notation such as
graphical (DFD, flowchart, or structure chart), tabular (decision table), or text-based (program
design language) whichever is easier to be translated into source code.

The component-level design provides a way to determine whether the defined algorithms, data
structures, and interfaces will work properly. Note that a component (also known as module) can
be defined as a modular building block for the software. However, the meaning of component
differs according to how software engineers use it. The modular design of the software should
exhibit the following sets of properties.

 Provide simple interface: Simple interfaces decrease the number of interactions.

Note that the number of interactions is taken into account while determining whether
the software performs the desired function. Simple interfaces also provide support
for reusability of components which reduces the cost to a greater extent. It not only
decreases the time involved in design, coding, and testing but the overall software
development cost is also liquidated gradually with several projects. A number of
studies so far have proven that the reusability of software design is the most valuable
way of reducing the cost involved in software development.

 Ensure information hiding: The benefits of modularity cannot be achieved merely by

decomposing a program into several modules; rather each module should be
designed and developed in such a way that the information hiding is ensured. It
implies that the implementation details of one module should not be visible to other
modules of the program. The concept of information hiding helps in reducing the
cost of subsequent design changes.

Modularity has become an accepted approach in every engineering discipline. With the
introduction of modular design, complexity of software design has considerably reduced; change

8
in the program is facilitated that has encouraged parallel development of systems. To achieve
effective modularity, design concepts like functional independence are considered to be very
important.

Functional Independence
Functional independence is the refined form of the design concepts of modularity, abstraction,
and information hiding. Functional independence is achieved by developing a module in such a
way that it uniquely performs given sets of function without interacting with other parts of the
system. The software that uses the property of functional independence is easier to develop
because its functions can be categorized in a systematic manner. Moreover, independent
modules require less maintenance and testing activity, as secondary effects caused by design
modification are limited with less propagation of errors. In short, it can be said that functional
independence is the key to a good software design and a good design results in high-quality
software. There exist two qualitative criteria for measuring functional independence,
namely, coupling and cohesion.

Coupling

Coupling in Software Engineering is a part of Software Requirement Specification (SRS)

documentation that is used to define the factors of dependency and independence of each
module of the software with other modules. It is used as an indicator of interdependency
amongst the modules, and the lower the coupling value will be, the higher the quality of the
software will be. The name coupling is applied for this process, as it is typically deliberated
between two modules at a time. The first step taken in the coupling process is to evaluate the
association between the two modules and to define the functionally dependent areas in the
modules.
Coupling measures the degree of interdependence among the modules. Several factors like
interface complexity, type of data that pass across the interface, type of communication, number
of interfaces per module, etc. influence the strength of coupling between two modules. For
better interface and well-structured system, the modules should be loosely coupled in order to

9
minimize the ‘ripple effect’ in which modifications in one module results in errors in other
modules. Module coupling is categorized into the following types.

Types of Coupling
Coupling between any two modules is identified from the number and types of resources that the

modules share with other modules. This resource can be a functional behavior, a common

interface, a common field in a user interface, the data picked from a field and shared between

two modules, a transaction shared between two modules, etc. Based on these possible

dependencies, the coupling in software engineering is classified into six different types of

coupling. And, they are

 Common Coupling

 Content Coupling

10
  Data Coupling

 Control Coupling

 Stamp Coupling

 External

Every software requirement specification documentation process should have a classification of

these coupling between the dependent modules, whichever is applicable after a brief evaluation

performed on the requirement provided by the client.

1. Common Coupling
Common Coupling consists of the modules that share the overall constraints in the midst of any

two modules of the software system. This also can be a sign of any change made in the common

constraint will reflect in the modules that share the common coupling scenario. As any other

process, this common coupling also allows space for characterizing the advantages and

disadvantages involved in the process. This type of dependency should be evaded as it calls for

more maintenance activities and lesser control over the modules. A fine example of this kind of

coupling is the login page, where the login module and the backend module are interdependent,

as the login validation happens both in the login page level and the backend database level.

2. Content Coupling
Content coupling, as the name says, is a case where two modules share their contents and when a

change is made in one module the other module needs to be updated as well. When the modules

are not in synch, it leads to higher level of functional misbehavior. For Instance, when two

11
modules share the same data, the primary key columns for both the modules’ databases should be

related, or else the content of the modules will reflect non-synch data due to the dependency.

3. Data Coupling
When two modules of the software system has only one type of interaction between them, and of

that interaction is in the form of data, then this type of coupling is termed as Data Coupling.

Other than the form of data, the modules have no other commonly shared resources like the

functionality or any other system components. An example of data coupling is that two user

interfaces, which share data in terms like module 1 passes data for processing to module 2 and

received the processed data back from module 2. Though all the coupling needs to be minimized,

this type of coupling is tolerable as it does not affect any other functional behavior of the

software.

Control Coupling
Control coupling is a functional flow of the software where the two software modules network

by provisioning the shared control involving the modules’ functional activities. The impact of

this type of coupling on the software application can either be a positive one or a negative one, as

it can be defined only based on the type of control being shared by the said modules. It is seen as

a positive impact, when the functionality is allowed for reusability. This type of coupling is

usually observed in code level, when the arguments are reused in more than one place in the

functional part of the code.

5. Stamp Coupling
Stamp coupling is detected between any two modules which share a compilation of an already

structured intricate set of data. As the data and elements are pre-organized and well-placed

12
beforehand, there will be no junk or unused data shared between the two coupling modules. This

helps in improving the general efficiency of the software and its performance, while the system

designer should know the limitations to what extent the stamp coupling can be allowed in the

system.

6. External Coupling
External coupling can be described as a situation where the modules are interrelated with

common external influencing factors. It can be ‘an external legacy application which sends the

same set of data or contents to both modules’, or ‘a hardware requirement common for both

modules’, or ‘a common file/ folder being used by both modules’, or ‘when both use same

switch/ router in the network for communication’, etc.

Advantages of Coupling in Software Engineering

In the Software Engineering process, as a part of Software Development Lifecycle, the Design

phase has ‘coupling’ as one of the essential steps to be completed.

Below are the key advantages of performing the coupling process,

 It helps in identifying the dependencies of each module with other modules in the

 It is mainly used for increasing the quality and performance of the software application,

as the analysis aids in keeping the coupling value to the

 Coupling supports the reusability of the functionality amongst the

 When the dependency between the modules is less, the changes done in one unit will not

affect the

13
  It provides room for better methods for the maintenance of the system.

Cohesion

Cohesion measures the relative functional strength of a module. It represents the strength of
bond between the internal elements of the modules. The tighter the elements are bound to each
other, the higher will be the cohesion of a module. In practice, designers should avoid a low
level of cohesion when designing a module. Generally, low coupling results in high cohesion
and vice versa.
Various types of cohesion are listed below.

Functional Cohesion
 The execution of the task related to the problem is the only concern from all the elements

inside the module.

 The purpose of functional cohesion is single minded, strong and focused.

 All the elements in the module perform only the necessary activities.

 Some of the examples of functional cohesion are read transaction record, cosine angle

computation, seat assignment to an airline passenger etc.

2. Sequential Cohesion
 The data which is the output of one activity is used an input data for the next activity, the

involvement of elements is as such.

 Sequential cohesion is easy maintenance and provides a good coupling.

 Sequential cohesion cannot be reused readily because of the activities that are not useful

even when used together.

14
  Some of the examples of sequential cohesion are cross validate record and formatting of

module, raw records usage, formatting of raw records, cross validation of fields in raw

records, returning of formatted cross validated records.

3. Communicational Cohesion
 The activities using the same input data or output data are contributed by the elements

inside the module.

 Communicational cohesion is not flexible like we can only focus on some of the activities

and not others at once.

 Communicational cohesion consists of the links because of which the activities affect

each other.

 The cohesive ones that are functional are split by communicational cohesion.

 Some of the examples of communicational cohesion are customer details determining

modules, usage of customer account number, finding the name of the customer, finding

the loan balance of the customer, returning loan balance and the name of the customer

etc.

4. Procedural Cohesion
 The activities are related if the elements in the module are related by sequence, otherwise

they are not related.

 Procedural cohesion and sequential cohesion are like each other except that the elements

in the module of procedural cohesion are not related.

 Procedural cohesion is found at the top of the hierarchy like the module of main program.

15
  Some of the examples of procedural cohesion are read, write, edit of the module, record

use out, writing out the record, reading the record, zero padding to the numeric fields,

returning records etc.

5. Temporal Cohesion
 The activities related in time consists of elements from the module.

 Temporal cohesion is found in the modules of initialization and termination.

 The module cannot be reused because the elements in the module are not related to each

other.

 The best practice in temporal cohesion is to terminate as early as possible and initialize as

late as possible.

 Some of the examples of temporal cohesion are initialization of module, setting

the counter to zero, opening the student file, clearing the variables of error message,

initializing the array etc.

6. Logical Cohesion
 The activities of the same type or same general category is contributed by the elements in

the module.

 Examples of activities of the same type or same general category being contributed by the

elements in the module include a report module, display module or intput output module.

 Logical cohesion consists of control coupling as one of the activities will be selected.

 Some of the examples of logical cohesion are module for displaying record as below:

16
 o Use type of the record as record.

o If type of the record is student. then,

o Display the record from student.

o Else if the type of the record is staff, then

o Display the record from staff.

7. Coincidental Cohesion
 The activities with meaningless relationship with one another are contributed by the

elements in the module.

 Coincidental cohesion and logical cohesion are like each other except that the activities

will be of different types.

 Coincidental cohesion consists combination of activities like rojak.

 Understanding and maintenance of Coincidental cohesion is difficult and there are

possibilities of side effects whenever there is modification in the module.

 Some of the examples of coincidental cohesion are module for miscellaneous functions,

customer record usage, displaying of customer record, calculation of total sales, reading

the transaction record etc.

Advantages of Cohesion is Software Engineering

Below are the advantages using Cohesion is Software Engineering:

17
1. The complexity of the modules can be reduced using cohesion in software

engineering. The modules can be made simpler consisting of very few operations using

cohesion in software engineering.

2. The maintainability of the system can be increased using cohesion in software

engineering because whenever there are logical changes in the domain, only fewer

modules are affected and change in one module cause very few changes in other

modules.

3. The reusability of the modules can be increased by using cohesion in software

engineering because the components needed by the developers of the application can be

found easily in a cohesive set of operations produced by the module using cohesion in

software engineering.

4. Cohesion in software engineering has a balance between both unit complexity and

coupling because a perfect cohesion is possible in a module if only it consists of single

element that is atomic and consisting of only one function. Such module consisting of

only one element can be either too complicated in order to be able to achieve the task or

can be too narrow while being in tight coupling with other modules.

18
19
User Interface Design

User interface is the front-end application view to which user interacts in order to use the
software. User can manipulate and control the software as well as hardware by means of user
interface. Today, user interface is found at almost every place where digital technology exists,
right from computers, mobile phones, cars, music players, airplanes, ships etc.

User interface is part of software and is designed such a way that it is expected to provide the
user insight of the software. UI provides fundamental platform for human-computer interaction.
UI can be graphical, text-based, audio-video based, depending upon the underlying hardware and
software combination. UI can be hardware or software or a combination of both.

The software becomes more popular if its user interface is:

 Attractive
 Simple to use
 Responsive in short time
 Clear to understand
 Consistent on all interfacing screens

UI Design Principles

Structure: Design should organize the user interface purposefully, in the meaningful and usual
based on precise, consistent models that are apparent and recognizable to users, putting related
things together and separating unrelated things, differentiating dissimilar things and making
similar things resemble one another. The structure principle is concerned with overall user
interface architecture.

Simplicity: The design should make the simple, common task easy, communicating clearly and
directly in the user's language, and providing good shortcuts that are meaningfully related to
longer procedures.

Visibility: The design should make all required options and materials for a given function visible
without distracting the user with extraneous or redundant data.

Feedback: The design should keep users informed of actions or interpretation, changes of state
or condition, and bugs or exceptions that are relevant and of interest to the user through clear,
concise, and unambiguous language familiar to users.

Tolerance: The design should be flexible and tolerant, decreasing the cost of errors and misuse
by allowing undoing and redoing while also preventing bugs wherever possible by tolerating
varied inputs and sequences and by interpreting all reasonable actions.

20
There are two types of User Interface:
1. Command Line Interface: Command Line Interface provides a command prompt,
where the user types the command and feeds to the system. The user needs to
remember the syntax of the command and its use.

Advantages
o Many and easier to customizations options.
o Typically capable of more important tasks.

Disadvantages
o Relies heavily on recall rather than recognition.
o Navigation is often more difficult.

2. Graphical User Interface: Graphical User Interface provides the simple interactive
interface to interact with the system. GUI can be a combination of both hardware and
software. Using GUI, user interprets the software.

Advantages
o Less expert knowledge is required to use it.
o Easier to Navigate and can look through folders quickly in a guess and check
manner.
o The user may switch quickly from one task to another and can interact with
several different applications.

Disadvantages
o Typically decreased options.
o Usually less customizable. Not easy to use one button for tons of different
variations.

User Interface Design Process:

21
The analysis and design process of a user interface is iterative and can be represented by a spiral
model. The analysis and design process of user interface consists of four framework activities.

1. User, task, environmental analysis, and modeling: Initially, the focus is based on
the profile of users who will interact with the system, i.e. understanding, skill and
knowledge, type of user, etc, based on the user’s profile users are made into
categories. From each category requirements are gathered. Based on the
requirements developer understand how to develop the interface. Once all the
requirements are gathered a detailed analysis is conducted. In the analysis part, the
tasks that the user performs to establish the goals of the system are identified,
described and elaborated. The analysis of the user environment focuses on the
physical work environment. Among the questions to be asked are:

 Where will the interface be located physically?

 Will the user be sitting, standing, or performing other tasks unrelated to the
interface?
 Does the interface hardware accommodate space, light, or noise constraints?
 Are there special human factors considerations driven by environmental factors?

2. Interface Design: The goal of this phase is to define the set of interface objects and
actions i.e. Control mechanisms that enable the user to perform desired tasks.
Indicate how these control mechanisms affect the system. Specify the action
sequence of tasks and subtasks, also called a user scenario. Indicate the state of the
system when the user performs a particular task. Always follow the three golden
rules stated by Theo Mandel. Design issues such as response time, command and
action structure, error handling, and help facilities are considered as the design
model is refined. This phase serves as the foundation for the implementation phase.

3. Interface construction and implementation: The implementation activity begins

with the creation of prototype (model) that enables usage scenarios to be evaluated.
As iterative design process continues a User Interface toolkit that allows the creation
of windows, menus, device interaction, error messages, commands, and many other
elements of an interactive environment can be used for completing the construction
of an interface.

4. Interface Validation: This phase focuses on testing the interface. The interface
should be in such a way that it should be able to perform tasks correctly and it should
be able to handle a variety of tasks. It should achieve all the user’s requirements. It
should be easy to use and easy to learn. Users should accept the interface as a useful
one in their work.

Golden Rules:

22
The following are the golden rules stated by Theo Mandel that must be followed during the
design of the interface.
1. Place the user in control:

 Define the interaction modes in such a way that does not force the user into
unnecessary or undesired actions: The user should be able to easily enter and exit the
mode with little or no effort.

 Provide for flexible interaction: Different people will use different interaction
mechanisms, some might use keyboard commands, some might use mouse, some
might use touch screen, etc, Hence all interaction mechanisms should be provided.

 Allow user interaction to be interruptable and undoable: When a user is doing a

sequence of actions the user must be able to interrupt the sequence to do some other
work without losing the work that had been done. The user should also be able to do
undo operation.

 Streamline interaction as skill level advances and allow the interaction to be

customized: Advanced or highly skilled user should be provided a chance to
customize the interface as user wants which allows different interaction mechanisms
so that user doesn’t feel bored while using the same interaction mechanism.

 Hide technical internals from casual users: The user should not be aware of the
internal technical details of the system. He should interact with the interface just to
do his work.

 Design for direct interaction with objects that appear on screen: The user should be
able to use the objects and manipulate the objects that are present on the screen to
perform a necessary task. By this, the user feels easy to control over the screen.

2. Reduce the user’s memory load:

 Reduce demand on short-term memory: When users are involved in some complex
tasks the demand on short-term memory is significant. So the interface should be
designed in such a way to reduce the remembering of previously done actions, given
inputs and results.

 Establish meaningful defaults: Always initial set of defaults should be provided to

the average user, if a user needs to add some new features then he should be able to
add the required features.

 Define shortcuts that are intuitive: Mnemonics should be used by the user.
Mnemonics means the keyboard shortcuts to do some action on the screen.
23
  The visual layout of the interface should be based on a real-world metaphor:
Anything you represent on a screen if it is a metaphor for real-world entity then users
would easily understand.
 Disclose information in a progressive fashion: The interface should be organized
hierarchically i.e. on the main screen the information about the task, an object or
some behavior should be presented first at a high level of abstraction. More detail
should be presented after the user indicates interest with a mouse pick.

3 .Make the interface consistent:

 Allow the user to put the current task into a meaningful context: Many interfaces
have dozens of screens. So it is important to provide indicators consistently so that
the user know about the doing work. The user should also know from which page
has navigated to the current page and from the current page where can navigate.

 Maintain consistency across a family of applications: The development of some set

of applications all should follow and implement the same design, rules so that
consistency is maintained among applications.

 If past interactive models have created user expectations do not make changes unless
there is a compelling reason.

24
Object Oriented Design

In the object-oriented design method, the design works around the entities and their
characteristics instead of functions involved in the software system. This design strategy focuses
on entities and its characteristics. The whole concept of software solution revolves around the
engaged entities. the system is viewed as a collection of objects (i.e., entities). The state is
distributed among the objects, and each object handles its state data. For example, in a Library
Automation Software, each library representative may be a separate object with its data and
functions to operate on these data. The tasks defined for one purpose cannot refer or change data
of other objects. Objects have their internal data which represent their state. Similar objects
create a class. In other words, each object is a member of some class. Classes may inherit
features from the super class.

The different terms related to object design are

:
1. Objects: All entities involved in the solution design are known as objects. For example,
person, banks, company, and users are considered as objects. Every entity has some
attributes associated with it and has some methods to perform on the attributes.
2. Classes: A class is a generalized description of an object. An object is an instance of a
class. A class defines all the attributes, which an object can have and methods, which
represents the functionality of the object.
3. Messages: Objects communicate by message passing. Messages consist of the integrity of
the target object, the name of the requested operation, and any other action needed to
perform the function. Messages are often implemented as procedure or function calls.
4. Abstraction In object-oriented design, complexity is handled using abstraction.
Abstraction is the removal of the irrelevant and the amplification of the essentials.
5. Encapsulation: Encapsulation is also called an information hiding concept. The data and
operations are linked to a single unit. Encapsulation not only bundles essential
information of an object together but also restricts access to the data and methods from
the outside world.
6. Inheritance: OOD allows similar classes to stack up in a hierarchical manner where the
lower or sub-classes can import, implement, and re-use allowed variables and functions
from their immediate super classes. This property of OOD is called an inheritance. This
makes it easier to define a specific class and to create generalized classes from specific
ones.
7. Polymorphism: OOD languages provide a mechanism where methods performing similar
tasks but vary in arguments, can be assigned the same name. This is known as
polymorphism, which allows a single interface is performing functions for different
types. Depending upon how the service is invoked, the respective portion of the code gets
executed.

25
In OOD, the technology-independent concepts in the analysis model are mapped onto
implementing classes, constraints are identified, and interfaces are designed, resulting in a
model for the solution domain. In a nutshell, a detailed description is constructed
specifying how the system is to be built on concrete technologies
The stages for object–oriented design can be identified as −

 Definition of the context of the system

 Designing system architecture
 Identification of the objects in the system
 Construction of design models
 Specification of object interfaces

System Design

Object-oriented system design involves defining the context of a system followed by designing
the architecture of the system.
 Context − The context of a system has a static and a dynamic part. The static context of
the system is designed using a simple block diagram of the whole system which is
expanded into a hierarchy of subsystems. The subsystem model is represented by UML
packages. The dynamic context describes how the system interacts with its environment.
It is modelled using use case diagrams.
 System Architecture − The system architecture is designed on the basis of the context
of the system in accordance with the principles of architectural design as well as domain
knowledge. Typically, a system is partitioned into layers and each layer is decomposed
to form the subsystems.

Object-Oriented Decomposition

Decomposition means dividing a large complex system into a hierarchy of smaller components
with lesser complexities, on the principles of divide–and–conquer. Each major component of
the system is called a subsystem. Object-oriented decomposition identifies individual
autonomous objects in a system and the communication among these objects.
The advantages of decomposition are −
 The individual components are of lesser complexity, and so more understandable and
manageable.
 It enables division of workforce having specialized skills.
 It allows subsystems to be replaced or modified without affecting other subsystems.

Identifying Concurrency
26
Concurrency allows more than one objects to receive events at the same time and more than one
activity to be executed simultaneously. Concurrency is identified and represented in the
dynamic model.
To enable concurrency, each concurrent element is assigned a separate thread of control. If the
concurrency is at object level, then two concurrent objects are assigned two different threads of
control. If two operations of a single object are concurrent in nature, then that object is split
among different threads.
Concurrency is associated with the problems of data integrity, deadlock, and starvation. So a
clear strategy needs to be made whenever concurrency is required. Besides, concurrency
requires to be identified at the design stage itself, and cannot be left for implementation stage.

Identifying Patterns

While designing applications, some commonly accepted solutions are adopted for some
categories of problems. These are the patterns of design. A pattern can be defined as a
documented set of building blocks that can be used in certain types of application development
problems.
Some commonly used design patterns are −

 Façade pattern
 Model view separation pattern
 Observer pattern
 Model view controller pattern
 Publish subscribe pattern
 Proxy pattern

Controlling Events

During system design, the events that may occur in the objects of the system need to be
identified and appropriately dealt with.
An event is a specification of a significant occurrence that has a location in time and space.
There are four types of events that can be modelled, namely −
 Signal Event − A named object thrown by one object and caught by another object.
 Call Event − A synchronous event representing dispatch of an operation.
 Time Event − An event representing passage of time.
 Change Event − An event representing change in state.

27
Handling Boundary Conditions

The system design phase needs to address the initialization and the termination of the system as
a whole as well as each subsystem. The different aspects that are documented are as follows −
 The start–up of the system, i.e., the transition of the system from non-initialized state to
steady state.
 The termination of the system, i.e., the closing of all running threads, cleaning up of
resources, and the messages to be sent.
 The initial configuration of the system and the reconfiguration of the system when
needed.
 Foreseeing failures or undesired termination of the system.
Boundary conditions are modelled using boundary use cases.

Object Design

After the hierarchy of subsystems has been developed, the objects in the system are identified
and their details are designed. Here, the designer details out the strategy chosen during the
system design. The emphasis shifts from application domain concepts toward computer
concepts. The objects identified during analysis are etched out for implementation with an aim
to minimize execution time, memory consumption, and overall cost.
Object design includes the following phases −

 Object identification
 Object representation, i.e., construction of design models
 Classification of operations
 Algorithm design
 Design of relationships
 Implementation of control for external interactions
 Package classes and associations into modules

Object Identification
The first step of object design is object identification. The objects identified in the object–
oriented analysis phases are grouped into classes and refined so that they are suitable for actual
implementation.
The functions of this stage are −
 Identifying and refining the classes in each subsystem or package

28
  Defining the links and associations between the classes
 Designing the hierarchical associations among the classes, i.e., the
generalization/specialization and inheritances
 Designing aggregations

Object Representation
Once the classes are identified, they need to be represented using object modelling techniques.
This stage essentially involves constructing UML diagrams.
There are two types of design models that need to be produced −
 Static Models − To describe the static structure of a system using class diagrams and
object diagrams.
 Dynamic Models − To describe the dynamic structure of a system and show the
interaction between classes using interaction diagrams and state–chart diagrams.

Classification of Operations
In this step, the operation to be performed on objects are defined by combining the three models
developed in the OOA phase, namely, object model, dynamic model, and functional model. An
operation specifies what is to be done and not how it should be done.
The following tasks are performed regarding operations −
 The state transition diagram of each object in the system is developed.
 Operations are defined for the events received by the objects.
 Cases in which one event triggers other events in same or different objects are identified.
 The sub–operations within the actions are identified.
 The main actions are expanded to data flow diagrams.

Algorithm Design
The operations in the objects are defined using algorithms. An algorithm is a stepwise
procedure that solves the problem laid down in an operation. Algorithms focus on how it is to
be done.
There may be more than one algorithm corresponding to a given operation. Once the alternative
algorithms are identified, the optimal algorithm is selected for the given problem domain. The
metrics for choosing the optimal algorithm are −
 Computational Complexity − Complexity determines the efficiency of an algorithm in
terms of computation time and memory requirements.
 Flexibility − Flexibility determines whether the chosen algorithm can be implemented
suitably, without loss of appropriateness in various environments.

29
  Understandability − This determines whether the chosen algorithm is easy to
understand and implement.

Design of Relationships
The strategy to implement the relationships needs to be chalked out during the object design
phase. The main relationships that are addressed comprise of associations, aggregations, and
inheritances.
The designer should do the following regarding associations −
 Identify whether an association is unidirectional or bidirectional.
 Analyze the path of associations and update them if necessary.
 Implement the associations as a distinct object, in case of many–to-many relationships;
or as a link to other object in case of one–to-one or one–to-many relationships.
Regarding inheritances, the designer should do the following −
 Adjust the classes and their associations.
 Identify abstract classes.
 Make provisions so that behaviors are shared when needed.

Implementation of Control
The object designer may incorporate refinements in the strategy of the state–chart model. In
system design, a basic strategy for realizing the dynamic model is made. During object design,
this strategy is aptly embellished for appropriate implementation.
The approaches for implementation of the dynamic model are −
 Represent State as a Location within a Program − This is the traditional procedure-
driven approach whereby the location of control defines the program state. A finite state
machine can be implemented as a program. A transition forms an input statement, the
main control path forms the sequence of instructions, the branches form the conditions,
and the backward paths form the loops or iterations.
 State Machine Engine − This approach directly represents a state machine through a
state machine engine class. This class executes the state machine through a set of
transitions and actions provided by the application.
 Control as Concurrent Tasks − In this approach, an object is implemented as a task in
the programming language or the operating system. Here, an event is implemented as an
inter-task call. It preserves inherent concurrency of real objects.

Packaging Classes

30
In any large project, meticulous partitioning of an implementation into modules or packages is
important. During object design, classes and objects are grouped into packages to enable
multiple groups to work cooperatively on a project.
The different aspects of packaging are −
 Hiding Internal Information from Outside View − It allows a class to be viewed as a
“black box” and permits class implementation to be changed without requiring any
clients of the class to modify code.
 Coherence of Elements − An element, such as a class, an operation, or a module, is
coherent if it is organized on a consistent plan and all its parts are intrinsically related so
that they serve a common goal.
 Construction of Physical Modules − The following guidelines help while constructing
physical modules −
o Classes in a module should represent similar things or components in the same
composite object.
o Closely connected classes should be in the same module.
o Unconnected or weakly connected classes should be placed in separate modules.
o Modules should have good cohesion, i.e., high cooperation among its
components.
o A module should have low coupling with other modules, i.e., interaction or
interdependence between modules should be minimum.

Design Optimization

The analysis model captures the logical information about the system, while the design model
adds details to support efficient information access. Before a design is implemented, it should
be optimized so as to make the implementation more efficient. The aim of optimization is to
minimize the cost in terms of time, space, and other metrics.
However, design optimization should not be excess, as ease of implementation, maintainability,
and extensibility are also important concerns. It is often seen that a perfectly optimized design is
more efficient but less readable and reusable. So the designer must strike a balance between the
two.
The various things that may be done for design optimization are −

 Add redundant associations

 Omit non-usable associations
 Optimization of algorithms
 Save derived attributes to avoid re-computation of complex expressions

31
Addition of Redundant Associations
During design optimization, it is checked if deriving new associations can reduce access costs.
Though these redundant associations may not add any information, they may increase the
efficiency of the overall model.

Omission of Non-Usable Associations

Presence of too many associations may render a system indecipherable and hence reduce the
overall efficiency of the system. So, during optimization, all non-usable associations are
removed.

Optimization of Algorithms
In object-oriented systems, optimization of data structure and algorithms are done in a
collaborative manner. Once the class design is in place, the operations and the algorithms need
to be optimized.
Optimization of algorithms is obtained by −

 Rearrangement of the order of computational tasks

 Reversal of execution order of loops from that laid down in the functional model
 Removal of dead paths within the algorithm

Saving and Storing of Derived Attributes

Derived attributes are those attributes whose values are computed as a function of other
attributes (base attributes). Re-computation of the values of derived attributes every time they
are needed is a time–consuming procedure. To avoid this, the values can be computed and
stored in their computed forms.
However, this may pose update anomalies, i.e., a change in the values of base attributes with no
corresponding change in the values of the derived attributes. To avoid this, the following steps
are taken −
 With each update of the base attribute value, the derived attribute is also re-computed.
 All the derived attributes are re-computed and updated periodically in a group rather than
after each update.

Design Documentation

Documentation is an essential part of any software development process that records the
procedure of making the software. The design decisions need to be documented for any non–
trivial software system for transmitting the design to others.

32
Usage Areas
Though a secondary product, a good documentation is indispensable, particularly in the
following areas −

 In designing software that is being developed by a number of developers

 In iterative software development strategies
 In developing subsequent versions of a software project
 For evaluating a software
 For finding conditions and areas of testing
 For maintenance of the software.

Contents
A beneficial documentation should essentially include the following contents −
 High–level system architecture − Process diagrams and module diagrams
 Key abstractions and mechanisms − Class diagrams and object diagrams.
 Scenarios that illustrate the behavior of the main aspects − Behavioural diagrams

Features
The features of a good documentation are −
 Concise and at the same time, unambiguous, consistent, and complete
 Traceable to the system’s requirement specifications
 Well-structured
 Diagrammatic instead of descriptive

33
 Software Design Notations

Design notations are used when planning and should be able to communicate the purpose of a
program without the need for formal code. Commonly used design notations are:

 Pseudocode
 Flow charts
 Structure chart

Pseudo code
When designing a program, it is useful to lay out how the program might work, before writing it
in a programming language,.
Pseudo code is a design notation that is closely related to the logic of how a program will work.
It lets you detail what your program will do without having to worry about the particular syntax
of your chosen programming language.
There is no specific standard for pseudo code and programmers often have their own version.
Pseudo code can look a lot like code but it does not need to be implemented as strictly.
Programming languages like python, reference language (used by the SQA) and visual basic will
have specific rules around syntax and structure, whereas pseudo code gives more freedom.
There is no strict set of rules for pseudo code, but some of the most widely recognized are:

 INPUT – indicates a user will be inputting something

 OUTPUT – indicates that an output will appear on the screen
 WHILE – a loop (iteration that has a condition at the beginning)
 FOR – a counting loop (iteration)
 REPEAT – UNTIL – a loop (iteration) that has a condition at the end
 IF – THEN – ELSE – a decision (selection) in which a choice is made

Pseudo code can be used to plan out programs. It is similar to actual code. Planning a program
that asks people what their favorite subject is could look like this in pseudo code:
REPEAT

34
 OUTPUT 'What is the best subject you take?'
INPUT user inputs the best subject they take
STORE the user's input in the answer variable
IF answer = 'Computer Science' THEN
OUTPUT 'Of course it is!'
ELSE
OUTPUT 'Try again!
'UNTIL answer = 'Computer Science'

A programmer who uses pseudo code as part of their planning is able to take time to think about
how their program will work, what variables they might need and what inputs and outputs there
are.

Flow charts

Flow charts show what is going on in a program and how data flows around it. Flow charts can
represent everyday processes, show decisions taken and the result of these decisions.

The diamond shape explains when there is a choice to make. The flow chart shows what happens
depending on the decision made at this point. Flow charts visualise the results of decisions,
showing what will happen in a program, and also when, for example an if statement, is required
to make a decision. Flow charts can be used to show iteration (repeating something).

35
In the above flow chart, the user is asked what their favourite subject is. If they answer
'Computing Science' they are told they are 'clearly very intelligent' and the program stops.
Any other answer results in the user being asked again. If the user does not enter 'Computing
Science', the program will keep going round and round, asking them forever until they enter
Computing Science.
Structure diagrams

Structure diagrams break down a problem into smaller sections. These smaller sections can then
be worked on one at a time. This can be good for big projects where a large problem can be split
into smaller tasks for separate groups, or individuals, to work on. Below is an example of how a
structure diagram might be used to break a large problem down.

1.

This shows how you can take a complex problem and start breaking it down into more
manageable chunks. In reality, a complex project like building a house would have many more
stages, but this example shows that structure diagrams can help to break down problems when
designing a program. You would most likely use a structure diagram if you were designing a
game and wanted to break down the overall design problem into individual elements.
36
37