UNIT-III

Software Design: Overview of the design process, how to characterize a good software
design? Layered arrangement of modules, Cohesion and Coupling. approaches to
software design.
Agility: Agility and the Cost of Change, Agile Process, Extreme Programming (XP), Other
Agile Process Models, Tool Set for the Agile Process (Text Book 2)
Function-Oriented Software Design: Overview of SA/SD methodology, Structured
analysis, Developing the DFD model of a system, Structured design, Detailed design, and
Design Review.
User Interface Design: Characteristics of a good user interface, Basic concepts, Types of
user interfaces, Fundamentals of component-based GUI development, and user interface
design methodology.

Overview of design process

The design process essentially transforms the SRS document into a design document.There
are two fundamentally different approaches to software design that are in use today—
function-oriented design, and object-oriented design. Though these two design
approaches are radically different, they are complementary rather than competing
techniques. The objectoriented approach is a relatively newer technology and it is still
evolving.

Function-oriented
The following are the salient features of the function-oriented design approach:
Top-down decomposition: A system, to start with, is viewed as a black box that provides
certain services (also known as high-level functions) to the users of the system. In top-
down decomposition, starting at a high-level view of the system, each high-level 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 high-level function may be refined into the following
subfunctions:
• assign-membership-number
• create-member-record
• print-bill
Centralised system state: The system state can be defined as the values of certain data
items that determine the response of the system to a user action or external event.
For example, the set of books (i.e. whether borrowed by different users or available for
issue) determines the state of a library automation system. Such data in procedural
programs usually have global scope and are shared by many modules. The system state is
centralised and shared among different functions.
For example, in the library management system, several functions such as the following
share data such as member-records for reference and updation:
• create-new-member
• delete-member
• update-member-record

Object-oriented Design
In the object-oriented design (OOD) approach, a system is viewed as being made up of a
collection of objects (i.e. entities). Each object is associated with a set of functions that are
called its methods. Each object contains its own data and is responsible for managing it.
The data internal to an object cannot be accessed directly by other objects and only
through invocation of the methods of the object.
ADT is an important concept that forms an important pillar of objectorientation. Let us
now discuss the important concepts behind an ADT. There are, in fact, three important
concepts associated with an ADT—data abstraction, data structure, data type.
Data abstraction:
The principle of data abstraction implies that how data is exactly stored is abstracted
away. This means that any entity external to the object (that is, an instance of an ADT)
would have no knowledge about how data is exactly stored, organised, and manipulated
inside the object. The entities external to the object can access the data internal to an
object only by calling certain well-defined methods supported by the object. Consider an
ADT such as a stack. The data of a stack object may internally be stored in an array, a
linearly linked list, or a bidirectional linked list. The external entities have no knowledge of
this and can access data of a stack object only through the supported operations such as
push and pop.
Data structure: A data structure is constructed from a collection of primitive data items.
Just as a civil engineer builds a large civil engineering structure using primitive building
materials such as bricks, iron rods, and cement; a programmer can construct a data
structure as an organised collection of primitive data items such as integer, floating point
numbers, characters, etc.
Data type: A type is a programming language terminology that refers to anything that can
be instantiated. For example, int, float, char etc., are the basic data types supported by C
programming language. Thus, we can say that ADTs are user defined data types. what is
the advantage of developing an application using ADTs?
Let us examine the three main advantages of using ADTs in programs:
1. The data of objects are encapsulated within the methods. The encapsulation
principle is also known as data hiding. The encapsulation principle requires that
data can be accessed and manipulated only through the methods supported by the
object and not directly.
2. An ADT-based design displays high cohesion and low coupling. Therefore, object-
oriented designs are highly modular.
3. Since the principle of abstraction is used, it makes the design solution easily
understandable and helps to manage complexity.

characterize the good software design

most researchers and software engineers agree on a few desirable characteristics
that every good software design for general applications must possess. These
characteristics are listed below:
Correctness: A good design should first of all be correct. That is, it should correctly
implement all the functionalities of the system.
Understandability: A good design should be easily understandable. Unless a design
solution is easily understandable, it would be difficult to implement and maintain it.
Efficiency: A good design solution should adequately address resource, time, and
cost optimisation issues.
Maintainability: A good design should be easy to change. This is an important
requirement, since change requests usually keep coming from the customer even
after product release
These two principles are exploited by design methodologies to make a design
modular and layered. We can now define the characteristics of an easily
understandable design as follows: A design solution is understandable, if it is
modular and the modules are arranged in distinct layers. A design solution should
be modular and layered to be understandable.

Modularity
A modular design is an effective decomposition of a problem. It is a basic
characteristic of any good design solution. A modular design, in simple words,
implies that the problem has been decomposed into a set of modules that have
only limited interactions with each other. Decomposition of a problem into modules
facilitates taking advantage of the divide and conquer principle. If different modules
have either no interactions or little interactions with each other, then each module
can be understood separately. This reduces the perceived complexity of the design
solution greatly.
For example, consider two alternate design solutions to a problem that are
represented in Figure 5.2, in which the modules M1 , M2 etc. have been drawn as
rectangles. The invocation of a module by another module has been shown as an
 arrow. It can easily be seen that the design solution of Figure 5.2(a) would be easier
to understand since the interactions among the different modules is low.

Layered design

A layered design is one in which when the call relations among different modules are
represented graphically, it would result in a tree-like diagram with clear layering. In a
layered design solution, the modules are arranged in a hierarchy of layers. A module can
only invoke functions of the modules in the layer immediately below it. The higher layer
modules can be considered to be similar to managers that invoke (order) the lower layer
modules to get certain tasks done. A layered design can be considered to be implementing
control abstraction, since a module at a lower layer is unaware of (about how to call) the
higher layer modules. A layered design can make the design solution easily
understandable, since to understand the working of a module, one would at best have to
understand how the immediately lower layer modules work without having to worry
about the functioning of the upper layer modules. When a failure is detected while
executing a module, it is obvious that the modules below it can possibly be the source of
the error
cohesion method
Cohesion is a measure of the functional strength of a module,If the functions of the
module do very different things and do not co-operate with each other to perform a single
piece of work, then the module has very poor cohesion.
Functional independence
By the term functional independence, we mean that a module performs a single task and
needs very little interaction with other modules. A module that is highly cohesive and also
has low coupling with other modules is said to be functionally independent of the other
modules. Functional independence is a key to any good design primarily due to the
following advantages it offers:
 Error isolation: Whenever an error exists in a module, functional independence reduces
the chances of the error propagating to the other modules. The reason behind this is that
if a module is functionally independent, its interaction with other modules is low.
Therefore, an error existing in the module is very unlikely to affect the functioning of other
modules. Further, once a failure is detected, error isolation makes it very easy to locate the
error.
Scope of reuse: Reuse of a module for the development of other applications becomes
easier. The reasons for this is as follows. A functionally independent module performs
some well-defined and precise task and the interfaces of the module with other modules
are very few and simple. A functionally independent module can therefore be easily taken
out and reused in a different program.
Understandability: When modules are functionally independent, complexity of the design
is greatly reduced. This is because of the fact that different modules can be understood in
isolation, since the modules are independent of each other.

