Software Engineering Chapter 11 Architectural Design - PowerPoint PPT Presentation

Loading...

PPT – Software Engineering Chapter 11 Architectural Design PowerPoint presentation | free to view - id: 78d844-NTczN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Software Engineering Chapter 11 Architectural Design

Description:

Software Engineering Chapter 11 Architectural Design Ku-Yaw Chang canseco_at_mail.dyu.edu.tw Assistant Professor Department of Computer Science and Information Engineering – PowerPoint PPT presentation

Number of Views:136
Avg rating:3.0/5.0
Slides: 40
Provided by: KuY3
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Software Engineering Chapter 11 Architectural Design


1
Software Engineering Chapter 11 Architectural
Design
  • Ku-Yaw Chang
  • canseco_at_mail.dyu.edu.tw
  • Assistant Professor Department 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
About PowerShow.com