Software Engineering Chapter 11 Architectural Design

1
Software Engineering Chapter 11Architectural
Design

• Ku-Yaw Chang
• canseco_at_mail.dyu.edu.tw
• Assistant ProfessorDepartment of Computer
  Science and Information Engineering
• Da-Yeh University

2
Objectives

• Understand why the architectural design of
  software is important
• Understand the decisions that have to be made
  about the system architecture during the
  architectural design process
• Have been introduced to three complementary
  architectural styles covering the overall system
  organization, modular decomposition and control
• Understand how reference architectures are used
  to communicate architectural concepts and to
  access system architectures

3
Preamble

• Large system are always decomposed into
  sub-systems
• Provide some related set of services
• Architectural design
• Identifying these sub-systems
• Establish a framework for sub-system control and
  communication
• A critical link between the design and
  requirements engineering processes

4
Preamble

• Three advantages
• Stakeholder communication
• A high-level presentation of the system
• System analysis
• Required for making the system architecture
  explicit
• Large-scale reuse
• A compact, manageable description
• How a system is organized
• How the components interoperate

5
Preamble

• The system architecture affects non-functional
  system requirements
• Performance
• Localize critical operation
• As little communication as possible
• Security
• A layered structure
• Availability
• Redundant components
• Maintainability
• Fine-grain, self-contained components

6
Block diagram

• Simple box-and-line diagram
• Very abstract
• Not show
• The nature of component relationships
• The externally visible properties of the
  sub-systems.
• Useful for communication with stakeholders and
  for project planning
• Not the only architectural representation
• One of useful architectural models

7
Packing robot control system
8
Contents

• 11.1 Architectural design decisions
• 11.2 System organization
• 11.3 Modular decomposition styles
• 11.4 Control styles
• 11.5 Reference architectures

9
Architectural design decisions

• Architectural design
• A creative process
• To establish a system organization that will
  satisfy the functional and non-functional system
  requirements
• System architects
• Make a number of fundamental decisions
• Profoundly affect the system and its development
  process

10
Architectural design decisions

• Is there a generic application architecture that
  can act as a template for the system that is
  being designed?
• How will the system be distributed across a
  number of processors?
• What architectural style or styles are
  appropriate for the system?
• What will be the fundamental approach used to
  structure the system?

11
Architectural design decisions

• How will the structural units in the system be
  decomposed into modules?
• What strategy will be used to control the
  operation of the units in the system?
• How will the architectural design be evaluated?
• How should the architecture of the system be
  documented?

12
Architectural design decisions

• Systems in the same application domain
• Have similar architectures that reflects the
  fundamental domain concepts
• A system architecture
• May be based on a particular architectural model
  or style
• Client-server organization
• Layered architecture
• May be a composite architecture
• Combine different architectural styles

13
Architectural design decisions

• Architectural models may include
• A static structural model
• Sub-systems or components as separate units
• A dynamic process model
• Organized into process at run-time
• An interface model
• Define the services offered by public interfaces
• A relationship model
• Relationship between sub-systems
• A distributed model
• Be distributed across computers

14
Contents

• 11.1 Architectural design decisions
• 11.2 System organization
• 11.3 Modular decomposition styles
• 11.4 Control styles
• 11.5 Reference architectures

15
System Organization

• Three organizational styles that are widely used
• A shared data repository style
• A shared service and servers style
• An abstract machine or layered style
• The above styles can be used separately or
  together

16
The Repository Model

• Sub-systems must exchange information so that
  they can work together effectively
• Shared data is held in a central database or
  repository and may be accessed by all sub-systems
• A system model based on a shared database is
  sometimes called a repository model
• The repository is passive.
• Each sub-system maintains its own database and
  passes data explicitly to other sub-systems

17
CASE Toolset Architecture
18
The Client-Server Model

• The system is organized as
• A set of services
• Associated servers and clients
• Access and use the services
• Major components
• A set of servers
• Offer services to other sub-systems
• A set of clients
• Call on the services
• A network
• Allow the clients to access the services

19
Film and Picture Library
20
The Layered Model

• Organize a system into layers
• Each provide a set of services
• Each layer can be thought of as an abstract
  machine
• Also called an abstract machine model
• Incremental development of sub-systems in
  different layers
• When a layer interface changes, only the adjacent
  layer is affected.
• An example the OSI reference model of network
  protocol

21
OSI Reference Model
22
Version Management System
23
Contents

• 11.1 Architectural design decisions
• 11.2 System organization
• 11.3 Modular decomposition styles
• 11.4 Control styles
• 11.5 Reference architectures

24
Modular Decomposition Styles

• After system organization
• Decompose sub-systems into modules
• No rigid distinction between system organization
  and modular decomposition
• A sub-system
• Does not depend on the services provided by other
  sub-systems
• A module
• Provide one or more services to other modules

25
Modular Decomposition Styles

• Two strategies
• Object-oriented decomposition
• A set of communicating objects
• Function-oriented decomposition
• Functional modules
• Accept input data
• Transform it into output data

26
Object-Oriented Decomposition

• Structure the system into
• A set of loosely-coupled objects with
  well-defined interfaces
• Advantages
• Be modified without affecting other objects
• Readily understandable
• Representations of real-world entities
• Reuse

27
Invoice Processing System
28
Function-Oriented Pipelining

• Functional transformations process their inputs
  to produce outputs
• May be referred to as a pipe and filter model (as
  in UNIX shell)
• Not really suitable for interactive systems

29
A Pipeline Model
30
Contents

• 11.1 Architectural design decisions
• 11.2 System organization
• 11.3 Modular decomposition styles
• 11.4 Control styles
• 11.5 Reference architectures

31
Control Styles

• Sub-systems must be controlled
• Two generic control styles
• Centralized control
• One sub-system has overall responsibility for
  control
• Event-based control
• Each sub-system can respond to externally
  generated events

32
Centralized Control

• One sub-system is designated as the system
  controller
• Manage the execution
• Two classes
• Call-return model
• Manager model

33
The Call-Return Model
34
The Manager Model
35
Event-Driven System

• An event vs. an input
• The timing of the event is outside the control of
  the process that handles that event
• Two event-driven control models
• Broadcast models
• Different computers on a network
• Interrupt-driven models
• Real-time systems

36
A Broadcast Model
37
An Interrupt-Driven Model
38
Contents

• 11.1 Architectural design decisions
• 11.2 System organization
• 11.3 Modular decomposition styles
• 11.4 Control styles
• 11.5 Reference architectures

39
The End