Se-Iii 112018
Se-Iii 112018
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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.
Menu-based Interface
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.
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.