22CSC51 - AGILE METHODOLOGIES

Prepared By,
Mr.N.Aravindhraj,
Assistant Professor
Department.of CSE
Kongu Engineering College
 Quality attributes
The attributes of design name as 'FURPS' are as follows:
Functionality:
It evaluates the feature set and capabilities of the program.

Usability:
It is accessed by considering the factors such as human factor, overall aesthetics, consistency
and documentation.

Reliability:
It is evaluated by measuring parameters like frequency and security of failure, output result
accuracy, the mean-time-to-failure(MTTF), recovery from failure and the program predictability.

Performance:
It is measured by considering processing speed, response time, resource consumption,
throughput and efficiency.

Supportability:
• It combines the ability to extend the program, adaptability, serviceability. These three term
defines the maintainability.
• Testability, compatibility and configurability are the terms using which a system can be
easily installed and found the problem easily.
• Supportability also consists of more attributes such as compatibility, extensibility, fault
tolerance, modularity, reusability, robustness, security, portability, scalability.
 Design Concepts
The goal of the Good software design is to produce a
model or representation that exhibits
 Firmness: A program should not have any bugs

that inhibit its function.

 Commodity: A program should be suitable for the

purposes for which it was intended.

 Delight: The experience of using the program

should be pleasurable one.

Design Model
 Design Concepts
A set of fundamental software design concepts has
evolved over the history of Software Engineering.
Each provides the software designer with a foundation
from which more sophisticated design methods can be
applied. Each helps you answer the following questions:
• What criteria can be used to partition software into
individual components?
• How is function or data structure detail separated
from a conceptual representation of the software?
• What uniform criteria define the technical quality of
a software design?
 Design Concepts
The set of fundamental software design concepts are as follows:
 Abstraction
 Architecture
 Patterns
 Separation of Concerns
 Modularity
 Information hiding
 Functional independence
 Refinement
 Aspects
 Refactoring
 OO Design Concepts
 Design classes
 Design Concepts
• Abstraction—data, procedure, control
• Architecture—the overall structure of the software
• Patterns—”conveys the essence” of a proven design solution
• Separation of concerns—any complex problem can be more easily
handled if it is subdivided into pieces
• Modularity—compartmentalization of data and function
• Hiding—controlled interfaces
• Functional independence—single-minded function and low
coupling
• Refinement—elaboration of detail for all abstractions
• Aspects—a mechanism for understanding how global
requirements affect design
• Refactoring—a reorganization technique that simplifies the design
• OO design concepts
• Design Classes—provide design detail that will enable analysis
classes to be implemented
 Abstraction
• Abstraction is the act of representing essential
features without including the background details or
explanations.
• The abstraction is used to reduce complexity and
allow efficient design and implementation of complex
software systems.
• Many levels of abstraction can be posed.
• At the highest level of abstraction, a solution is
stated in broad terms using the language of the
problem environment.
• At lower levels of abstraction, a more detailed
description of the solution is provided.
 Abstraction
Procedural Abstraction
• A procedural abstraction refers to a sequence of
instructions that have a specific and limited function.
The name of a procedural abstraction implies the
functions, but specific details are suppressed.
• An example of a procedural abstraction would be the
word open for a door. Open implies a long sequence
of procedural steps.
• e.g., walk to the door, reach out and grasp knob, turn
knob and pull door, step away from moving door,
etc.).
 Abstraction
Data Abstraction
• A data abstraction is a named collection of data that
describes a data object.
• In the context of the procedural abstraction open, we
can define a data abstraction called door.
• Like any data object, the data abstraction for door
would encompass a set of attributes that describe
the door (e.g., door type, swing direction, opening
mechanism, weight, dimensions).
• It follows that the procedural abstraction open
would make use of information contained in the
attributes of the data abstraction door.
 Architecture
• Software architecture alludes to “the overall
structure of the software and the ways in which that
structure provides conceptual integrity for a
system”.
• In its simplest form, architecture is the structure or
organization of program components (modules), the
manner in which these components interact, and the
structure of data that are used by the components.
• set of properties that should be specified as part of
an architectural design:
 Structural properties
 Extra-functional properties
 Families of related systems
 Architecture

Structural properties:
• This aspect of the architectural design representation defines the
components of a system (e.g., modules, objects, filters) and the
manner in which those components are packaged and interact
with one another.
Extra-functional properties:
• The architectural design description should address
how the design architecture achieves requirements
for performance, capacity, reliability, security, adaptability, and
other system characteristics.
Families of related systems:
• The architectural design should draw upon repeatable patterns
that are commonly encountered in the design of families of
similar systems.
• In essence, the design should have the ability to reuse
architectural building blocks.
 Architecture

• The architectural design can be represented using one or more of a

number of different models.
• Structural models: Represent architecture as an organized
collection of program components.
• Framework models: Increase the level of design abstraction by
attempting to identify repeatable architectural design frameworks
that are encountered in similar types of applications.
• Dynamic models : Address the behavioral aspects of the program
architecture, indicating how the structure or system configuration
may change as a function of external events.
• Process models :Focus on the design of the business or technical
process that the system must accommodate.
• Functional models : can be used to represent the functional
hierarchy of a system.
• A number of different architectural description languages (ADLs)
have been developed to represent these models.
 Patterns
