Architectural design, Architectural design process, Architecture importance, Architectural description, data-centered Architecture, Data flow style, Data flow Architecture, call and return style, call and return Architecture, object-oriented architecture, layered architecture, architectural patterns, organization and refinement. Fundamentals of Software Engineering

1. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 1
Chapter 2
 Architectural Design

2. 2
Definitions
 The software architecture of a program or computing system is the
structure or structures of the system which comprise
 The software components
 The externally visible properties of those components
 The relationships among the components
 Software architectural design represents the structure of the data and
program components that are required to build a computer-based
system
 An architectural design model is transferable
 It can be applied to the design of other systems
 It represents a set of abstractions that enable software engineers to
describe architecture in predictable ways

3. 3
Architectural Design Process
 Basic Steps
 Creation of the data design
 Derivation of one or more representations of the architectural structure of
the system
 Analysis of alternative architectural styles to choose the one best suited to
customer requirements and quality attributes
 Elaboration of the architecture based on the selected architectural style
 A database designer creates the data architecture for a system to
represent the data components
 A system architect selects an appropriate architectural style derived
during system engineering and software requirements analysis

4. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 4
Why Architecture?
The architecture is not the operational software. Rather,The architecture is not the operational software. Rather,
it is a representation that enables a software engineerit is a representation that enables a software engineer
to:to:
(1)(1) analyze the effectiveness of the design in meeting itsin meeting its
stated requirements,stated requirements,
(2)(2) consider architectural alternatives at a stage whenat a stage when
making design changes is still relatively easy, andmaking design changes is still relatively easy, and
(3)(3) reduce the risks associated with the construction ofassociated with the construction of
the software.the software.
Focus is placed on the software component
•A program module
•An object-oriented class
•A database
•Middleware

5. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 5
Why is Architecture Important?
 Representations of software architecture are an enabler
for communication between all parties (stakeholders)
interested in the development of a computer-based
system.
 The architecture highlights early design decisions that
will have a profound impact on all software engineering
work that follows and, as important, on the ultimate
success of the system as an operational entity.
 Architecture “constitutes a relatively small, intellectually
graspable mode of how the system is structured and
how its components work together” [BAS03].

6. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 6
Architectural Descriptions
 The IEEE Computer Society has proposed IEEE-Std-
1471-2000, Recommended Practice for Architectural
Description of Software-Intensive System, [IEE00]
 to establish a conceptual framework and vocabulary for use
during the design of software architecture,
 to provide detailed guidelines for representing an architectural
description, and
 to encourage sound architectural design practices.
 The IEEE Standard defines an architectural description (AD)
as a “a collection of products to document an architecture.”
 The description itself is represented using multiple views, where
each view is “a representation of a whole system from the
perspective of a related set of [stakeholder] concerns.”

7. Architectural Decisions
 Architectural description addresses a specific
stakeholder concern.
 Among multiple views the system architect
considers a variety of alternatives and
ultimately decides the specific architectural
feature that best meet the concern.
 Therefore, architecture decisions themselves
can be considered to be one view of the
architecture.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 7

8. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 8
Architectural Styles
 Data-centered architectures
 Data flow architectures
 Call and return architectures
 Object-oriented architectures
 Layered architectures
Each style describes a system category that encompasses: (1) aEach style describes a system category that encompasses: (1) a
set of components (e.g., a database, computational modules)(e.g., a database, computational modules)
that perform a function required by a system, (2) athat perform a function required by a system, (2) a set of
connectors that enable “communication, coordination andthat enable “communication, coordination and
cooperation” among components, (3)cooperation” among components, (3) constraints that definethat define
how components can be integrated to form the system, andhow components can be integrated to form the system, and
(4)(4) semantic models that enable a designer to understand thethat enable a designer to understand the
overall properties of a system by analyzing the knownoverall properties of a system by analyzing the known
properties of its constituent parts.properties of its constituent parts.

9. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 9
Data-Centered Architecture

10. 10
Data-Centered Style (continued)
 A data store resides at the center of the architecture and is accessed
frequently by other components that update, add, delete data within
the store
 In some case data repository is passive. i.e. client software access the
data independent of any changes to the data or actions of other client
software
 A variation on this approach transforms the repository into a
“blackboard” that sends a notification to client software when data of
interest to the client changes
(More on next slide)

11. 11
Data-Centered Style (continued)
 Data-centered architectures promotes integrability i.e. existing
components can be changed and new client components added to the
architecture without concern about other clients
 Client components independently execute processes

12. 12
Data Flow Style
Validate Sort Update Report

13. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 13
Data Flow Architecture

14. 14
Data Flow Style
• It is applied when input data are to be transformed through a
series of computational or manipulative components into o/p
data
• A pipe and filter pattern has set of components , called
filter , connected by pipes that transmits data from one
component to the next
• Each filter works independently and is designed to expect
data input of a certain form, and produces data output of a
specified form
• Batch sequential approach: This structure accepts a batch of
data and then applies a series of sequential components to
transform it
(More on next slide)

15. 15
Call-and-Return Style
Main module
Subroutine A
Subroutine B
Subroutine A-1 Subroutine A-2
Physical layer
Data layer
Network layer
Transport layer
Application layer Class WClass V
Class X
Class Z
Class Y

16. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 16
Call and Return Architecture

17. 17
Call-and-Return Style
• Has the goal of modifiability and scalability
• A number of sub styles exist within this category
Categories
• Main / sub program architecture:
– it decomposes function into a control hierarchy where a
“main” program invokes a no of program components ,
which in turn may invoke still other components
• RPC architecture:
– the components of main program / sub program architecture
are distributed across multiple computers on a network
(More on next slide)

18. 18
Object-oriented Architecture
• The components of a system encapsulate
data and the operations that must be applied
to manipulate the data
• Communication and coordination between
the components are accomplished via
message passing.

19. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 19
Layered Architecture

20. 20
Layered system
 A number of different layers are defined, each accomplishing
operations that progressively become closer to the machine
instruction set
 At the outer layer, components are used to serve user
interface operations
 At the inner layer, components perform operating system
interfacing
 Intermediate layers provides utility services and application
software functions

21. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 21
Architectural Patterns
 Architectural patterns address an
application-specific problem within a
specific context and under a set of
limitations and constraints.
 The pattern proposes an architectural
solution that can serve as the basis for
architectural design
.

22. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 22
Organization and Refinement
 Set of design criteria can be used to access an
architectural design that is derived
 Control: How is control managed within the
architecture?
 Data: How are data communicated between
components? What is a mode of transfer? etc.