Classification of Cohesiveness
Cohesiveness of a module is the degree to which the different functions of the module co-
operate to work towards a single objective.The different classes of cohesion are elaborated
below.

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, we can say that the
module contains a random collection of functions.
An example of a module with coincidental cohesionhas been shown in Figure
5.4(a).Observe that the different functions of the module carry out very different and
unrelated activities starting from issuing of library books to creating library member
records on one hand, and handling librarian leave request on the other
Logical cohesion: A module is said to be logically cohesive, if all elements of the module
perform similar operations, such as error handling, data input, data output, etc. As an
example of logical cohesion, consider a module that contains a set of print functions to
generate various types of output reports such as grade sheets, salary slips, annual reports,
etc.
Temporal cohesion: When a module contains functions that are related by the fact that
these functions are executed in the same time span, then the module is said to possess
temporal cohesion. As an example, consider the following situation. When a computer is
booted, several functions need to be performed. These include initialisation of memory
and devices, loading the operating system, etc

Procedural cohesion: A module is said to possess procedural cohesion, if the set of

functions of the module are executed one after the other, though these functions may
work towards entirely different purposes and operate on very different data. Consider the
activities associated with order processing in a trading house. The functions login(), place-
order(), check-order(), printbill(), place-order-on-vendor(), update-inventory(), and
logout() all do different thing and operate on different data.

Communicational cohesion: A module is said to have communicational cohesion, if all

functions of the module refer to or update the same data structure. As an example of
procedural cohesion, consider a module named student in which the different functions in
the module such as admitStudent, enterMarks, printGradeSheet, etc. access and
manipulate data stored in an array named studentRecords defined within the module.
Sequential cohesion: A module is said to possess sequential cohesion, if the different
functions of the module execute in a sequence, and the output from one function is input
to the next in the sequence. As an example consider the following situation. In an on-line
store consider that after a customer requests for some item, it is first determined if the
item is in stock. In this case, if the functions create-order(), check-item-availability(),
placeorder-on-vendor() are placed in a single module
Functional cohesion: A module is said to possess functional cohesion, if different functions
of the module co-operate to complete a single task. For example, a module containing all
the functions required to manage employees’ pay-roll displays functional cohesion. In this
case, all the functions of the module (e.g., computeOvertime(), computeWorkHours(),
computeDeductions(), etc.) work together to generate the payslips of the employees.

coupling method
Classification of Coupling The coupling between two modules indicates the degree of
interdependence between them. Intuitively, if two modules interchange large amounts of
data, then they are highly interdependent or coupled. The interface complexity is
determined based on the number of parameters and the complexity of the parameters
that are interchanged while one module invokes the functions of the other module.

These different types of coupling,

Data coupling: Two modules are data coupled, if they communicate using an
elementary data item that is passed as a parameter between the two, e.g. an integer, a
float, a character, etc. This data item should be problem related and not used for control
purposes.

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 instruction 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 some global data
items.
Content coupling: Content coupling exists between two modules, if they share code. That
is, a jump from one module into the code of another module can occur. Modern high-level
programming languages such as C do not support such jumps across modules.
Approachs to Software Design
There are two fundamentally different approaches to software design that are in use today
— function-oriented design, and object-oriented design
Function-oriented Design:
The following are the salient features of the function-oriented design approach:
Top-down decomposition: A system, to start with, is viewed as a black box that provides
certain services to the users of the system. In top-down decomposition, starting at a high-
level view of the system, each high-level function is successively refined into more detailed
functions. For example, consider a function create-new-library me mbe r 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 high-level function may be refined into
the following subfunctions: • assign-membership-number • create-member-record •
print-bill
Centralised system state: The system state can be defined as the values of certain data
items that determine the response of the system to a user action or external event. For
example, the set of books (i.e. whether borrowed by different users or available for issue)
determines the state of a library automation system. Such data in procedural programs
usually have global scope and are shared by many modules. The system state is centralised
and shared among different functions. For example, in the library management system,
several functions such as the following share data such as member-records for reference
and updation: • create-new-member • delete-member • update-member-record

Object-oriented Design
In the object-oriented design (OOD) approach, a system is viewed as being made up of a
collection of objects (i.e. entities). Each object is associated with a set of functions that are
called its methods. Each object contains its own data and is responsible for managing it.
The data internal to an object cannot be accessed directly by other objects and only
through invocation of the methods of the object. The system state is decentralised since
there is no globally shared data in the system and data is stored in each object. Objects
can also be considered as instances of abstract data types (ADTs) There are, in fact, three
important concepts associated with an ADT—data abstraction, data structure, data type
Data abstraction: The principle of data abstraction implies that how data is exactly stored
is abstracted away. This means that any entity external to the object (that is, an instance of
an ADT) would have no knowledge about how data is exactly stored, organised, and
manipulated inside the object. The entities external to the object can access the data
internal to an object only by calling certain well-defined methods supported by the object.

Data structure: A data structure is constructed from a collection of primitive data items.
Just as a civil engineer builds a large civil engineering structure using primitive building
materials such as bricks, iron rods, and cement; a programmer can construct a data
structure as an organised collection of primitive data items such as integer, floating point
numbers, characters, etc.
Data type: A type is a programming language terminology that refers to anything that can
be instantiated. For example, int, float, char etc., are the basic data types supported by C
programming language. Thus, we can say that ADTs are user defined data types. In object-
orientation, classes are AD
Automated fire-alarm system—customer requirements
The owner of a large multi-storied building wants to have a computerised fire alarm
system designed, developed, and installed in his building. Smoke detectors and fire alarms
would be placed in each room of the building. The fire alarm system would monitor the
status of these smoke detectors. Whenever a fire condition is reported by any of the
smoke detectors, the fire alarm system should determine the location at which the fire has
been sensed and then sound the alarms only in the neighbouring locations. The fire alarm
system should also flash an alarm message on the computer console. Fire fighting
personnel would man the console round the clock. After a fire condition has been
successfully handled, the fire alarm system should support resetting the alarms by the fire
fighting personnel.
Function-oriented approach: In this approach, the different high-level functions are first
identified, and then the data structures are designed.

The functions which operate on the system state are: interrogate_detectors();

get_detector_location(); determine_neighbour_alarm();
determine_neighbour_sprinkler(); ring_alarm(); activate_sprinkler(); reset_alarm();
reset_sprinkler(); report_fire_location();
Object-oriented approach: In the object-oriented approach, the different classes of
objects are identified. Subsequently, the methods and data for each object are identified.
Finally, an appropriate number of instances of each class is created.
class detector attributes: status, location, neighbours
operations: create, sense-status, get-location, find-neighbours
class alarm attributes: location, status
operations: create, ring-alarm, get_location, resetalarm
class sprinkler attributes: location, status
operations: create, activate-sprinkler, get_location, reset-sprinkler

Agility:
 Agility means effective (rapid and adaptive) response to change, effective
communication among all stakekholder.
 Drawing the customer onto team and organizing a team so that it is in
control of work performed. The Agile process is light-weight methods and
People-based rather than plan-based methods.
 The agile process forces the development team to focus on software itself
rather than design and documentation.
 The agile process believes in iterative method.
 The aim of agile process is to deliver the working model of software quickly
