Architecture

Software Engineering

Software Architecture

N.L. Hsueh

1
N.L. Hsueh, SE-Lab IECS FCU


Outline

 Basic Concept
 Architecture Styles

 Control models
 Modular decomposition
 Domain-specific architectures
 Design Pattern

2


Basic Concept

 The architecture of a system is a comprehensive framework
that describes its form and structure – its components and
how they fit together

 A bad architectural design for a building cannot be rescued
by good construction; the same is true for software

 There are styles of building and software architecture

3


Architectural design process

 System structuring
 The system is decomposed into several principal sub-
systems and communications between these sub-
systems are identified
 Control modelling
 A model of the control relationships between the
different parts of the system is established
 Modular decomposition
 The identified sub-systems are decomposed into
modules

4


Sub-systems and modules

 A sub-system is a system in its own right whose operation is
independent of the services provided by other sub-systems.
 A module is a system component that provides services to
other components but would not normally be considered as
a separate system

5


Architectural models

 Structure, control and modular decomposition may be based
on a particular model or architectural style

 However, most systems are heterogeneous in that different
parts of the system are based on different models and, in
some cases, the system may follow a composite model

 The architectural model used affects the performance,
robustness, distributability and maintainability of the system

6


System structuring

 Concerned with decomposing the system into interacting
sub-systems

 The architectural design is normally expressed as a block
diagram presenting an overview of the system structure

 More specific models showing how sub-systems share
data, are distributed and interface with each other may
also be developed

7


Architectural Style

8


1. Main Program With Subroutines

9


Control

Input Shift Sort Output

store shifts sorted

input
output
Procedure call
Access to data structure
i/o
10


2. Abstract Data Type

Control

Input Output

Store Shift Sort

output
output

11


 Store
 initialStore:
 PutChar(r,w,c,d):
 CloseStore: it is called after all inputlines have been
stored through successive calls of PutChar()

Lines(): delivers the number of lines stores
 Words(r)
 Chars(r,w)
 Char(r,w,c)

 Input
 Call Store.initialStore()
 Read from input and call PutChar(…)
 Call CloseStore()

12


 Shift
ShiftLines()

 ShiftWords(l)
 ShiftChars(l,w)
 ShiftChar(l,w,c)

 Sort
 iniSort
 getIndex(w)

13


3. Implicit Invocation

Control

Input MakeShift Sort Output

input Store Shift output

Implicit call The MakeShift module is
no explicitly called
14


4. Pipe and Filter

Input Shift Sort Output

input output

15


5. Repository

 Sub-systems must exchange data. This may be done in two
ways:
 Shared data is held in a central database or repository
and may be accessed by all sub-systems
 Each sub-system maintains its own database and
passes data explicitly to other sub-systems

 When large amounts of data are to be shared, the repository
model of sharing is most commonly used

16


Conti.

17


Conti.

 Advantages
 Efficient way to share large amounts of data
 Sub-systems need not be concerned with how data is
produced
 Centralized management e.g. backup, security, etc.
 Sharing model is published as the repository schema

 Disadvantages
 Sub-systems must agree on a repository data model.
Inevitably a compromise
 Data evolution is difficult and expensive

18


6. Layered

19


7. Client-server

 Distributed system model which shows how data and
processing is distributed across a range of components
 Set of stand-alone servers which provide specific services
such as printing, data management, etc.
 Set of clients which call on these services
 Network which allows clients to access servers

20


Conti.

 Advantages
 Distribution of data is straightforward
 Makes effective use of networked systems
 Easy to add new servers or upgrade existing servers
 Disadvantages
 No shared data model so sub-systems use different
data organization.
 Data interchange may be inefficient
 No central register of names and services - it may be
hard to find out what servers and services are available

21


Control Model

22


Control models

 Are concerned with the control flow between sub-
systems.
 Distinct from the system decomposition model

 Centralized control
 One sub-system has overall responsibility for control
and starts and stops other sub-systems

 Event-based control
 Each sub-system can respond to externally generated
events from other sub-systems or the system’s
environment

23


1. Centralized control

 A control sub-system takes responsibility for managing the
execution of other sub-systems
 Call-return model
 Top-down subroutine model
 Control starts at the top of a subroutine hierarchy and
moves downwards.
 Applicable to sequential systems
 Manager model
 One system component controls the stopping, starting
and coordination of other system processes.
 Applicable to concurrent systems.

24


Call-return model

M ain
program

Routine 1 Routine 2 Routine 3

Routine 1.1 Routine 1.2 Routine 3.1 Routine 3.2

25

A centralized control model for
a real-time system control

Sensor Actuator
processes processes

System
controller

Computation User Fault
processes interface handler

26


2. Event-driven systems

 Driven by externally generated events where the timing of
the event is outside the control of the sub-systems which
process the event
 In centralized control models, control decisions are
usually determined by the value of some system state
variables
 Two principal event-driven models
 Broadcast models. An event is broadcast to all sub-
systems. Any sub-system which can handle the event
may do so
 Interrupt-driven models. Used in real-time systems
