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 isgathering requirements
(early in a project).
 The team is in the middle of validation testing (something that occursrelatively
late in the project), and stakeholder is requesting a major functional change. Thechange requires
a modification to the architectural design of the software, the design and construction of three
new components, modifications to another fivecomponents, 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 asoftware 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 numberof 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—
isessential.
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, andsome 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 ofdifferent talents
must exist among the people on an agile team and the team itself:
Competence:“competence” encompasses talent, specific software-relatedskills, 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 softwareincrement 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 softwaredevelopment. 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)
todesign 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 anytime.
• 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 ofunit 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 successfullyfor 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 bemodified 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). Butmany 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 backlogand updates priorities as required.
Sprints—consist of work units that are required to achieve a requirement definedin 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 theresponses from each
person.
Demos—deliver the software increment to the customer so that functionality thathas 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 constraintsassociated 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 thatwill 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 provideoperational
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 asthe 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 as1)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 betterunderstand aspect of the
software) in mind before creating the model.
Use multiple models. There are many different models and notations thatcan 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 modelsthat 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 tocreate it.
Adapt locally. The modeling approach should be adapted to the needs ofthe 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 andcoordinates 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