to the customer For example: Extreme programming is the best known of
agile process.

AGILITY AND THE COST OF CHANGE

The cost of change increases as the project progresses.(Figure 3.1, solid black curve).
It is relatively easy to accommodate a change when a software team is gathering
requirements (early in a project).
 The team is in the middle of validation testing (something that occurs relatively
late in the project), and stakeholder is requesting a major functional change. The change
requires a modification to the architectural design of the software, the design and
construction of three new components, modifications to another five components, the
design of new tests, and so on. Costs and time increases quickly.
A well-designed agile process “flattens” the cost of change curve (Figure 3.1, shaded,
solid curve), allowing a software team to accommodate changes late in a software project
without cost and time impact. the agile process encompasses incremental delivery.
What is an Agile Process:
Any agile software process is characterized in a manner that addresses a number of key
assumptions about the majority of software projects:

1. It is difficult to predict(estimate for future change) in advance which software

requirements will persist and which will change.
2. For many types of software, design and construction are performed
simultaneously. It is difficult to predict how much design is necessary before
construction is used to prove the design.
3. Analysis, design, construction, and testing are not expected. (from a
planning point of view)
Agility Principles
12 agility principles for those who want to achieve agility:
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of
Months.
4. stake holders and software engineers must work together daily throughout the
project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.
9. Continuous attention to technical excellence and good design
enhances(increases)agility.
10. Simplicity—the art of maximizing the amount of work not done—is
essential.
11. The best architectures, requirements, and designs emerge from self–
organizing teams.
12. At regular intervals, the team reflects on how to become more effective and
then adjusts its behavior accordingly.
Not every agile process model applies these 12 principles with equal weight, and some
models choose to ignore (or at least downplay) the importance of one or more of the
principles.
The Politics of Agile Development
 There is debate about the benefits and applicabilityof agile software
development as opposed to more conventional software engineering
processes(produces documents rather than working product).
 Even within the agile, there are many proposed process models each with a
different approach to the agility .
Human Factors
Agile software development take the importance of “people factors”. Number of different
talents must exist among the people on an agile team and the team itself:
Competence:“competence” encompasses talent, specific software-related skills,
and overall knowledge of the process .
Common focus: Members of the agile team may perform different
tasks and all should be focused on one goal—to deliver a working software increment to the
customer within the time promised.
Collaboration: Team members must collaborate with one another and all other
Stakeholders to complete the their task.
Decision-making ability: Any good software team (including agile teams) must
be allowed the freedom to control its own destiny.
Fuzzy problem-solving ability: The agile team will continually have to deal with
ambiguities(confusions or doubts).
Mutual trust and respect: The agile team exhibits the trust and respect .
Self-organization:
(1) the agile team organizes itself for the work to be done
(2) the team organizes the process to best accommodate its local environment
(3) the team organizes the work schedule to best achieve delivery of the software
increment.
Extreme Programming:
Extreme Programming (XP), the most widely used approach to agile software development.
XP proposed by kent beck during the late 1980’s.
XP Values
Beck defines a set of five values —communication, simplicity, feedback, courage, and
respect. Each of these values is used in XP activities, actions, and tasks.
 Effective communication between software engineers and
other stakeholders .
 . To achieve simplicity, XP restricts developers to design only for immediate
needs, rather than future needs.
 Feedback is derived from three sources: the implemented software itself,
the customer, and other software team members
 courage.(discipline) An agile XP team must have the discipline (courage) to
design for today, recognizing that future requirements may change
dramatically.
 the agile team inculcates respect among it members, between other
stakeholders and team members.
The XP(Extreme Programming) Process
XP Process have four framework activities: planning, design, coding, and testing.

Planning. The planning activity begins with listening—a requirements gathering

activity.
 Listening leads to the creation of a set of “stories” (also called user stories)
that describe required output, features, and functionality for software to be
built.
  Each story is written by the customer and is placed on an index card.The
customer assigns a value (i.e., a priority) to the story based on the overall
business value of the feature or function.
 Members of the XP team then assess each story and assign a cost—
measured in development weeks—to it.
 If the story is estimated to require more than three development
weeks,the story into smaller stories and the assignment of value and cost
occurs again. It is important to note that new stories can be written at any
time.
 the stories with highest value will be moved up in the schedule and
implemented first.

Design: XP design follows the KIS (keep it simple) principle.

 If a difficult design problem is encountered as part of the design of a story,
XP recommends the immediate creation of an operational prototype of
that portion of the design. Called a spike solution.
 XP encourages refactoring—a construction technique that is also a method
for design optimization.
 Refactoring is the process of changing a software system in a way that it
does not change the external behavior of the code and improves the
internal structure.
 Coding:design work is done, the team does not move to code, develops a series of unit tests
for each of the stories that is to be included in the current release (software increment).
 Once the unit test has been created, the developer is better able to focus
on what must be implemented to pass the test.
 Once the code is complete, it can be unit-tested immediately,and providing
feedback to the developers.
 A key concept during the coding activity is pair programming. i.e..,two
people work together at one computer workstation to create code for a
story.
 As pair programmers complete their work, the code they develop is
integrated with the work of others.
Testing:
 As the individual unit tests are organized into a “universal testing suite”
integration and validation testing of the system can occur on a daily basis.
 XP acceptance tests, also called customer tests, are specified by the
customer and focus on overall system features and functionality.
Acceptance tests are derived from user stories that have been
implemented as part of a software release.
Industrial XP
Joshua Kerievsky describes Industrial Extreme Programming (IXP)
IXP has six new practices that are designed to help XP process works successfully for
projects within a large organization.
Readiness assessment. the organization should conduct a readiness assessment.
(1) Development environment exists to support IXP(Industrial Extreme
Programming).
(2) the team will be populated by the proper set of stakeholders.
(3) the organization has a distinct quality program and supports continuous
improvement.
(4) the organizational culture will support the new values of an agile Team.
Project community.
 Classic XP suggests that the right people be used to populate the agile team
to ensure success.
 The people on the team must be well-trained, adaptable and skilled.
 A community may have a team members and customers who are central to
the success of the project.
Project chartering.:
  Chartering examines the context of the project to determine how it
complements, extends, or replaces existing systems or processes.
Test-driven management.
 Test-driven management establishes a series of measurable “destinations”
and then defines mechanisms for determining whether or not these destinations
have been reached.
Retrospectives.
 An IXP team conducts a specialized technical reviews after a software
increment is delivered. Called a retrospective.
 The review examines “issues, events, and lessons-learned” across a
software increment and/or the entire software release.
Continuous learning.
 learning is a vital part of continuous process improvement, members of the
XP team are encouraged to learn new methods and techniques that can
lead to a higher quality product.
The XP Debate
Requirements volatility. The customer is an active member of the XP team,
changes to requirements are requested informally. As a consequence,
the scope of the project can change and earlier work may have to be modified to
accommodate current needs.
• Conflicting customer needs. Many projects have multiple customers, each with
his own set of needs.
• Requirements are expressed informally. User stories and acceptance tests are
the only explicit manifestation of requirements in XP. specification is often
needed to remove inconsistencies, and errors before the system is built.
• Lack of formal design:when complex systems are built, design must have the
overall structure of the software then it will exihibit quality.

