Software Engineering

B.Tech IT/II Sem-II

Term: 2008-2009
Unit-4 PPT SLIDES

Text Books:1.Software Engineering, A practitioner’s approach

Roger s. Pressman 6th edition McGraw-Hill
2.Software Engineering Somerville 7th edition

1
 UNIT 4 SYLLABUS
• Design Engineering : Design process and
Design quality, Design concepts, the design
model.
• Creating an architectural design : Software
architecture, Data design, Architectural styles
and patterns, Architectural Design.

2
 INDEX
Unit-4 PPTS
S.No Topic Lecture No PPTSlides
1 Design Process & Design Quality L1 4
2 Design Concepts Abstraction, L2 7
Architecture,
Patterns, Modularity
3 Design Concepts L3 12

--Information Hiding, Functional

Independence
Refinement, Refactoring, Design
classes
4 Design Models L4 16
--Data
Design Elements, Architectural
Design Elements, Component Level
Design Elements, Deployment
Level Design Elements
5 Creating an architectural design: L5 19
Software Architecture
6 Data Design L6 22
3
7 Architectural styles and patterns L7 25
 DESIGN ENGINEERING
DESIGN PROCESS AND DESIGN QUALITY
– ENCOMPASSES the set of principles, concepts and
practices that lead to the development of high quality
system or product
– Design creates a representation or model of the software
– Design model provides details about S/W architecture,
interfaces and components that are necessary to
implement the system
– Quality is established during Design
– Design should exhibit firmness, commodity and design
– Design sits at the kernel of S/W Engineering
– Design sets the stage for construction
– Design should represented using effective notations
4
 QUALITY GUIDELINES
• Users recognizable architectural styles or patterns
• Modular, that is logically partitioned into elements
or subsystems
• Distinct representation of data, architecture,
interfaces and components
• Appropriate data structures for the classes to be
implemented
• Independent functional characteristics for
components
• Interfaces that reduces complexity of connection
• Repeatable method
5
 QUALITY ATTRIBUTES
• FURPS quality attributes

Functionality
* Feature set and capabilities of programs
* Security of the overall system
Usability
* user-friendliness
* Aesthetics
* Consistency
* Documentation
Reliability
* Evaluated by measuring the frequency and severity of failure
* MTTF(mean-time-to-failue)

6
 QUALITY ATTRIBUTES
Performance
* Speed
* Response Time
* Throughput
* Resource Consumption
* Efficiency

Supportability
* Extensibility
* Adaptability
* Serviceability

7
 DESIGN CONCEPTS
1. Abstractions
2. Architectures
3. Patterns
4. Modularity
5. Information Hiding
6. Functional Independence
7. Refinement
8. Re-factoring
9. Design Classes 8
 DESIGN CONCEPTS
ABSTRACTION
Different levels of abstraction
• Highest level of abstraction : Solution is slated in broad terms
using the language of the problem environment
• Lower levels of abstraction : More detailed description of the
solution is provided
• Procedural abstraction
-- Refers to a sequence of instructions that a specific and
limited function
• Data abstraction
-- Named collection of data that describe a data object

9
 DESIGN CONCEPTS
ARCHITECTURE
--Structure organization of program components (modules) and their
interconnection
• Architecture Models
(a) Structural Models
-- An organized collection of program components
(b) Framework Models
-- Represents the design in more abstract way
(c) Dynamic Models
-- Represents the behavioral aspects indicating changes
as a function of external events
(d) Process Models
-- Focus on the design of the business or technical process
10
 PATTERNS
Provides a description to enables a designer to
determine the followings :
(a) Whether the pattern is applicable to the
current work
(b) Whether the pattern can be reused
(c) Whether the pattern can serve as a guide
for developing a similar but functionally or
structurally different pattern

11
 MODULARITY
• Divides software into separately named and addressable
components, sometimes called modules
• Modules are integrated to satisfy problem requirements
• Consider two problems p1 and p2. If the complexity of p1 is
cp1 and of p2 is cp2 then effort to solve p1=cp1 and effort to
solve p2=cp2
• If cp1>cp2 then ep1>ep2
• The complexity of two problems when they are combined is
often greater than the sum of the perceived complexity
when each is taken separately
• Based on Divide and Conquer strategy : it is easier to solve
a complex problem when broken into sub-modules

12
 INFORMATION HIDING
• Information contained within a module is inaccessible
to other modules who do not need such information
• Achieved by defining a set of Independent modules
that communicate with one another only that
information necessary to achieve S/W function
• Provides the greatest benefits when modifications are
required during testing and later
• Errors introduced during modification are less likely to
propagate to other location within the S/W

13
 FUNCTIONAL INDEPENDENCE
• A direct outgrowth of Modularity. abstraction and information hiding.
• Achieved by developing a module with single minded function and an
aversion to excessive interaction with other modules.
• Easier to develop and have simple interface
• Easier to maintain because secondary effects caused b design or code
modification are limited, error propagation is reduced and reusable
modules are possible.
Independence is assessed by two quantitative criteria:
(1) Cohesion
(2) Coupling
Cohesion
-- Performs a single task requiring little interaction with other
components
Coupling
--Measure of interconnection among modules
--Coupling should be low and cohesion should be high for good design
14
 REFINEMENT & REFACTORING
REFINEMENT

• Process of elaboration from high level abstraction to the

