Software Engineering 1 N.L. Hsueh, SE-Lab IECS FCU Software Architecture N.L. Hsueh

Software Engineering

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

Software Architecture

N.L. Hsueh



Outline

Basic Concept Architecture Styles

Control models Modular decomposition Domain-specific architectures Design Pattern



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



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



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



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



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



Architectural Style



1. Main Program With Subroutines



Control

Input Shift Sort Output

store shifts sorted

outputProcedure call

Access to data structure

i/o

input



2. Abstract Data Type

Control

Input

Store Shift Sort

Output

outputoutput



Store initialStore: PutChar(r,w,c,d): CloseStore: it is called after all inputlines have been store

d 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()



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

Sort iniSort getIndex(w)



3. Implicit Invocation

Control

Input MakeShift Sort Output

Store Shift output

Implicit call

input

The MakeShift module is no explicitly called



4. Pipe and Filter

Input Shift Sort Output

input output



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



Conti.



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



6. Layered



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



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



Control Model



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



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.



Call-return model

Routine 1.2Routine 1.1 Routine 3.2Routine 3.1

Routine 2 Routine 3Routine 1

Mainprogram



A centralized control model for a real-time

system control

Systemcontroller

Userinterface

Faulthandler

Computationprocesses

Actuatorprocesses

Sensorprocesses



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



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 m1.registerTo(m2) m2 receive an event m2 will call m1

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



Broadcasting

Sub-system1

Event and message handler

Sub-system2

Sub-system3

Sub-system4



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



Interrupt-driven control

Handler1

Handler2

Handler3

Handler4

Process1

Process2

Process3

Process4

Interrupts

Interruptvector



Modular Decomposition



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



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



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



Invoice processing system

IssueSend reminderAccept paymentSend receipt

invoice #dateamountcustomer

Invoice

customer #nameaddresscredit period

Customer

invoice #dateamountcustomer #

Receipt

invoice #dateamountcustomer #

Payment



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



Invoice processing system

Read issuedinvoices

Identifypayments

Issuereceipts

Findpayments

due

Receipts

Issuepaymentreminder

Reminders

Invoices Payments



Domain-Specific Architecture



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 systemsMay 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 architecturesUsed to communicate domain concepts and compare

possible architecture

Top-down models



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



A data-flow model of a compiler

Lexicalanalysis

Syntacticanalysis

Semanticanalysis

Codegeneration

Symboltable



The repository model of a language processing

system

Syntaxanalyser

Lexicalanalyser

Semanticanalyser

Abstractsyntax tree

Grammardefinition

Symboltable

Outputdefinition

Pretty-printer

Editor

Optimizer

Codegenerator

Repository



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



OSI reference model

Application

Presentation

Session

Transport

Network

Data link

Physical

7

6

5

4

3

2

1

Communica tions medium

Network

Data link

Physical

Application

Presentation

Session

Transport

Network

Data link

Physical



Design Pattern



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



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



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



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 wh

at 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



Types of software patterns

Analysis Design Organizational Process Project Planning Configuration Management



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 concept

s 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 lang

uage constructs



Design Pattern Level of Abstraction

Complex design for an entire application or subsystem

Solution to a general design problem in a particular context

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

More concrete

More abstract



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.”



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 PatternsFocus on the relationships between classes and their subclasses Involve inheritance reuse

Object PatternsFocus on the relationships between objects Involve composition reuse



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



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




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




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



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



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



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

R. Pressman

Documents

Software Engineering 1 N.L. Hsueh, SE-Lab IECS FCU Software Architecture N.L. Hsueh