Other Agile Process Models:

The most widely used of all agile process model is Extreme Programming (XP). But many
other agile process models have been proposed and are in use across the industry. Among
the most common are:
• Adaptive Software Development (ASD)
• Scrum
• Dynamic Systems Development Method (DSDM)
• Crystal
• Feature Drive Development (FDD)
• Lean Software Development (LSD)
• Agile Modeling (AM)
• Agile Unified Process (AUP)
Adaptive Software Development (ASD)Adaptive Software Development
(ASD) has been proposed by Jim High smith as a technique for building
complexsystems. ASD focus on human collaboration and team self-
organization.
 ASD “life cycle” (Figure 3.3) has three phases:- speculation, collaboration,
and learning.
 speculation, the project is initiated and adaptive cycle planning is
conducted.Adaptive cycle planning uses project initiation information—the
customer’s statement, project constraints (e.g., delivery dates or user
descriptions), and basic requirements—to define the set of release cycles
(software increments) that will be required for the project.

 Motivated people use collaboration

 People working together must trust one another to (1) without criticize, (2)
work as hard as or harder than they do, (3) have the skill set to contribute
to the work and (4) communicate problems in away that leads to effective
action.
 learning will help them to improve their level of real understanding.
Scrum
 Scrum is an agile software development method that was coined by Jeff
Sutherland and his development team in the early 1990’s.
 Scrum has the following framework activities: requirements, analysis,
design, evolution, and delivery. Within each framework activity, actions and
work tasks occur within a process called a sprint.
  scrum defines a set of development actions:
Backlog—a prioritized list of project requirements or features that provide business value
for the customer. Items can be added to the backlog at any time (this is how changes are
introduced). The product manager assesses the backlog and updates priorities as required.
Sprints—consist of work units that are required to achieve a requirement defined in the
backlog .

Scrum meetings—are short (typically 15 minutes) meetings held daily by the Scrum
team. Three key questions are asked and answered by all team members.
• What did you do since the last team meeting?
• What obstacles are you encountering?
• What do you plan to accomplish by the next team meeting?
A team leader, called a Scrum master, leads the meeting and assesses the responses from
each person.
Demos—deliver the software increment to the customer so that functionality that has been
implemented can be demonstrated and evaluated by the customer.
Dynamic Systems Development Method (DSDM)
 The Dynamic Systems Development Method (DSDM) is an agile software
development approach.
 The DSDM—80 percent of an application can be delivered in 20 percent of
the time it would take to deliver the complete (100 percent) application.
  DSDM is an iterative software process in which each iteration follows the
80 percent rule. That is, only enough work is required for each increment to
facilitate movement to the next increment.
 The remaining detail can be completed later when more business
requirements are known or changes have been requested and
accommodated.
 The activities of DSDM are:
Feasibility study—establishes the basic business requirements and constraints associated
with the application to be built and then assesses whether the application is a viable
candidate for the DSDM process.
Business study—establishes the functional and information requirements that will allow
the application to provide business value.
Functional model iteration—produces a set of incremental prototypes that
demonstrate functionality for the customer.
 The intent during this iterative cycle is to gather additional requirements by
eliciting feedback from users as they exercise the prototype.
Design and build iteration—prototypes built during functional model
iteration to ensure that each has been engineered in a manner that it will provide
operational business value for end users.
Implementation—places the latest software increment (an “operationalized” prototype)
into the operational environment. It should be noted that (1) the increment may not be 100
percent complete or (2) changes may be requested as the increment is put into place.
Crystal
 Alistair Cockburn and Jim Highsmith created the Crystal family of
agile methods .
 Cockburn characterizes as “a resource limited, cooperative game of
invention and communication, with a primary goal of delivering useful,
working software and a secondary goal of setting up for the next game”.
 Cockburn and Highsmith have defined a set of methodologies, each with
core elements that are common to all, and roles,process patterns, work
products, and practice that are unique to each.
 The Crystal family is actually a set of example agile processes that have
been proven effective for different types of projects.
Feature Driven Development (FDD)
 Feature Driven Development (FDD) was originally coined by Peter Coad and
his colleagues as a process model for object-oriented software engineering.
  A feature “is a client-valued function that can be implemented in two
weeks or less”.
 the definition of features provides the following benefits:
 features are small blocks of deliverable functionality, users can
describe them more easily.
 Since a feature is the FDD deliverable software increment, the
team develops operational features every two weeks.
 Because features are small, their design and code representations
are easier.
 the following template for defining a feature:
<action> the <result> <by for of to> a(n) <object>
Where
<object> is “a person, place, or thing.”
Examples of features for an e-commerce application might be:
1) Add the product to shopping cart
2) Store the shipping-information for the customer

 A feature set groups related features into business-related categories and is

defined as:
<action><-ing> a(n) <object>
For example: Making a product sale is a feature set that would encompass the
features noted earlier and others.
 The FDD approach defines five “collaborating” framework activities as
shown in Figure 3.5.
 It is essential for developers, their managers, and other stakeholders to
understand project status.
  For that FDD defines six milestones during the design and implementation
of a feature: “design walkthrough, design, design inspection, code,
code inspection, promote to build”.
Lean Software Development (LSD)
 Lean Software Development (LSD) has adapted the principles of lean
manufacturing to the world of software engineering.
 LSD process can be summarized as eliminate waste, build quality in,
create knowledge, defer commitment, deliver fast, respect people, and
optimize the whole.
 For example,
eliminate waste within the context of an agile software project as 1)adding
no extraneous features or functions
(2) assessing the cost and schedule impact of any newly requested requirement,
(3) removing any superfluous process steps,
(4) establishing mechanisms to improve the way team members find information,
(5) ensuring the testing finds as many errors as possible,
Agile Modeling (AM)
Agile Modeling(AM) suggests a wide array of “core” and “supplementary”
modeling principles,
Model with a purpose. A developer who uses AM should have a specific goal
(e.g., to communicate information to the customer or to help better understand
aspect of the software) in mind before creating the model.
Use multiple models. There are many different models and notations that can be
used to describe software.
 Each model should present a different aspect of the system and only those
models that provide value to their intended audience should be used.
Travel light. As software engineering work proceeds, keep only those models that will
provide long-term value .
Content is more important than representation. Modeling should impart
information to its intended audience.
Know the models and the tools you use to create them. Understand
the strengths and weaknesses of each model and the tools that are used to create it.
Adapt locally. The modeling approach should be adapted to the needs of the agile
team.
Agile Unified Process (AUP)
The Agile Unified Process (AUP) adopts a “serial in the large” and “iterative in the
small” philosophy for building computer-based systems. Each
AUP iteration addresses the following activities:
• Modeling. UML representations of the business and problem domains
are created.
• Implementation. Models are translated into source code.
• Testing. Like XP, the team designs and executes a series of tests to
uncover errors and ensure that the source code meets its requirements.
• Deployment. focuses on the delivery of a software increment and
the acquisition of feedback from end users.
• Configuration and project management.configuration management
addresses change management, risk management,and the control of any
persistent work products that are produced by the team.
Project management tracks and controls the progress of the team and coordinates team
activities.
• Environment management. Environment management coordinates a
process infrastructure that includes standards, tools, and other support
technology available to the team.
A tool set for agile development
 Automated software tools (e.g., design tools) should be viewed as a