where interrupts are detected by an interrupt handler
and passed to some other component for processing

27


Broadcast model

 Effective in integrating sub-systems on different computers
in a network
 Sub-systems register an interest in specific events. When
these occur, control is transferred to the sub-system which
can handle the event
 Control policy is not embedded in the event and message
handler. Sub-systems decide on events of interest to
them
 However, sub-systems don’t know when an event will be
handled

Sub-system K
Sub-system K
m1.registerTo(m2)
m1.registerTo(m2)
m2 receive an event
m2 receive an event
m2 will call m1
m2 will call m1
28


Broadcasting

Sy
us
bt
- e
s m Sy
us
bt
- e
s m Sy
us
bt
- e
s m Sy
us
bt
- e
s m
1 2 3 4

E am enr
v n eg d
e ds hl
n
t s ae
a

29


Interrupt-driven systems

 Used in real-time systems where fast response to an event
is essential
 There are known interrupt types with a handler defined for
each type
 Each type is associated with a memory location and a
hardware switch causes transfer to its handler
 Allows fast response but complex to program and difficult to
validate

30


Interrupt-driven control
Interrupts

Interrupt
vector

Handler Handler Handler Handler
1 2 3 4

Process Process Process Process
1 2 3 4

31


Modular Decomposition

32


The problem that they have to deal with are
complex, …, software engineers cannot reduce
this complexity. However, it can be funneled
and confined within weakly coupled closed
areas. By judicious segmentation of the state
space, the system is made easier

33


Modular decomposition

 Sub-systems are decomposed into modules

 Two modular decomposition models covered
 An object model where the system is decomposed
into interacting objects
 A data-flow model where the system is decomposed
into functional modules which transform inputs to
outputs. Also known as the pipeline model
 If possible, decisions about concurrency should be delayed
until modules are implemented

34


Object models

 Structure the system into a set of loosely coupled objects
with well-defined interfaces
 Object-oriented decomposition is concerned with identifying
object classes, their attributes and operations
 When implemented, objects are created from these classes
and some control model used to coordinate object
operations
 Adv:
 loosely coupled: the implementation of objects can be
modified without affecting other objects
 Easily modeled: objects are often representations of
real-world entities

35


Invoice processing system

Customer Receipt
customer # invoice #
name date
address Invoice amount
credit period customer #
invoice #
date
amount
customer
Payment Issue
invoice # Send reminder
date Accept payment
amount Send receipt
customer #

36


Data-flow models

 Functional transformations process their inputs to produce outputs
 May be referred to as a pipe and filter model (as in UNIX shell)
 Variants of this approach are very common. When transformations
are sequential, this is a batch sequential model which is extensively
used in data processing systems
 Not really suitable for interactive systems
 Adv.
 It supports the reuse of transformations
 It is intuitive in that many people think of their work in terms of
input and output processing
 Evolving the system by adding new transformations is usually
straightforward
 It is simple to implement either as a concurrent or a
sequential system

37


Invoice processing system

Issue
Receipts
receipts

R issued
ead Identify
invoices paym ents
Find Issue
pa e
ym nts pa e
ym nt R inders
em
due rem inder
Invoices Paym nts
e

38


Domain-Specific Architecture

39


Domain-specific architectures

 Architectural models which are specific to some application
domain
 Two types of domain-specific model
 Generic models which are abstractions from a number
of real systems and which encapsulate the principal
characteristics of these systems
 May be reused directly in a design
 Bottom-up models
 Reference models which are more abstract, idealized
model. Provide a means of information about that class
of system and of comparing different architectures
 Used to communicate domain concepts and compare
possible architecture
 Top-down models

40


Generic models

 Compiler model is a well-known example although other
models exist in more specialized application domains
 Lexical analyzer
 Symbol table
 Syntax analyzer
 Syntax tree
 Semantic analyzer
 Code generator
 Generic compiler model may be organized according to
different architectural models

41


A data-flow model of a compiler

Sym bol
table

Lexical Syntactic Semantic Code
analysis analysis analysis generation

42

The repository model of a language
processing system

Lexical Syntax Semantic
analyser analyser analyser

Pretty- Abstract Grammar
printer syntax tree definition Optimizer

Symbol Output Code
Editor
table definition generator

Repository

43


Reference architectures

 Reference models are derived from a study of the
application domain rather than from existing systems

 May be used as a basis for system implementation or to
compare different systems. It acts as a standard against
which systems can be evaluated

 OSI model is a layered model for communication systems

44


OSI reference model

7 A p c ti n
p li a o A p c ti n
p li a o

6 Pe e t t n
r s naio Pe e t t n
r s naio

5 S ss n
e io S ss n
e io

4 Ta sp r
r n ot Ta sp r
r n ot

3 Ntw rk
e o Ntw rk
e o Ntw rk
e o

2 Dtal k
a in Dtal k
a in Dt ln
aa i k

1 P y ic l
hs a P y ic l
hs a P y ic l
hs a
C m u ic o s md m
o mn ati n e iu

