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 Component Package
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 User Login Logic Withdraw Interface Withdraw Logic
Account Database
Account database
Account Object
construct ID
query
account data
ID, type
accountType, amount
withdraw (accountType, amount)
hasAccount
[1] withdraw (amount)
[2] IllegalAmount
[3] Error message
[3] Insufficient Balance
[1] setBalance (amount, accountType)
[1] update
[2] Error message
[3] Confirmation message

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: Disadvantages:
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 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

32. Layered Model Advantages: Disadvantages:
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: Disadvantages:
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 Disadvantages
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 Disadvantages
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 Disadvantages
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