minor supplement to the team’s activities, and not to the success of the
team.
 Collaborative and communication “tools” are generally low technology
and incorporate any mechanism(, whiteboards, poster sheets) that
provides information and coordination among agile developers.
 other agile tools are used to optimize the environment in which the agile
team works ,improve the team culture by social interactions, physical
devices (e.g., electronic whiteboards), and process enhancement (e.g.,
pair programming or time-boxing)”
FUNCTION-ORIENTED SOFTWARE DESIGN

The term top-down decomposition i s often used to denote the successive

decomposition of a set of high-level functions into more detailed functions.
After top-down decomposition has been carried out, the different identified
functions are mapped to modules and a module structure is created. This module
structure would possess all the characteristics of a good design The SA/SD
technique can b e used to perform the high-level design of a software.
Structured analysis (SA)
Structured design (SD)
During structured analysis, the SRS document is transformed into a data flow diagram
(DFD) model. During structured design, the DFD model is transformed into a structure
chart.

It is important to understand that the purpose of structured analysis is to capture

the detailed structure of the system as perceived by the user, whereas the purpose of
structured design is to define the structure of the solution that is suitable for
implementation in some programming language.

STRUCTURED ANALYSIS
structured analysis, the major processing tasks (high-level functions) of the
system are analysed, and t h e data flow among these processing tasks are represented
graphically. The structured analysis technique is based on the following underlying
principles: Top-down decomposition approach. Application of divide and conquer
principle. Through this each highlevel function is independently decomposed into
detailed functions. Graphical representation of the analysis results us i ng data flow
diagrams (DFDs). A DFD is a hierarchical graphical model of a system that shows the
different processing activities or functions that the system performs and the data
interchange among those functions

Data Flow Diagrams (DFDs)

The DFD (also known as the bubble chart) is a simple graphical formalism that can be
used to represent a system in terms of the input data to the system, various processing
carried out on those data, and the output data generated by the system. The main
reason why the DFD technique is so popular is probably because of the fact that DFD is a
very simple formalism— it is simple to understand and use.
There are essentially five different types of symbols used for constructing DFDs.

Function symbol: A function is represented using a circle. This symbol is called a process
or a bubble
External entity symbol: An external entity such as a librarian, a library member, etc. is
represented by a rectangle. The external entities are essentially those physical entities
external to the software system which interact with the system by inputting data to the
system or by consuming the data produced by the system.
Data flow symbol: A directed arc (or an arrow) is used as a data flow symbol. A data flow
symbol represents the data flow occurring between two processes or between an
external entity and a process in the direction of the data flow arrow. Data flow symbols
are usually annotated with the corresponding data names.
Data store symbol: A data store is represented using two parallel lines. It represents a
logical file. That is, a data store symbol can represent either a data structure or a physical
file on disk. Each data store is connected to a process by means of a data flow symbol.
The direction of the data flow arrow shows whether data is being read from or written
into a data store.
Output symbol: The output symbol is used when a hard copy is produced.

Synchronous and asynchronous operations

If two bubbles are directly connected by a data flow arrow, then they are synchronous.
This means that they operate at t he same speed. If two bubbles are directly connected
by a data flow arrow, then they are synchronous. This means that they operate at t he
same speed. Here, the validate-number bubble can start processing only after t h e
readnumber bubble has supplied data to it; and the read-number bubble has to wait
until the validate-number bubble has consumed its data.
However, if two bubbles are connected through a data store, then the speed of
operation of the bubbles are independent. This statement can be explained using the
following reasoning. The data produced by a producer bubble gets stored in the data
store.

Data dictionary
. A data dictionary lists all data items that appear in a DFD model. The data items listed
include all data flows and the contents of all data stores appearing on all the DFDs in a
DFD model. Please remember that the DFD model of a system typically consists of
several DFDs, viz., level 0 DFD, level 1 DFD, level 2 DFDs, etc.,
The dictionary plays a very important role in any software development process,
A data dictionary provides a standard terminology for all relevant data for use by the
developers working in a project. A consistent vocabulary for data items is very
important, since in large projects different developers of the project have a tendency to
use different terms to refer to the same data, which unnecessarily causes confusion.
Data definition
Composite data items can be defined in terms of primitive data items using the following
data definition operators.
+: denotes composition of two data items, e.g. a+b represents data a and b.
[,,]: represents selection, i.e. any one of the data items listed inside the square bracket
can occur For example, [a,b] represents either a occurs or b occurs.
(): the contents inside the bracket represent optional data which may or may not appear.
a+(b) represents either a or a+b occurs.
{}: represents iterative data definition, e.g. {name}5 represents five name data. {name}*
represents zero or more instances of name data.
=: represents equivalence, e.g. a=b+c means that a is a composite data item
DEVELOPING THE DFD MODEL OF A SYSTEM
The DFD model of a problem consists of many of DFDs and a single data dictionary.
To develop the data flow model of a system, first the most abstract representation Level
0 and Level 1 consist of only one DFD each. Level 2 may contain up to 7 separate DFDs,
and level 3 up to 49 DFDs, and so on. However, there is only a single data dictionary for
the entire DFD model.
Context Diagram
The context diagram is the most abstract (highest level) data flow representation of a
system. It represents the entire system as a single bubble. The bubble in the context
diagram is annotated with the name of the software system being developed (usually a
noun). This is the only bubble in a DFD model, where a noun is used for naming the
bubble.
Level 1 DFD
The level 1 DFD usually contains three to seven bubbles. That is, the system is
represented as performing three to seven important functions. To develop the level 1
DFD, examine the high-level functional requirements in the SRS document. If there are
three to seven highlevel functional requirements, then each of these can be directly
represented as a bubble in the level 1 DFD. Each bubble in the DFD represents a function
performed by the system. The bubbles are decomposed into subfunctions at the
successive levels of the DFD model.
DFD model of a system more systematically.
1. Construction of context diagram:
Examine the SRS document to determine: • Different high-level functions that the
system needs to perform. • Data input to every high-level function. • Data output from
every high-level function. • Interactions (data flow) among the identified high-level
functions.
2.Construction of level 1 diagram:
Examine the high-level functions described in the SRS document. If there are three to
seven high-level requirements in the SRS document, then represent each of the high-
level function in the form of a bubble. If there are more than seven bubbles, then some
of them have to be combined. If there are less than three bubbles, then some of these
have to be split.
3.Construction of lower-level diagrams:
Decompose each high-level function into its constituent subfunctions through the
following set of activities: •...Identify the different subfunctions of the high-level
function. •...Identify the data input to each of these subfunctions. •...Identify the data
output from each of these subfunctions. •...Identify he interactions (data flow) among
these subfunctions.
The bubble at the context level is usually assigned the number 0 to indicate that it is the
0 level DFD. Bubbles at level 1 are numbered, 0.1, 0.2, 0.3, etc. When a bubble
numbered x is decomposed, its children bubble are numbered x.1, x.2, x.3, etc
The data that flow into or out of a bubble must match the data flow at the next
level of DFD. This is known as balancing a DFD. In the level 1 DFD, data items d1 and d3
flow out of the bubble 0.1 and the data item d2 flows into the bubble 0.1 (shown by the
dotted circle). In the next level, bubble 0.1 is decomposed into three DFDs
(0.1.1,0.1.2,0.1.3). The decomposition is balanced, as d1 and d3 flow out of the level 2
diagram and d2 flows in. Please note that dangling arrows (d1,d2,d3) represent the data
flows into or out of a diagram.
 Commonly made errors while constructing a DFD model
