Transcript Introduction and Course Outline

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
Withdraw
Interface
Login
Logic
Withdraw
Logic
Account
Account
Database
Object
User
construct
ID
Account
databas
e
construct
ID
construct
query
ID
hasAccount
account
data
account data
account data
accountType,
amount
[2] Error message
[3] Error message
construct
ID, type
withdraw
(accountType,
amount)
[2] IllegalAmount
[3] Insufficient
Balance
[1] withdraw
(amount)
[3] Insufficient
Balance
[1] setBalance
(amount,
accountType)
[1] update
[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 modelview-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
Function
Sub-function
Sub-function
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 Inventory
Roster
Database
Course Info
Time
Days
Instructor
Hours
Roster
Student
Database
Room
Students
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)
Requirement
Process step A
Process step B
Requirement
Process step C
Process step F
Process step D
Process step E
Event-driven Decomposition
• Identify main external signals system must
handle
• Create a component for each
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
Manager Model
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
User Interface
Business Logic
Data Access
Order
Database
Product
Database
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
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
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
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
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
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