Introduction to Software Architecture
1
Introduction◦ Background◦ What is software architecture?◦ What’s wrong with the diagram?◦ Software architecture definition
Why is Software Architecture Important?◦ Communication among stakeholders◦ Early design decisions◦ Transferable abstraction of a system
Architectural Structures and Views◦ Module◦ Connector-Component◦ Allocation
2
Think about a situation where we are trying to build a new dog house.
◦ we can build a new one simply by cutting the wood and driving a nail into the wood
3
How about a situation where we have to build a two-storied house?◦ We need
More workers More instruments
◦ We may need to draw a blue-print before constructing the house
4
What if we want to construct a high-rise building◦ Many specialists are involved◦ The high-rise building cannot be built without
careful planning and design Architectures are the key to the successful
construction of the building
planning design construction5
Analogy◦ As the size and complexity of software systems
increases, the design of overall system structure-software architecture- become more significant issues than the choice of algorithms and data structures of computation.
◦ Structural issues include The organization of a system as a composition of
components The protocols for communications The assignment of functionality to design elements Physical distribution, etc.
6
Controlprocess
(CP)
Noisemodel
(MODN)
Reverbmodel
(MODR)
Prop lossmodel
(MODP)
7
Many things are left unspecified:◦ What is the nature of the elements?◦ What are the responsibilities of the elements?◦ What is the significance of the connections?◦ What is the significance of the layout?
Box and arrow drawings alone are not architectures; rather, they are a starting point
All architectural descriptions require three fundamental things:◦ a drawing - illustrating major parts of systems ◦ a legend - explaining what the graphic representation◦ a prose - describing the drawing
8
9
Perry and Wolf, 1992A set of architectural (or design) elements that have a particular form. Perry and Wolf further distinguish between processing elements, data elements, and connecting elements.
Boehm et al., 1995A software system architecture comprises
A collection of software and system components, connections, and constraints A collection of system stakeholders' need statements A rationale which demonstrates that the components, connections, and constraints
define a system that, if implemented, would satisfy the collection of system stakeholders' need statements.
Clements et al., 1997 The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.
10
Architecture defines major components Architecture defines component relationships
(structures) and interactions Architecture omits content information about
components that does not pertain to their interactions
Behavior of components is a part of architecture insofar as it can be discerned from the point of view of another component
Every system has an architecture (even a system composed of one component)
Architecture defines the rationale behind the components and the structure
Architecture definitions do not define what a component is
Architecture is not a single structure -- no single structure is the architecture
11
A unit of distribution, assembly, deployment, and replacement
Implementing a nontrivial functionality Defined by services it provides and
services it requires◦ Services reveal component’s behavior
only as far as required for assembly Meaningful in context of
◦ architecture◦ Component model and a framework
Not necessarily a single unit of code or a single binary
12
Architecture involves a set of strategic design decisions, rules or patterns that constrain design and construction
CODE
implementation
design
architecture
Architectural decisions are the most fundamental decisions and changing them will have significant ripple effects.
13
Customer Requirements Architecture
Architectural renderings begin to appear after requirements elicitation and analysis◦ typically we iterate between requirements
and analysis
14
User view of problem
Builder’s view of problem
Modules and connections
Algorithms & data
User Model
Requirements
Architecture
Code
ExecutableData layouts, memory maps
DesignMethods data structures
How to describe SA? Abstractly as box-and-line diagrams Accompanying prose
◦ Explain the meaning behind the symbols ◦ Provide some rationale for the specific choice of
components and interactionsEx)“Camelot is based on the client-server model and uses
remote procedure calls …”“We have chosen a distributed, object-oriented
approach to managing information”
Basic Web System
[Orfali 99]
Web ServerWeb Server
HTMLHTMLDocumentsDocuments
BrowserBrowser
Document
Request
applicationapplicationCGI
Web Server
DataBase
Browser
[Conallen 99]
Document
Request
ISAPINSAPI
Java Servlet
ISAPINSAPI
Java Servlet
ASPJSP
ASPJSP
ScriptedPage
ScriptedPage
ScriptedPage
ScriptedPage
ScriptedPage
ScriptedPage
ScriptedPage
HTMLPage
Common Architectural Styles
Dataflow systems◦ Batch sequential◦ Pipes and filters
Call-and-return systems◦ Main program and subroutine◦ OO systems◦ Hierarchical layers
Independent components◦ Communicating process◦ Event systems
Virtual machines◦ Interpreters◦ Rule-based systems
Data-centered systems(Repositories)◦ Databases◦ Hypertext systems◦ Blackboards
A style Components + Connectors + Constraints
◦ Components : Computational components ◦ Connectors : Interactions among components◦ Constraints : How they can be combined
Questions What is the design vocabulary? What are the allowable structural patterns? What is the underlying computational model? What are the essential invariants of the style? What are some common examples of its use? What are the advantages and disadvantages of
using that style? What are some of the common specializations??
Pipe and Filter - 1
Pipe and Filter - 2 Components
◦ Filters Connectors
◦ Pipes Invariants
◦ Filters must be independent entities. Should not share state with other filters
◦ Filters do not know the identity of their upstream and downstream filters
CourseFilter15671
MainFilter MergeFilter
CourseFilter21701
Input File
Output File
Filter File Pipe
Main Program and Subroutines - 1
Main controllerMain controller
Sub 1Sub 2
Sub 3
comp
manager
memmem
Main Program and Subroutines - 2 System model
◦ Call and definition hierarchy ◦ Subsystems often defined via modularity
Components ◦ Procedures and explicitly visible data
Connectors◦ Procedure calls and explicit data sharing
Control◦ Single thread
ADT/Objects - 1
data
methods
data
methodsdata
methods
data
methods
data
methods data
methods
ADT/Objects - 2 Components
◦ Objects(Manager), Instance of ADT Connectors
◦ Function and Procedure calls Invariants
◦ An object is responsible for preserving the integrity of its representation
◦ The representation is hidden from other objects
ADT/Objects - 3 Advantage
◦ Possible to change the implementation without affecting those clients
◦ Allow designers to decompose problems into collections of interacting agents
Disadvantage◦ Must know the identity of that other object◦ Whenever the identity of an object changes it is
necessary to modify all other objects that explicitly invoke
Event Based, Implicit invocation - 1
AA
CC
trigger
announc
e
trigger
trigger
announce
announcee1
e2
DD
BB
Event Based, Implicit invocation - 2 Components
◦ Modules whose interfaces provide both a collection of procedures and a set of events
Connectors◦ Event registration and procedure invocation
Invariants◦ Announcers of events do not know which
components will be affected by those events
Event Based, Implicit invocation - 3 Reactive integration, Selective broadcast
◦ A component can announce one or more events◦ Other components can register an interest in an
event by associating a procedure with it◦ When the event is announced, the system itself
invokes all of the procedures that have been registered for the event
◦ An event announcement implicitly causes the invocation of procedures in other modules
Event Based, Implicit invocation - 3 Usages
◦ Programming environments to integrate tools◦ In database management systems
Ensure consistency constraints◦ In user interfaces to separate presentation of data
from applications that manage data◦ Syntax directed editors◦ Debugger
Layered Systems - 1
Kernel LayerKernel Layer
Resource Management LayerResource Management Layer
System Service LayerSystem Service Layer
Application LayerApplication Layer
Layered Systems - 2 Components
◦ Layers Each layer provides service to the layer above it and
serves as a client to the layer below Connectors
◦ Protocols Constraints
◦ Topological◦ Limit interaction to adjacent layers
Layered Systems - 3 Usage
◦ Communication layer OSI ISO model
◦ Database systems and Operating system Some of the X window system protocols
Repository - 1
RepositoryRepositoryRepositoryRepository
compcomp compcomp compcomp
compcomp compcomp compcomp
Repository – 2 Components
◦ Central data structure Represent the current state,
◦ A collection of independent components Operate on central data store
Repository - 3 Traditional Database
◦ The types of transactions in an input stream trigger selection of processes to execute
Blackboard◦ The current state of the central data structure is
the main trigger for selecting processes to execute
Repository - 4 Blackboard
◦ The knowledge source Separate, independent parcels of application-
dependent knowledge. Interaction among knowledge sources takes place
solely through the blackboard◦ The blackboard data structure
Problem-solving state data Organized into an application-dependent hierarchy
◦ Control Driven by the state of the blackboard Knowledge sources respond opportunistically when
changes in the blackboard make them applicable
Blackboards - 1
Blackboard(shared data)
Blackboard(shared data)
ks ks ks
ks ks ks
ks
ksks
ks
Interpreters - 1
program being interpreted
interpreter control unit
Memory
data (program state)
interpreter execution unit
Interpretation Engine
instruction updatesdata
inputs
outputs
instruction
interpreter state
Interpreters - 2 System model
◦ Virtual machines Components
◦ One state machine and three memories Connectors
◦ Data access and procedure call Control
◦ Usually state transition for execution engine ◦ Input-driven for selection of what to interpret
Rule-based Systems - 1
MemoryMemory
rule scheduler
working memory
rule interpreter
Inference EngineInference Engine
rules and facts updatesdata
inputs
outputs
selected actionselected action
engine state
rules facts
knowledge base
Rule-based Systems - 2 System model
◦ Virtual machines Components
◦ One inference engine and three memories (knowledge base, working memory, and inference engine state)
Connectors ◦ Data access and production rule application
Control◦ Usually state transition for inference engine ◦ Goal-driven for selection of what to interpret
LexLex SynSyn SemSem OptOpt CodeCode
Text Code
Compiler construction - 1Compiler construction - 1
LexLex SynSyn SemSem OptOpt CodeCodeText Code
Sym tabSym tab
LexLex SynSyn SemSem OptOpt CodeCodeText Code
Sym tabSym tab
TreeTree
Compiler construction - 2Compiler construction - 2
LexLex
SynSyn
SemSem
OptOpt
CodeCode
OptOpt
SynSynEditEdit
TreeTree
Sym tabSym tab
Compiler construction - 3Compiler construction - 3
Contents The concept of software architecture Software architecture patterns Building software systems from parts Software Architecture Analysis Discussion
COTS(Commercial Off-The-Shelf) A part of a deployed system Purchased from a vendor Sold in binary form in identical copies Available to general public Example
◦ Windows NT, Netscape Communicator
Stages COTS Market
◦ Examine which products? Selected
◦ Which products are fit? Adapted
◦ Use which features Assembled
◦ Which design best reflects market factors? Refreshed
◦ Version, Upgrading
Problems Code size
◦ Each piece was huge by itself◦ (Ex) Tools had to include X, even if they didn’t
need it Performance
◦ Efficiency can be low Need to modify/understand reused parts in
significant ways◦ Event loop rewrite◦ Memory allocation
52
Architecture assures conceptual integrity while allowing change ◦ New requirements◦ Changed requirements ◦ Technology churn
Architecture supports system longevity
53
“Divide and conquer”◦ Decomposition into components◦ Hiding of implementation details
Separation of concerns ◦ Components (and layers) encapsulate
details◦ Different components can be implemented
by people with different expertise
54
Architecture iterations remove major risks
Architecture prototypes allow for collection of metrics ◦ Development cost metrics◦ Schedule metrics
55
Well componentized systems support better and easier ◦ Diagnostics ◦ Traceability◦ Error detection
Testing is use-case driven
56
Architecture defines rules of substitution
Component interfaces define substitution boundaries
Architecture enables different granularity of reuse ◦ Small-scale reuse at component level◦ Large-scale reuse
Subsystems Products Frameworks
57
architecture supports communication between stakeholders
Different views address different stakeholder concerns
architecture communicates key design decisions
architecture design rationale communicates the tradeoffs
58
Organizational structure aligned with architecture ◦ Development team(s)◦ Subcontractors
Components/subsystems used as units of ◦ Development◦ CM◦ Testing◦ Delivery and upgrade
Components/subsystems developed concurrently
59
Software Requirements and Specifications, Michael Jackson, 1995 Software
Software Architecture: Perspectives on an Emerging Discipline, Shaw & Garlan, 1996
Architecture in Practice, Bass, Clements, & Kazman, 1998