Although DFDs are simple to understand and draw, students and practitioners
alike encounter similar types of problems while modelling software problems using
DFDs. The errors are as follows:
1. Many beginners commit the mistake of drawing more than one bubble in
the context diagram. Context diagram should depict the system as a single
bubble.
2. Many beginners create DFD models in which external entities appearing at
all levels of DFDs. All external entities interacting with the system should
be represented only in the context diagram. The external entities should
not appear in the DFDs at any other level.
3. It is a common oversight to have either too few or too many bubbles in a
DFD. Only three to seven bubbles per diagram should be allowed. This also
means that each bubble in a DFD should be decomposed three to seven
bubbles in the next level.
4. Many beginners leave the DFDs at the different levels of a DFD model
unbalanced. A common mistake committed by many beginners while
developing a DFD model is attempting to represent control information in
a DFD.

Example 6.1 (RMS Calculating Software) A software system called RMS calculating
software would read three integral numbers from the user in the range of –1000 and
+1000 and would determine the root mean square (RMS) of the three input numbers
and display it. In this example, the context diagram is simple to draw. The system accepts
three integers from the user and returns the result to him.
Example 6.2 (Tic-Tac-Toe Computer Game ) Tic-tac-toe is a computer game in which a
human player and the computer make alternate moves on a 3 × 3 square. A move
consists of marking a previously unmarked square. The player who is first to place three
consecutive marks along a straight line (i.e., along a row, column, or diagonal) on the
square wins. As soon as either of the human player or the computer wins, a message
congratulating the winner should be displayed. If neither player manages to get three
consecutive marks along a straight line, and all the squares on the board are filled up,
then the game is drawn. The computer always tries to win a game.
Data dictionary for the DFD model of Example 6.2 move: integer /* number between 1
to 9 */ display: game+result game: board board: {integer}9 result: [“computer won”,
“human won”, “drawn”]
Example 6.3 (Personal Library Software) Perform structured analysis for the personal
library software
Data dictionary for the DFD model
input-data: friend-reg-data + own-book-data + stat-request + borrowed-book-data
response: friend-reg-conf-msg + own-book-response + stat-response + borrowed-book-
response
own-book-data: query-details + own-book-details + query-outstanding-books-option +
return-own bookdetails + reg-own-book-data
own-book-response: query-book-response + issue-book-msg + friend-details + return-
book- msg + serial#.
borrowed-book-data: borrowed-book-details + book-return-details + display-books-
option borrowed-bookresponse: reg-msg + unreg-msg + borrowed-books-list
friend-reg-data: name + address + landline# + mobile#
own-book-details: friend-reg-data + book-title + data-of-issue
return-own-book-details: book-title + date-of-return
friend-details: name + address + landline# + mobile# + book-list
borrowed-book-details: book-title + borrow-date
serial#: integer
STRUCTURED DESIGN
The aim of structured design is to transform the results of the structured analysis (that i
s, the DFD model) into a structure chart. A structure chart represents the software
architecture. The various modules making up the system, the module dependency (i.e.
which module calls which other modules), and the parameters that are passed among
the different modules.
The basic building blocks using which structure charts are designed are as following:
Rectangular boxes: A rectangular box represents a module. Usually, every rectangular
box is annotated with the name of the module it represents.
Module invocation arrows: An arrow connecting two modules implies that during
program execution control is passed from one module to the other in the direction of
the connecting arrow.
Data flow arrows: These are small arrows appearing alongside the module invocation
arrows. The data flow arrows are annotated with the corresponding data name. Data flo
w arrows represent the fact that the named data passes from one module to the other
in the direction of the arrow.
Library modules: A library module is usually represented by a rectangle with double
edges. Libraries comprise the frequently called modules. Usually, when a module is
invoked by many other modules, it is made into a library module.
Selection: The diamond symbol represents the fact that one module of several modules
connected with the diamond symbol i s invoked depending on the outcome of the
condition attached with the diamond symbol.
Repetition: A loop around the control flow arrows denotes that the respective modules
are invoked repeatedly
Transformation of a DFD Model into Structure Chart
Systematic techniques are available to transform the DFD representation of a problem
into a module structure represented by as a structure chart. Structured design provides
two strategies to guide transformation of a DFD into a structure chart:
1. Transform analysis
2. Transaction analysis
The data input to the diagram can be easily spotted because they are represented by
dangling arrows. If all the data flow into the diagram are processed in similar ways (i.e. if
all the input data flow arrows are incident on the same bubble in the DFD) then
transform analysis is applicable. Otherwise, transaction analysis is applicable. Normally,
transform analysis is applicable only to very simple processing.
Transform analysis
Transform analysis identifies the primary functional components (modules) and the
input and output data for these components. The first step in transform analysis is to
divide the DFD into three types of parts:
• Input. • Processing. • Output.
The input portion in the DFD includes processes that transform input data from physical
(e.g, character from terminal) to logical form (e.g. internal tables, lists, etc.). Each input
portion is called an afferent branch. The output portion of a DFD transforms output data
from logical form to physical form. Each output portion is called an efferent branch. The
remaining portion of a DFD is called central transform. In the next step of transform
analysis, the structure chart is derived by drawing one functional component each for
the central transform, the afferent and efferent branches. These are drawn below a root
module, which would invoke these modules. T h e first level o f structure chart is
produced by representing each input and output unit as a box and each central
transform as a single box. In the third step of transform analysis, the structure chart is
refined by adding subfunctions required by each of the high-level functional
components. Many levels of functional components may be added. This process of
breaking functional components into subcomponents is called factoring.
Example 4 Draw the structure chart for the RMS software of Example 6.1. By observing
the level 1 DFD of Figure 6.8, we can identify validate-input as the afferent branch and
write-output as the efferent branch. The remaining (i.e., compute-rms) as the central
transform. By applying the step 2 and step 3 of transform analysis, we get the structure
chart
Example 5
Draw the structure chart for the tic-tac-toe software of Example 6.2. The structure chart
for the Tic-tac-toe software . Observe that the check-game-status bubble, though
produces some outputs. i s not really responsible for converting logical data to physical
data. On the other hand, it carries out the processing involving checking game status.
That is the main reason, why we have considered it as a central transform and not as an
efferent type of module.

Transaction analysis
Transaction analysis is an alternative to transform analysis and is useful while designing
transaction processing programs. A transaction allows the user to perform some specific
type of work by using the software. As in transform analysis, first all data entering into
the DFD need to be identified. In a transaction-driven system, different data items may
pass through different computation paths through the DFD. This is in contrast to a
transform centered system where each data item entering the DFD goes through the
same processing steps. Each different way in which input data is processed is a
transaction. For each identified transaction, trace the input data to the output. All the
traversed bubbles belong to the transaction. These bubbles should be mapped to the
same module on the structure chart. In the structure chart, draw a root module and
below this module draw each identified transaction as a module
Example 6
The structure chart for the personal library software is
 USER INTERFACE DESIGN