• Brad Appleton defines a design pattern in the
following manner: “A pattern is a named nugget of
insight which conveys the essence of a proven
solution to a recurring problem within a certain
context amidst competing concerns”.
• Design pattern describes a design structure that
solves a particular design problem within a specific
context and amid “forces” that may have an impact
on the manner in which the pattern is applied and
used.
 Patterns
• The intent of each design pattern is to provide a
description that enables a designer to determine:

(1) whether the pattern is applicable to the current

work,
(2) whether the pattern can be reused (hence, saving
design time), and
(3) whether the pattern can serve as a guide for
developing a similar, but functionally or structurally
different pattern.
 Separation of Concerns
• Separation of concerns is a design concept that suggests that
any complex problem can be more easily handled if it is
subdivided into pieces that can each be solved and/or
optimized independently.
• A concern is a feature or behavior that is specified as part of
the requirements model for the software.
• By separating concerns into smaller, and therefore more
manageable pieces, a problem takes less effort and time to
solve.
• For two problems, p1 and p2, if the perceived complexity of
p1 is greater than the perceived complexity of p2, it follows
that the effort required to solve p1 is greater than the effort
required to solve p2. As a general case, this result is intuitively
obvious.
 Separation of Concerns

• It does not take more time to solve a difficult

problem.
• Separation of concerns is manifested in other related
design concepts:
Modularity,
Aspects,
Functional Independence,
Refinement.
 Modularity
• Modularity is the most common manifestation of
separation of concerns.
• Software is divided into separately named and
addressable components, sometimes called modules,
that are integrated to satisfy problem requirements.
• It has been stated that “modularity is the single
attribute of software that allows a program to be
intellectually manageable”
 Modularity
• However, as the number of modules grows, the effort
(cost) associated with integrating the modules also
grows.
 Information Hiding
• The principle of information hiding suggests that
modules be “characterized by design decisions that
hides from all others.”
• In other words, modules should be specified and
designed so that information contained within a
module is inaccessible to other modules that have
no need for such information.
• The use of information hiding as a design criterion
for modular systems provides the greatest benefits
when modifications are required during testing and
later during software maintenance.
 Functional Independence
• The concept of functional independence is a direct
outgrowth of separation of concerns, modularity, and
the concepts of abstraction and information hiding.
• Functional independence is achieved by developing
modules with “single minded” function and an
“aversion” to excessive interaction with other
modules.
• Independence is assessed using two qualitative
criteria:
– Cohesion
– Coupling
 Cohesion
• Cohesion is an indication of the relative functional
strength of a module.
• Cohesion is a natural extension of the information-
hiding concept
• A cohesive module performs a single task, requiring
little interaction with other components in other
parts of a program.
• Stated simply, a cohesive module should (ideally) do
just one thing.
• Although you should always strive for high cohesion
(i.e., single-mindedness)
 Coupling
• Coupling is an indication of the relative
interdependence among modules.
• Coupling is an indication of interconnection among
modules in a software structure.
• Coupling depends on the interface complexity
between modules, the point at which entry or
reference is made to a module, and what data pass
across the interface.
• In software design, you should strive for the lowest
possible coupling.
 Refinement
• Stepwise refinement is a top-down design strategy.
• Refinement is actually a process of elaboration.
• Abstraction and refinement are complementary
concepts.
• Abstraction enables you to specify procedure and
data internally but suppress the need for “outsiders”
to have knowledge of low-level details.
• Refinement helps you to reveal low-level details as
design progresses.
 Aspects and Refactoring
Aspects
• An aspect is a representation of a crosscutting concern.
• A crosscutting concern is some characteristic of the system
that applies across many different requirements.
Refactoring
• “Refactoring is the process of changing a software system
in such a way that it does not alter the external behavior
of the code [design] yet improves its internal structure.”
• An important design activity suggested for many agile
methods, refactoring is a reorganization technique that
simplifies the design (or code) of a component without
changing its function or behavior.
 Object-Oriented Design Concepts
• The object-oriented (OO) paradigm is widely used in
modern software engineering.
• OO design concepts such as
Classes and Objects
Inheritance
Message Passing
Polymorphism
are widely used.
 Design Classes
• A set of design classes that refine the analysis classes
by providing design detail that will enable the classes
to be implemented, and implement a software
infrastructure that supports the business solution.
• Five different types of design classes, each
representing a different layer of the design
architecture, can be developed:
• User interface classes define all abstractions that are
necessary for human computer interaction (HCI).
• The design classes for the interface may be visual
representations of the elements of the metaphor.
 Design Classes
• Business domain classes are often refinements of the
analysis classes defined earlier. The classes identify the
attributes and services (methods) that are required to
implement some element of the business domain.
• Process classes implement lower-level business
abstractions required to fully manage the business
domain classes.
• Persistent classes represent data stores (e.g., a database)
that will persist beyond the execution of the software.
• System classes implement software management and
control functions that enable the system to operate and
communicate within its computing environment and with
the outside world.
 Design Classes
• Four characteristics of a well-formed design class:
 Complete and sufficient
 Primitiveness
 High cohesion
 Low coupling