Software Architecture

1
Software Architecture

• CSCI 5801 Software Engineering

2
Software Architecture
3
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.)

4
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

5
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

6
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

7
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

8
Physical Architectures

• Highest levels of architecture often determined
  by physical location and other restrictions (such
  as security)
• Interfaces then designed to enable communication

9
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

10
Sequence Diagrams

11
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

12
Example Architecture
13
Example Architecture
14
Example Architecture
15
Example Architecture
16
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

17
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

18
Decomposition Methods

• Functional decomposition
• Data-driven decomposition
• Object-oriented decomposition
• Process-oriented decomposition
• Event-oriented decomposition
• And many others
• Often influence overall system architecture

19
Functional Decomposition

• Indentify top-level functions than meet
  requirements
• Decompose into simpler subfunctions (looking for
  reuse)

Requirement
Requirement
Requirement
Function
Function
Sub-function
Sub-function
Sub-function
Sub-function
Sub-function
Sub-function
20
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
Roster
Student Database
Time
Instructor
Room
Students
Days
Hours
21
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

22
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 F
Process step C
Process step D
Process step E
23
Event-driven Decomposition

• Identify main external signals system must handle
• Create a component for each

24
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

25
Common Architectural Styles

• Centralized control
• Layered
• Distributed objects
• Repository
• Pipelining
• Client/Server
• Event-driven

26
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.

27
Call-return Model
28
Manager Model
29
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

30
Layered Model

• System organized into layers of components
• Each layer only communicates with previous and
  next layer

Layern
Layer2
Layer1
31
3-Tier Architecture
Data Access
User Interface
Business Logic
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
32
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?)

33
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

34
Object Model

• UI (persistent component) creates customer
  invoice and supporting objects as needed from
  database

35
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

36
Repository Model

• Data to be shared among subsystems kept in single
  location
• All components communicate with repository to
  access/modify data

37
Repository Model
38
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

39
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

40
Pipelining Model
41
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

42
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

43
Client-Server Model
44
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

45
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

46
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

47
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