The user interface part of a software product is responsible for all interactions with the
end-user. Consequently, the user interface part of any software product is of direct
concern to the end-users.

CHARACTERISTICS OF A GOOD USER INTERFACE

1. Speed of learning: A good user interface should be easy to learn. Speed of
learning is hampered by complex syntax and semantics of the command issue
procedures. A good user interface should not require its users to memorise
commands.. Besides, the following three issues are crucial to enhance the speed
of learning:
a) U s e of metaphors1 and intuitive command names: Speed of learning an interface is
greatly facilitated if these are based on some dayto-day real-life examples or some
physical objects with which the users are familiar with. The abstractions of real-life
objects or concepts used in user interface design are called metaphors. If the user
interface of a text editor uses concepts similar to the tools used by a writer for text
editing such as cutting lines and paragraphs and pasting it at other places, users can
immediately relate to it.
b) Consistency: Once, a user learns about a command, he should be able to use the
similar commands in different circumstances for carrying out similar actions. Thus, the
different commands supported by an interface should be consistent.
c)Component-based interface: Users can learn an interface faster if the interaction style
of the interface is very similar to the interface of other applications with which the user
is already familiar with. This can be achieved if the interfaces of different applications
are developed using some standard user interface components.

2. Speed of use: Speed of use of a user interface is determined by the time and user
effort necessary to initiate and execute different commands. This characteristic of
the interface is some times referred to as productivity support of the interface. It
indicates how fast the users can perform their intended tasks. The time and user
effort necessary to initiate and execute different commands should be minimal.
 3. Speed of recall: Once users learn how to use an interface, the speed with which
they can recall the command issue procedure should be maximised. Speed of
recall is improved if the interface is based on some metaphors, symbolic
command issue procedures, and intuitive command names.
4. Error prevention: A good user interface should minimise the scope of committing
errors while initiating different commands. The error rate of an interface can be
easily determined by monitoring the errors committed by an average users while
using the interface
5. Consistency: The commands supported by a user interface should be consistent.
The basic purpose of consistency is to allow users to generalise the knowledge
about aspects of the interface from one part to another. Thus, consistency
facilitates speed of learning, speed of recall, and also helps in reduction of error
rate
6. Feedback: A good user interface must provide feedback to various user actions.
Especially, if any user request takes more than few seconds to process, the user
should be informed about the state of the processing of his request. If required,
the user should be periodically informed about the progress made in processing
his command.
7. Error recovery (undo facility): While issuing commands, even the expert users
can commit errors. Therefore, a good user interface should allow a user to undo a
mistake committed by him while using the interface. Users are inconvenienced if
they cannot recover from the errors they commit while using a software. If the
users cannot recover even from very simple types of errors, they feel irritated,
helpless, and out of control.
8. User guidance and on-line help: Users seek guidance and on-line help when they
either forget a command or are unaware of some features of the software.
Whenever users need guidance or seek help from the system, they should be
provided with appropriate guidance and help.

User Guidance and On-line Help

This is provided by the on-line help system. This is different from the guidance and error
messages which are flashed automatically without the user asking for them.
On-line help system: Users expect the on-line help messages to be tailored to the
context in which they invoke the “help system”. Therefore, a good online help system
should keep track of what a user is doing while invoking the help system and provide the
output message in a context-dependent way.
Guidance messages: A good guidance system should have different levels of
sophistication for different categories of users. For example, a user using a command
language interface might need a different type of guidance compared to a user using a
menu or iconic interface
Error messages: Error messages are generated by a system either when the user
commits some error or when some errors encountered by the system during processing
due to some exceptional conditions, such as out of memory, communication link broken,
etc. Users do not like error messages that are either ambiguous or too general such as
“invalid input or system error”.
Mode-based versus Modeless Interface:
A mode is a state or collection of states in which only a subset of all user interaction
tasks can be performed. In a modeless interface, the same set of commands can be
invoked at any time during the running of the software. Thus, a modeless interface has
only a single mode and all the commands are available all the time during the operation
of the software. On the other hand, in a mode-based interface, different sets of
commands can be invoked depending on the mode in which the system is.
Graphical User Interface (GUI) versus Text-based User Interface
 In a GUI multiple windows with different information can simultaneously be
displayed on the user screen. Iconic information representation and symbolic
information manipulation is possible in a GUI.
 Symbolic information manipulation such as dragging an icon representing a file to
a trash for deleting is intuitively very appealing and the user can instantly
remember it. A GUI usually supports command selection using an attractive and
user-friendly menu selection system.
 In a GUI, a pointing device such as a mouse or a light pen can be used for issuing
commands. The use of a pointing device increases the efficacy of command issue
procedure.
TYPES OF USER INTERFACES
user interfaces can be classified into the following three categories:
1. Command language-based interfaces
2. Menu-based interfaces
3. Direct manipulation interfaces
 Command Language-based Interface:
A command language-based interface—as the name itself suggests, is based on
designing a command language which the user can use to issue the commands.
A simple command language-based interface might simply assign unique names
to the different commands. a more sophisticated command language-based
interface may allow users to compose complex commands by using a set of
primitive commands. , a command language-based interface is easier to develop
compared to a menu-based or a direct-manipulation interface because compiler
writing techniques are well developed. One can systematically develop a
command language interface by using the standard compiler writing tools Lex and
Yacc. command language-based interfaces suffer from several drawbacks. Usually,
command language-based interfaces are difficult to learn and require the user to
memorise the set of primitive commands.

Menu-based Interface

A menu-based interface is based on recognition of the command names, rather

than recollection. Humans are much better in recognising something than
recollecting it. Further, in a menu-based interface the typing effort is minimal as
most interactions are carried out through menu selections using a pointing
device. A moderate-sized software might need hundreds or thousands of
different menu choices. In fact, a major challenge in the design of a menu-based
interface is to structure large number of menu choices into manageable forms.

1. Scrolling Menu
2. Walking Menu
3. Hierarchical Menu

Scrolling Menu:
scrolling menu all the commands should be highly correlated, so that the user can easily
locate a command that he needs. This is important since the user cannot see all the
commands at any one time. An example situation where a scrolling menu is frequently
used is font size selection in a document processor. Here, the user knows that the
command list contains only the font sizes that are arranged in some order and he can
scroll up or down to find the size he is looking for.
Walking menu: Walking menu is very commonly used to structure a large collection of
menu items. In this technique, when a menu item is selected, it causes further menu
items to be displayed adjacent to it in a sub-menu A walking menu can successfully be
used to structure commands only if there are tens rather than hundreds of choices since
each adjacently displayed menu does take up screen space and the total screen area is
after all limited