lowest level abstraction
• High level abstraction begins with a statement of functions
• Refinement causes the designer to elaborate providing
more and more details at successive level of abstractions
• Abstraction and refinement are complementary concepts.

REFACTORING

• Organization technique that simplifies the design of a

component without changing its function or behavior.
• Examines for redundancy, unused design elements and
inefficient or unnecessary algorithms 15
 DESIGN CLASSES
Class represents different layers of design architecture. Five types of Design Classes

1. User interface class

-- Defines all abstractions that are necessary for human computer interaction
2. Business Domain class
-- Refinement of the analysis classes that identity attributes and services to
implement some of business domain
3.Process class
-- implements lower level business abstractions required to fully manage the business
domain classes
4.Persistent class
-- Represent data stores that will persist beyond the execution of the software
5.System class
-- Implements management and control functions to operate and communicate within
the computer environment and with the outside world.

16
 THE DESIGN MODEL
• Analysis viewed in two different dimensions as process
dimension and abstract dimension.
• Process dimension indicates the evolution of the design
model as design tasks are executed as part of software
process.
• Abstraction dimension represents the level of details as each
element of the analysis model is transformed into design
equivalent
Data Design Elements
-- Data design creates a model of data that is represented at a
high level of abstraction
-- Refined progressively to more implementation-specific
representation for processing by the computer base system
-- Translation of data model into a data base is pivotal to
achieving business objective of a system
17
 THE DESIGN MODEL
Architectural design elements
Derived from three sources
(1) Information about the application domain of the
software
(2) Analysis model such as dataflow diagrams or analysis
classes.
(3) Architectural pattern and styles

Interface Design elements

-- Set of detailed drawings constituting:
(1) User interface
(2) External interfaces to other systems, devices etc
(3) Internal interfaces between various components
18
 THE DESIGN MODEL
Deployment level design elements
-- Indicates how software functionality and subsystem
will be allocated with in the physical computing
environment
-- UML deployment diagram is developed and refined
Component level design elements
--Fully describe the internal details of each
software component
--UML diagram can be used

19
CREATING AN ARCHITECTURAL
DESIGN
What is SOFTWARE ARCHITECTURE:
The software architecture of a program or
computing system is the structure or
structures of the system, which comprise
software components, the externally
visible properties of those components
and the relationship among them.

20
• Software Architecture is not the operational software.
• It is a representation that enables a software
engineer to
 Analyze the effectiveness of the design in meeting its
stated requirements.
 consider architectural alternative at a stage when making
design changes is still relatively easy .
 Reduces the risk associated with the construction of the
software.

21
• Why Is Architecture Important?

Three key reasons

1. Representations of software architecture enables

communication and understanding between
stakeholders.
2. Highlights early design decisions to create an operational
entity.
3. constitutes a model of software components and their
interconnection.

22
 Data Design
• The data design action translates data
objects defined as part of the analysis
model into data structures at the
component level and a database
architecture at application level when
necessary.

23
DATA DESIGN AT ARCHITECTURE LEVEL

• Data structure at programming level

• Data base at application level
• Data warehouse at business level.

24
 DATA DESIGN AT COMPONENT LEVEL
Principles for data specification:
1. Proper selection of data objects and data and data models
2. Identification of attribute and functions and their
encapsulation of these within a class
3. Mechanism for representation of the content of each data
object. Class diagrams may be used
4. Refinement of data design elements from requirement
analysis to component level design.
5. Information hiding
6. A library of useful data structures and operations be
developed.
7. Software design and PL should support the specification
and realization of abstract data types..

25
 ARCHITECTURAL STYLES
Describes a system category that encompasses:
(1) a set of components
(2) a set of connectors that enables “communication and
coordination
(3) Constraints that define how components can be integrated
to form the system
(4) Semantic models to understand the overall properties of a
system

26
27
 Data-flow architectures
• Shows the flow of input data, its computational
components and output data
• Structure is also called pipe and Filter
• Pipe provides path for flow of data
• Filters manipulate data and work independent of
its neighboring filter
• If data flow degenerates into a single line of
transform, it is termed as batch sequential.

28
29
 Call and return architectures
Achieves a structure that is easy to modify and scale
Two sub styles
(1) Main program/sub program architecture
-- Classic program structure
-- Main program invokes a number of
components, which in turn invoke still other
components
(2) Remote procedure call architecture
-- Components of main program/subprogram are
distributed across computers over network

30
Object-oriented architectures
• The components of a system encapsulate
data and the operations
• Communication and coordination between
components is done via message

31
 Layered architectures
• A number of different layers are defined
• Inner Layer( interface with OS)
• Intermediate Layer Utility services and
application function)
• Outer Layer (User interface)

32
FIG: Layered Architecture

33
 ARCHITECTURAL PATTERNS
A template that specifies approach for behavioral characteristics of the system
• Patterns are imposed on the architectural styles
• Pattern Domains
1.Concurrency
--Handles multiple tasks that simulates parallelism.
--Approaches(Patterns)
(a) Operating system process management pattern
(b) A task scheduler pattern
2.Persistence
--Data survives past the execution of the process
--Approaches (Patterns)
(a) Data base management system pattern
(b) Application Level persistence Pattern( word processing software)
3.Distribution
-- Addresses the communication of system in a distributed environment
--Approaches(Patterns)
(a) Broker Pattern
- Acts as middleman between client and server.
34