Upload
rudolph-griffin
View
251
Download
3
Embed Size (px)
Citation preview
Software Architecture
CSCI 5801: Software Engineering
Software Architecture
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.)
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
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
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
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
Physical Architectures
• Highest levels of architecture often determined by physical location and other restrictions (such as security)
• Interfaces then designed to enable communication
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
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
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
Example Architecture
Example Architecture
Example Architecture
Example Architecture
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
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
Decomposition Methods
• Functional decomposition• Data-driven decomposition• Object-oriented decomposition• Process-oriented decomposition• Event-oriented decomposition• And many others…
• Often influence overall system architecture
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
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
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
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
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
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
Common Architectural Styles
• Centralized control• Layered• Distributed objects• Repository • Pipelining• Client/Server• Event-driven
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.
Call-return Model
Routine 1.2Routine 1.1 Routine 3.2Routine 3.1
Routine 2 Routine 3Routine 1
Mainprogram
Manager Model
Systemcontroller
Userinterface
Faulthandler
Computationprocesses
Actuatorprocesses
Sensorprocesses
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
Layered Model
• System organized into layers of components• Each layer only communicates with previous
and next layer
Layern
Layer2
Layer1
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
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?)
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
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
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
Repository Model
• Data to be shared among subsystems kept in single location
• All components communicate with repository to access/modify data
Repository Model
Projectrepository
Designtranslator
Programeditor
Designeditor
Codegenerator
Designanalyser
Reportgenerator
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
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
Pipelining Model
Read issuedinvoices
Identifypayments
Issuereceipts
Findpayments
due
Receipts
Issuepaymentreminder
Reminders
Invoices Payments
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
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
Client-Server Model
Catalogueserver
Librarycatalogue
Videoserver
Film clipfiles
Pictureserver
Digitisedphotographs
Web server
Film andphoto info.
Client 1 Client 2 Client 3 Client 4
Internet
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
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
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
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