45


Design Pattern

46


我們不只要做絲襪 , 我們要做 ‘超彈性’絲襪

47


What is a Pattern?

 Current use comes from the work of the
architect Christopher Alexander
 Alexander studied ways to improve the
process of designing buildings and urban
areas
 “Each pattern is a three-part rule, which
expresses a relation between a certain
context, a problem and a solution.”
 Hence, the common definition of a pattern:
“A solution to a problem in a context.”
 Patterns can be applied to many different
areas of human endeavor, including software
development

48


Why Pattern?

 "Designing object-oriented software is hard and designing reusable
object-oriented software is even harder." - Erich Gamma
 Experienced designers reuse solutions that have worked in the past
 Well-structured object-oriented systems have recurring patterns of
classes and objects
 Knowledge of the patterns that have worked in the past allows a
designer to be more productive and the resulting designs to be more
flexible and reusable

49


History

 1987 - Cunningham and Beck used Alexander’s ideas to develop a
small pattern language for Smalltalk
 1990 - The Gang of Four (Gamma, Helm, Johnson and Vlissides)
begin work compiling a catalog of design patterns
 1991 - Bruce Anderson gives first Patterns Workshop at OOPSLA
 1993 - Kent Beck and Grady Booch sponsor the first meeting of
what is now known as the Hillside Group
 1994 - First Pattern Languages of Programs (PLoP) conference
 1995 - The Gang of Four (GoF) publish the Design Patterns book

50


Types of software patterns

 Analysis
 Design
 Organizational
 Process
 Project Planning
 Configuration Management

51


Types of software patterns

 Riehle and Zullighoven in “Understanding and Using Patterns in
Software Development” mention three types of software patterns
 Conceptual Pattern
 Pattern whose form is described by means of terms and concepts
from the application domain
 Design Pattern
 Pattern whose form is described by means of software design
constructs, such as objects, classes, inheritance and aggregation
 Programming Pattern (Programming Idiom)
 Pattern whose form is described by means of programming
language constructs

52


Design Pattern Level of Abstraction

 Complex design for an entire
application or subsystem

More abstract
 Solution to a general design
problem in a particular context
More concrete

 Simple reusable design class
such as a linked list, hash
table, etc.

53


GoF Design Patterns

 The GoF design patterns are in the middle of these levels of
abstraction
 “A design pattern names, abstracts, and identifies key aspects of a
common design structure that makes it useful for creating a reusable
object-oriented design.”
 The GoF design patterns are “descriptions of communicating
objects and classes that are customized to solve a general design
problem in a particular context.”

54


GoF Classification Of Design Patterns

 Purpose - what a pattern does
 Creational Patterns
 Concern the process of object creation
 Structural Patterns
 Deal with the composition of classes and objects
 Behavioral Patterns
 Deal with the interaction of classes and objects
 Scope - what the pattern applies to
 Class Patterns
 Focus on the relationships between classes and their subclasses
 Involve inheritance reuse
 Object Patterns
 Focus on the relationships between objects
 Involve composition reuse
55


GoF Essential Elements Of Design Patterns

 Pattern Name
 Having a concise, meaningful name for a pattern improves
communication among developers
 Problem
 What is the problem and context where we would use this pattern?
 What are the conditions that must be met before this pattern should be
used?
 Solution
 A description of the elements that make up the design pattern
 Emphasizes their relationships, responsibilities and collaborations
 Not a concrete design or implementation; rather an abstract description

 Consequences
 The pros and cons of using the pattern
 Includes impacts on reusability, portability, extensibility

56


GoF Pattern Template

 Structure
A graphical representation of the pattern
 Participants
 The classes and objects participating in the pattern

 Collaborations
 How to do the participants interact to carry out their
responsibilities?
 Consequences
 What are the pros and cons of using the pattern?

 Implementation
 Hints and techniques for implementing the pattern

57



 Pattern Name and Classification
A good , concise name for the pattern and the pattern's type
 Intent
 Short statement about what the pattern does

 Also Known As
 Other names for the pattern

 Motivation
 A scenario that illustrates where the pattern would be useful

 Applicability
 Situations where the pattern can be used

58



 Sample Code
Code fragments for a sample implementation


 Known Uses
 Examples of the pattern in real systems

 Related Patterns
 Other patterns that are closely related to the pattern

59


Key points

 The software architect is responsible for deriving a structural
system model, a control model and a sub-system
decomposition model

 System decomposition models include repository models,
client-server models and abstract machine models

 Control models include centralised control and event-driven
models

60


Key points

 Modular decomposition models include data-flow and object
models
 Domain specific architectural models are abstractions over
an application domain. They may be constructed by
abstracting from existing systems or may be idealised
reference models

61


The architectural model provides a Gestalt view
of a system, allowing the software engineering
to examine it as a whole

R. Pressman

62

Architecture

Recommended

Recommended

More Related Content

Similar to Architecture

Similar to Architecture (20)

Recently uploaded

Recently uploaded (20)

Architecture