Software Engineering
1N.L. Hsueh, SE-Lab IECS FCU
Software Architecture
N.L. Hsueh
Software Engineering
2N.L. Hsueh, SE-Lab IECS FCU
Outline
Basic Concept Architecture Styles
Control models Modular decomposition Domain-specific architectures Design Pattern
Software Engineering
3N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
4N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
5N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
6N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
7N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
8N.L. Hsueh, SE-Lab IECS FCU
Architectural Style
Software Engineering
9N.L. Hsueh, SE-Lab IECS FCU
1. Main Program With Subroutines
Software Engineering
10N.L. Hsueh, SE-Lab IECS FCU
Control
Input Shift Sort Output
store shifts sorted
outputProcedure call
Access to data structure
i/o
input
Software Engineering
11N.L. Hsueh, SE-Lab IECS FCU
2. Abstract Data Type
Control
Input
Store Shift Sort
Output
outputoutput
Software Engineering
12N.L. Hsueh, SE-Lab IECS FCU
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()
Software Engineering
13N.L. Hsueh, SE-Lab IECS FCU
Shift ShiftLines() ShiftWords(l) ShiftChars(l,w) ShiftChar(l,w,c)
Sort iniSort getIndex(w)
Software Engineering
14N.L. Hsueh, SE-Lab IECS FCU
3. Implicit Invocation
Control
Input MakeShift Sort Output
Store Shift output
Implicit call
input
The MakeShift module is no explicitly called
Software Engineering
15N.L. Hsueh, SE-Lab IECS FCU
4. Pipe and Filter
Input Shift Sort Output
input output
Software Engineering
16N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
17N.L. Hsueh, SE-Lab IECS FCU
Conti.
Software Engineering
18N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
19N.L. Hsueh, SE-Lab IECS FCU
6. Layered
Software Engineering
20N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
21N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
22N.L. Hsueh, SE-Lab IECS FCU
Control Model
Software Engineering
23N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
24N.L. Hsueh, SE-Lab IECS FCU
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.
Software Engineering
25N.L. Hsueh, SE-Lab IECS FCU
Call-return model
Routine 1.2Routine 1.1 Routine 3.2Routine 3.1
Routine 2 Routine 3Routine 1
Mainprogram
Software Engineering
26N.L. Hsueh, SE-Lab IECS FCU
A centralized control model for a real-time
system control
Systemcontroller
Userinterface
Faulthandler
Computationprocesses
Actuatorprocesses
Sensorprocesses
Software Engineering
27N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
28N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
29N.L. Hsueh, SE-Lab IECS FCU
Broadcasting
Sub-system1
Event and message handler
Sub-system2
Sub-system3
Sub-system4
Software Engineering
30N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
31N.L. Hsueh, SE-Lab IECS FCU
Interrupt-driven control
Handler1
Handler2
Handler3
Handler4
Process1
Process2
Process3
Process4
Interrupts
Interruptvector
Software Engineering
32N.L. Hsueh, SE-Lab IECS FCU
Modular Decomposition
Software Engineering
33N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
34N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
35N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
36N.L. Hsueh, SE-Lab IECS FCU
Invoice processing system
IssueSend reminderAccept paymentSend receipt
invoice #dateamountcustomer
Invoice
customer #nameaddresscredit period
Customer
invoice #dateamountcustomer #
Receipt
invoice #dateamountcustomer #
Payment
Software Engineering
37N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
38N.L. Hsueh, SE-Lab IECS FCU
Invoice processing system
Read issuedinvoices
Identifypayments
Issuereceipts
Findpayments
due
Receipts
Issuepaymentreminder
Reminders
Invoices Payments
Software Engineering
39N.L. Hsueh, SE-Lab IECS FCU
Domain-Specific Architecture
Software Engineering
40N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
41N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
42N.L. Hsueh, SE-Lab IECS FCU
A data-flow model of a compiler
Lexicalanalysis
Syntacticanalysis
Semanticanalysis
Codegeneration
Symboltable
Software Engineering
43N.L. Hsueh, SE-Lab IECS FCU
The repository model of a language processing
system
Syntaxanalyser
Lexicalanalyser
Semanticanalyser
Abstractsyntax tree
Grammardefinition
Symboltable
Outputdefinition
Pretty-printer
Editor
Optimizer
Codegenerator
Repository
Software Engineering
44N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
45N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
46N.L. Hsueh, SE-Lab IECS FCU
Design Pattern
Software Engineering
47N.L. Hsueh, SE-Lab IECS FCU
我們不只要做絲襪 , 我們要做 ‘超彈性’絲襪
Software Engineering
48N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
49N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
50N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
51N.L. Hsueh, SE-Lab IECS FCU
Types of software patterns
Analysis Design Organizational Process Project Planning Configuration Management
Software Engineering
52N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
53N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
54N.L. Hsueh, SE-Lab IECS FCU
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.”
Software Engineering
55N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
56N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
57N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
58N.L. Hsueh, SE-Lab IECS FCU
GoF Pattern Template
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
Software Engineering
59N.L. Hsueh, SE-Lab IECS FCU
GoF Pattern Template
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
Software Engineering
60N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
61N.L. Hsueh, SE-Lab IECS FCU
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
Software Engineering
62N.L. Hsueh, SE-Lab IECS FCU
The architectural model provides a Gestalt view of a system, allowing the software engineering to examine it as a whole
R. Pressman