Hierarchical menu: This type of menu is suitable for small screens with limited display
area such as that in mobile phones. In a hierarchical menu, the menu items are
organised in a hierarchy or tree structure. Selecting a menu item causes the current
menu display to be replaced by an appropriate sub-menu. Thus in this case, one can
consider the menu and its various submenu to form a hierarchical tree-like structure.
Walking menu can be considered to be a form of hierarchical menu which is practicable
when the tree is shallow.
FUNDAMENTALS OF COMPONENT-BASED GUI DEVELOPMENT
The current style of user interface development is component-based. It recognises that
every user interface can easily be built from a handfuls of predefined components such
as menus, dialog boxes, forms, etc. Besides the standard components, and the facilities
to create good interfaces from them, one of the basic support available to the user
interface developers is the window system. The window system lets the application
programmer create and manipulate windows without having to write the basic
windowing functions.
Window System
A window system can generate displays through a set of windows. Since a window is the
basic entity in such a graphical user interface.
Window: A window is a rectangular area on the screen. A window can be considered to
be a virtual screen, in the sense that it provides an interface to the user for carrying out
independent activities, e.g., one window can be used for editing a program and another
for drawing pictures, etc.

A window can be divided into two parts—client part, and non-client part. The client area
makes up the whole of the window, except for the borders and scroll bars. The non-
client-part of the window determines the look and feel of the window. The look and feel
defines a basic behaviour for all windows, such as creating, moving, resizing, iconifying
of the windows. The window manager is responsible for managing and maintaining the
non-client area of a window.
Window management system (WMS)
A graphical user interface typically consists of a large number of windows. Therefore, it is
necessary to have some systematic way to manage these windows. Most graphical user
interface development environments do this through a window management system
(WMS).
A WMS consists of two parts:
• a window manager,
• a window system.
Window manager and window system: The window manager is built on the top of the
window system in the sense that it makes use of various services provided by the
window system. The window manager and not the window system determines how the
windows look and behave. In fact, several kinds of window managers can be developed
based on the same window system. user interface development systems usually provide
a high-level abstraction called widgets for user interface development. A widget is the
short form of a window object. We know that an object is essentially a collection of
related data with several operations defined on these data which are available externally
to operate on these data. The data of an window object are the geometric attributes
(such as size, location etc.) and other attributes such as its background and foreground
colour, etc. The operations that are defined on these data include, resize, move, draw,
etc.
Component-based development
A development style based on widgets is called component-based (or widget-based )
GUI development style. There are several important advantages of using a widget-based
design style. One of the most important reasons to use widgets as building blocks is
because they help users learn an interface fast. In this style of development, the user
interfaces for different applications are built from the same basic components.
Types of Widgets
Different interface programming packages support different widget sets.
Label widget: This is probably one of the simplest widgets. A label widget does nothing
except to display a label, i.e., it does not have any other interaction capabilities and is
not sensitive to mouse clicks. A label widget is often used as a part of other widgets.
Container widget: These widgets do not stand by themselves, but exist merely to
contain other widgets. Other widgets are created as children of the container widget.
When the container widget is moved or resized, its children widget also get moved or
resized.
Pop-up menu: These are transient and task specific. A pop-up menu appears upon
pressing the mouse button, irrespective of the mouse position.
Pull-down menu : These are more permanent and general. You have to move the cursor
to a specific location and pull down this type of menu
Dialog boxes: A dialog box can include areas for entering text as well as values. If an
apply command is supported in a dialog box, the newly entered values can be tried
without dismissing the box.
Push button: A push button contains key words or pictures that describe the action that
is triggered when you activate the button. Usually, the action related to a push button
occurs immediately when you click a push button
Radio buttons: A set of radio buttons are used when only one option has to be selected
out of many options. A radio button is a hollow circle followed by text describing the
option it stands for. When a radio button is selected, it appears filled and the previously
selected radio button from the group is unselected
Combo boxes: A combo box looks like a button until the user interacts with it. When the
user presses or clicks it, the combo box displays a menu of items to choose from.

A USER INTERFACE DESIGN METHODOLOGY

User-centered design is the theme of almost all modern user interface design
techniques. However, user-centered design does not mean design by users.
Implications of Human Cognition Capabilities on User Interface Design
Limited memory: Humans can remember at most seven unrelated items of information
for short periods of time. Therefore, the GUI designer should not require the user to
remember too many items of information at a time. It is the GUI designer’s responsibility
to anticipate what information the user will need at what point of each task and to
ensure that the relevant information is displayed for the user to see.
Frequent task closure: Doing a task (except for very trivial tasks) requires doing several
subtasks. When the system gives a clear feedback to the user that a task has been
successfully completed, the user gets a sense of achievement and relief. This is known as
task closure. When the overall task is fairly big and complex, it should be divided into
subtasks, each of which has a clear subgoal which can be a closure point.
Recognition rather than recall: Information recall incurs a larger memory burden on the
users and is to be avoided as far as possible. On the other hand, recognition of
information from the alternatives shown to him is more acceptable.
Procedural versus ob ject-oriented: Procedural designs focus on tasks, prompting the
user in each step of the task, giving them very few options for anything else. This
approach is best applied in situations where the tasks are narrow and well-defined or
where the users are inexperienced, such as a bank ATM. An object-oriented interface on
the other hand focuses on objects. This allows the users a wide range of options.

A GUI Design Methodology

Our user interface design methodology consists of the following important steps:
 Examine the use case model of the software.
 Task and object modelling.
 Metaphor selection.
 Interaction design and rough layout.
 Detailed presentation and graphics design.
 GUI construction.
 Usability evaluation.

Examining the use case model

The starting point for GUI design is the use case model. interface should be developed
using one or more metaphors. Metaphors help in interface development at lower effort
and reduced costs for training the users. Metaphors can also be based on physical
objects such as a visitor’s book, a catalog, a pen, a brush, a scissor, etc. A solution based
on metaphors is easily understood by the users, reducing learning time and training
costs.

Task and ob ject modelling A task is a human activity intended to achieve some goals.
Examples of task goals can be as follows: Reserve an airline seat Buy an item Transfer
money from one account to another Book a cargo for transmission to an address A task
model is an abstract model of the structure of a task. A task model should show the
structure of the subtasks that the user needs to perform to achieve the overall task goal.
Each task can be modeled as a hierarchy of subtasks.
Metaphor selection Metaphors is the set of parallels to objects, tasks, and
terminologies of the use cases. If no obvious metaphors can be found, then the designer
can fall back on the metaphors of the physical world of concrete objects. Another
criterion that can be used to judge metaphors is that the metaphor should be as simple
as possible, the operations using the metaphor should be clear and coherent and it
should fit with the users’ ‘common sense’ knowledge.
Interaction design and rough layout The interaction design involves mapping the
subtasks into appropriate controls, and other widgets such as forms, text box, etc. This
involves making a choice from a set of available components that would best suit the
subtask. Rough layout concerns how the controls, an other widgets to be organised in
windows.
Detailed presentation and graphics design Each window should represent either an
object or many objects that have a clear relationship to each other. At one extreme,
each object view could be in its own window. But, this is likely to lead to too much
window opening, closing, moving, and resizing.
GUI construction windows have to be defined as modal dialogs. When a window is a
modal dialog, no other windows in the application is accessible until the current window
is closed. When a modal dialog is closed, the user is returned to the window from which
the modal dialog was invoked.
Usability evaluation common usability problems and built a check list of points which
can be easily checked for an interface.