![Page 1: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/1.jpg)
Software Architecture
CSCI 5801: Software Engineering
![Page 2: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/2.jpg)
Software Architecture
![Page 3: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/3.jpg)
Software Architecture
Architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution
(from IEEE Standard on the Recommended Practice for Architectural Descriptions, 2000.)
![Page 4: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/4.jpg)
Decomposition
• Main goal: Decompose overall system into components connected by interfaces– Component simple enough to be implemented by
smaller teams– Interfaces well defined enough to allow
independent development
• Architecture: shows components of a system and their interface relationships
![Page 5: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/5.jpg)
UML for Components
• Node– Physical device (computer,
sever, etc) which is part of system
• Component– Significant subsystem that
implements an interface
• Package– Submodule of a component, such as
a set of related classes
![Page 6: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/6.jpg)
UML for Interfaces
• Component 1 implements Interface, with methods Operation1 and Operation2
• Component 2 communicates with Component 1 through that interface by calling those methods
![Page 7: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/7.jpg)
UML Example
• Client-server system:– A client computer running a browser communicates with a
server running Tomcat through the GET and POST protocols– The Tomcat server uses JSPs, control servlets, and business
logic classes
![Page 8: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/8.jpg)
Physical Architectures
• Highest levels of architecture often determined by physical location and other restrictions (such as security)
• Interfaces then designed to enable communication
![Page 9: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/9.jpg)
Additional UML for Design
• Sequence diagrams also common in design• Specify data flow between major components
of system instead of between system and users
• Can also specify methods called and data passed/returned
![Page 10: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/10.jpg)
Sequence Diagrams
User
Login Logic
WithdrawInterface
Withdraw Logic
Account Database
Accountdatabase
AccountObject
constructconstruct
constructIDID
IDquery
account dataaccount data
construct
ID, type
accountType, amount
withdraw (accountType, amount)
hasAccount
account data
[1] withdraw (amount)
[2] IllegalAmount
[3] Error message
[3] InsufficientBalance[3] Insufficient
Balance [1] setBalance (amount, accountType)
[1] update
[2] Error message
[3] Confirmation message
![Page 11: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/11.jpg)
Role of the Client
• Client usually involved in high-level architecture design– Architecture (particularly physical) affects cost– Not involved at lower level (class design, etc.)
• Usual step: present high-level architecture to client for approval– Can be done at requirements stage
• No fixed representation (like UML) for this– Whatever the client might best understand
![Page 12: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/12.jpg)
Example Architecture
![Page 13: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/13.jpg)
Example Architecture
![Page 14: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/14.jpg)
Example Architecture
![Page 15: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/15.jpg)
Example Architecture
![Page 16: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/16.jpg)
Iterative Decomposition
• Decomposition done iteratively– System network of components– Component set of packages– Package set of classes …
• Key idea: – A subteam responsible for a module can make own
decisions about how to best decompose that module– Only restriction: Must make sure module
implements required interface
![Page 17: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/17.jpg)
Iterative Decomposition Example
• Overall team decides on client-server architecture
• Web server team decides on model-view-control paradigm
• Web design subteam creates template page and derives all pages from it
![Page 18: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/18.jpg)
Decomposition Methods
• Functional decomposition• Data-driven decomposition• Object-oriented decomposition• Process-oriented decomposition• Event-oriented decomposition• And many others…
• Often influence overall system architecture
![Page 19: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/19.jpg)
Functional Decomposition
• Indentify top-level functions than meet requirements• Decompose into simpler subfunctions (looking for
reuse)Requirement Requirement
Requirement
FunctionFunction
Sub-function Sub-function Sub-function
Sub-function Sub-function Sub-function
![Page 20: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/20.jpg)
Data-driven Decomposition
• Identify major data system needs to store– Decompose into simpler components– Identify what components might be stored where
Section
Course Info
Time Instructor Room
Days Hours
Roster
Students
Course Inventory Roster Database
Student Database
![Page 21: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/21.jpg)
Object-oriented Decomposition
• Combines data-driven decomposition and functional attributes– Each class contains all methods needed to
manipulate its data– Packages are sets of classes– Classes can implement an interface
• Object-oriented decomposition concerned with identifying object classes, their attributes and operations
![Page 22: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/22.jpg)
Process-oriented Decomposition
• Decompose requirements into series of steps• Design component for each step (looking for
reuse among different requirements)
Process step A Process step B
Process step C Process step D Process step E
Process step F
Requirement
Requirement
![Page 23: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/23.jpg)
Event-driven Decomposition
• Identify main external signals system must handle
• Create a component for each
Handler1
Handler2
Handler3
Handler4
Process1
Process2
Process3
Process4
Interrupts
Interruptvector
![Page 24: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/24.jpg)
Design and Reuse
• Most architecture based on existing systems– Most good design ideas have already been created
• Overall architectures based on common styles• Components based on design patterns
![Page 25: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/25.jpg)
Common Architectural Styles
• Centralized control• Layered• Distributed objects• Repository • Pipelining• Client/Server• Event-driven
![Page 26: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/26.jpg)
Centralized Control
• A control component manages the execution of other components
• Call-return model– Top-down subroutine model where control starts at
the top of a subroutine hierarchy and moves downwards.
• Manager model– Applicable to concurrent systems. One system
component controls the stopping, starting and coordination of other system processes.
![Page 27: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/27.jpg)
Call-return Model
Routine 1.2Routine 1.1 Routine 3.2Routine 3.1
Routine 2 Routine 3Routine 1
Mainprogram
![Page 28: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/28.jpg)
Manager Model
Systemcontroller
Userinterface
Faulthandler
Computationprocesses
Actuatorprocesses
Sensorprocesses
![Page 29: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/29.jpg)
Centralized Control
• Advantages:– Simple to implement, debug as all actions can be
traced to single point
• Disadvantages:– Centralized control must be error free– Can become overwhelmed in concurrent systems
![Page 30: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/30.jpg)
Layered Model
• System organized into layers of components• Each layer only communicates with previous
and next layer
Layern
Layer2
Layer1
![Page 31: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/31.jpg)
3-Tier Architecture
Data AccessUser Interface Business Logic
OrderDatabase
ProductDatabase
UI developers just need to know UI design and how to call business logic methods
Business logic developers just need to know business model, how will be called by UI, and how to call data access methods
Data access developers just need to know SQL and database design and how will be called by business logic
![Page 32: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/32.jpg)
Layered Model
• Advantages:– Limited communication greatly simplifies interface
design, as designers of each layer only have to worry about 2 other layers
• Disadvantages:– May not be possible to subdivide system in this
way (what are layers in registration system?)
![Page 33: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/33.jpg)
Object Model
• System decomposed into a set of loosely coupled objects with well-defined interfaces
• When implemented, objects are created from these classes and some control model used to coordinate object operations– Control components created at start, persist
throughout operation– Other components created/destroyed as needed
![Page 34: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/34.jpg)
Object Model
• UI (persistent component) creates customer invoice and supporting objects as needed from database
issue ()sendReminder ()acceptPayment ()sendReceipt ()
invoice#dateamountcustomer
invoice#dateamountcustomer#
invoice#dateamountcustomer#
customer#nameaddresscredit period
Customer
Payment
Invoice
Receipt
![Page 35: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/35.jpg)
Object Model
• Advantages:– OOP design is highly modular, allowing developers
to easily create and test objects, as well as reuse among multiple project
• Disadvantages:– Complex entities may be hard to represent as
objects– May not be most efficient implementation
![Page 36: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/36.jpg)
Repository Model
• Data to be shared among subsystems kept in single location
• All components communicate with repository to access/modify data
![Page 37: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/37.jpg)
Repository Model
Projectrepository
Designtranslator
Programeditor
Designeditor
Codegenerator
Designanalyser
Reportgenerator
![Page 38: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/38.jpg)
Repository Model
• Advantages– Efficient way to share large amounts of data– Centralised management (backup, security, etc.)
• Disadvantages– Components must agree on a repository data
model. Inevitably a compromise– Difficult to distribute data efficiently, resulting in
slowdowns
![Page 39: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/39.jpg)
Pipelining Model
• Functional transformations process their inputs to produce outputs
• Input of next stage is output of previous stage• “Pipe and filter model” in UNIX shell• Same as batch sequential model extensively
used in data processing systems
![Page 40: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/40.jpg)
Pipelining Model
Read issuedinvoices
Identifypayments
Issuereceipts
Findpayments
due
Receipts
Issuepaymentreminder
Reminders
Invoices Payments
![Page 41: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/41.jpg)
Pipelining Model
• Advantages– Can support concurrent processing– Easy to add new transformations to pipeline, or
reuse filters in other projects• Disadvantages
– Requires a common format for data transfer along the pipeline
– Not really suitable for interactive systems
![Page 42: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/42.jpg)
Client-Server Model
• Data and processing is distributed across a range of components– 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
![Page 43: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/43.jpg)
Client-Server Model
Catalogueserver
Librarycatalogue
Videoserver
Film clipfiles
Pictureserver
Digitisedphotographs
Web server
Film andphoto info.
Client 1 Client 2 Client 3 Client 4
Internet
![Page 44: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/44.jpg)
Client-Server Model
• Advantages– Simple distribution of data– Makes effective use of networked systems– Easy to add new servers or upgrade existing servers
• Disadvantages– No simple way to coordinate activities or data over all
servers (hard to get list of all items accessed, for example)
– Redundant management in each server
![Page 45: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/45.jpg)
Event-driven Model
• Driven by externally generated events where the timing of the event is outside the control of the components which process the event
• Two principal event-driven models– Broadcast models: An event is broadcast to all
subsystems. Any subsystem 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
![Page 46: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/46.jpg)
Broadcast Model
• Effective integration of different computers in a network. Subsystems register an interest in specific events. When these occur, control is transferred to the sub-system which can handle the event.
• However, no guarantee any subsystems will handle an event
Sub-system1
Event and message handler
Sub-system2
Sub-system3
Sub-system4
![Page 47: Software Architecture CSCI 5801: Software Engineering](https://reader035.vdocuments.net/reader035/viewer/2022062221/56649e0b5503460f94af304f/html5/thumbnails/47.jpg)
Interrupt-driven Systems
• Used in real-time systems for fast response• There are known interrupt types with a handler defined
for each type• However, complex to program and difficult to validate
Handler1
Handler2
Handler3
Handler4
Process1
Process2
Process3
Process4
Interrupts
Interruptvector