SlideShare a Scribd company logo
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
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
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
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
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].
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.”
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
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.
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
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
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
Data Flow Style
Validate Sort Update Report
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
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
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
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
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
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.
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
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
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
.
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.

More Related Content

PDF
Software Designing - Software Engineering
PPTX
Design Concept software engineering
PDF
software design principles
PPTX
Unit v -Construction and Evaluation
PPTX
Software Design and Modularity
PPT
Software architecture
DOC
Chapter 4 software design
Software Designing - Software Engineering
Design Concept software engineering
software design principles
Unit v -Construction and Evaluation
Software Design and Modularity
Software architecture
Chapter 4 software design

What's hot (20)

PDF
4 agile modeldevelopement-danielleroux
 
PPTX
Design process and concepts
PPT
Pressman ch-11-component-level-design
PPTX
Design techniques
PPTX
Design concept -Software Engineering
PPTX
Software engineering 17 architectural design
PPT
Architectural Design
PPTX
Software architecture by Dr.C.R.Dhivyaa, Assistant Professor,Kongu Engineerin...
PPT
07 software design
PPTX
Software architecture
PDF
Unit 5- Architectural Design in software engineering
PDF
Essential Software Architecture - Chapter 1 Understanding Software Architectu...
PPTX
Architectural styles and patterns
PPTX
Cs8092 computer graphics and multimedia unit 5
PPTX
Architectural styles and patterns
PPTX
Architectural design of software
PPT
Architectural Design in Software Engineering SE10
PPT
Seii unit7 component-level-design
PPT
PPT
Unit iii(part d - component level design)
4 agile modeldevelopement-danielleroux
 
Design process and concepts
Pressman ch-11-component-level-design
Design techniques
Design concept -Software Engineering
Software engineering 17 architectural design
Architectural Design
Software architecture by Dr.C.R.Dhivyaa, Assistant Professor,Kongu Engineerin...
07 software design
Software architecture
Unit 5- Architectural Design in software engineering
Essential Software Architecture - Chapter 1 Understanding Software Architectu...
Architectural styles and patterns
Cs8092 computer graphics and multimedia unit 5
Architectural styles and patterns
Architectural design of software
Architectural Design in Software Engineering SE10
Seii unit7 component-level-design
Unit iii(part d - component level design)
Ad

Similar to Fundamentals of Software Engineering (20)

PPT
Unit iii(part b - architectural design)
PPTX
Software Design.pptx
PPT
Chapter 08
PPT
Se ii unit3-architectural-design
PDF
Ch01 SE
PPT
Software architecture design ppt
PPT
Object oriented sad-5 part i
PPT
Chapter_01_of_slides_of_software_engineering_book.ppt
PPT
software
PDF
chapter1 introduction of software engneering.pdf
PPT
SE CHAPTER 1 SOFTWARE ENGINEERING
PPT
Software Engineering
PPT
Chapter 01 software engineering pressman
PPTX
Unit_4_Software_Design.pptx
PPTX
UNIT-3_SE_PPT1.pptx software engineering
PDF
Software Engineering and Fundamentals note
PPT
PPT-UEU-Rekayasa-Perangkat-Lunak-Pertemuan-1.ppt
PPT
Architec design introduction
PPT
Artifical selection for enhancment for people Use
PPTX
Introduction to Modern Software Architecture
Unit iii(part b - architectural design)
Software Design.pptx
Chapter 08
Se ii unit3-architectural-design
Ch01 SE
Software architecture design ppt
Object oriented sad-5 part i
Chapter_01_of_slides_of_software_engineering_book.ppt
software
chapter1 introduction of software engneering.pdf
SE CHAPTER 1 SOFTWARE ENGINEERING
Software Engineering
Chapter 01 software engineering pressman
Unit_4_Software_Design.pptx
UNIT-3_SE_PPT1.pptx software engineering
Software Engineering and Fundamentals note
PPT-UEU-Rekayasa-Perangkat-Lunak-Pertemuan-1.ppt
Architec design introduction
Artifical selection for enhancment for people Use
Introduction to Modern Software Architecture
Ad

More from Madhar Khan Pathan (20)

PPTX
Fundamentals of Software Engineering
PPTX
Fundamentals of Software Engineering
PPTX
Fundamentals of Software Engineering
PPT
Fundamentals of Software Engineering
PPT
Fundamentals of Software Engineering
PPT
Fundamentals of Software Engineering
PPT
Fundamentals of Software Engineering
PPT
Fundamentals of Software Engineering
PPT
Fundamentals of Software Engineering
PPTX
Fundamentals of Software Engineering
PPTX
Fundamentals of Software Engineering
PPTX
Fundamentals of Software Engineering
PPTX
Fundamentals of Software Engineering
PPTX
Fundamentals of Software Engineering
PPTX
Fundamentals of Software Engineering
PPTX
Fundamentals of Software Engineering
PPTX
Fundamentals of Software Engineering
PPTX
Generic process model
PPTX
Software Myths
PPTX
Introduction to Software Engineering
Fundamentals of Software Engineering
Fundamentals of Software Engineering
Fundamentals of Software Engineering
Fundamentals of Software Engineering
Fundamentals of Software Engineering
Fundamentals of Software Engineering
Fundamentals of Software Engineering
Fundamentals of Software Engineering
Fundamentals of Software Engineering
Fundamentals of Software Engineering
Fundamentals of Software Engineering
Fundamentals of Software Engineering
Fundamentals of Software Engineering
Fundamentals of Software Engineering
Fundamentals of Software Engineering
Fundamentals of Software Engineering
Fundamentals of Software Engineering
Generic process model
Software Myths
Introduction to Software Engineering

Recently uploaded (20)

PDF
Digital Strategies for Manufacturing Companies
PDF
How to Migrate SBCGlobal Email to Yahoo Easily
PPTX
Lecture 3: Operating Systems Introduction to Computer Hardware Systems
PDF
Odoo Companies in India – Driving Business Transformation.pdf
PDF
Claude Code: Everyone is a 10x Developer - A Comprehensive AI-Powered CLI Tool
PPTX
ManageIQ - Sprint 268 Review - Slide Deck
PDF
2025 Textile ERP Trends: SAP, Odoo & Oracle
PPTX
Agentic AI Use Case- Contract Lifecycle Management (CLM).pptx
PDF
Adobe Illustrator 28.6 Crack My Vision of Vector Design
PPTX
ai tools demonstartion for schools and inter college
PDF
Design an Analysis of Algorithms II-SECS-1021-03
PPTX
Agentic AI : A Practical Guide. Undersating, Implementing and Scaling Autono...
PDF
Which alternative to Crystal Reports is best for small or large businesses.pdf
PDF
How to Choose the Right IT Partner for Your Business in Malaysia
PDF
Understanding Forklifts - TECH EHS Solution
PDF
Raksha Bandhan Grocery Pricing Trends in India 2025.pdf
PDF
PTS Company Brochure 2025 (1).pdf.......
PDF
System and Network Administraation Chapter 3
PDF
Softaken Excel to vCard Converter Software.pdf
PDF
Audit Checklist Design Aligning with ISO, IATF, and Industry Standards — Omne...
Digital Strategies for Manufacturing Companies
How to Migrate SBCGlobal Email to Yahoo Easily
Lecture 3: Operating Systems Introduction to Computer Hardware Systems
Odoo Companies in India – Driving Business Transformation.pdf
Claude Code: Everyone is a 10x Developer - A Comprehensive AI-Powered CLI Tool
ManageIQ - Sprint 268 Review - Slide Deck
2025 Textile ERP Trends: SAP, Odoo & Oracle
Agentic AI Use Case- Contract Lifecycle Management (CLM).pptx
Adobe Illustrator 28.6 Crack My Vision of Vector Design
ai tools demonstartion for schools and inter college
Design an Analysis of Algorithms II-SECS-1021-03
Agentic AI : A Practical Guide. Undersating, Implementing and Scaling Autono...
Which alternative to Crystal Reports is best for small or large businesses.pdf
How to Choose the Right IT Partner for Your Business in Malaysia
Understanding Forklifts - TECH EHS Solution
Raksha Bandhan Grocery Pricing Trends in India 2025.pdf
PTS Company Brochure 2025 (1).pdf.......
System and Network Administraation Chapter 3
Softaken Excel to vCard Converter Software.pdf
Audit Checklist Design Aligning with ISO, IATF, and Industry Standards — Omne...

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.