This document provides an overview of software architecture. It defines software architecture as the fundamental organization of a system embodied in its components, their relationships to each other, and the environment. This includes high-level structures like modules, components and connectors, as well as views like logical, process, development and physical. It also discusses architectural patterns, reference models, reference architectures and the importance of architecture in enabling qualities like performance and modifiability. The architecture business cycle and influences on architecture are described. Finally, it outlines common architectural structures like modules, layers, classes, and deployment.

1. Dr. Awais Majeed
awais.majeed@bcs.org
Software Architecture
Software System Design & Architecture

2. Topics
 What is Software Architecture?
 ABC
 Architectural Patterns, Reference Models and
Reference Architectures
 Importance of Software Architecture
 Architectural structures and views
 Various Types of Structures

3. Software Architecture
 As the size and complexity of software systems
increases, the design and specification of overall
system structure become more significant issue than
the choice of algorithms and data structures.
 Structural issues include system organization as a
composition of components, protocols for
communication, interaction through interfaces, etc.
 This is the Software Architecture level of design.

4. What is Software Architecture?
 A natural evolution of design abstractions.
 Involves the description of elements from
which system is built, interactions among
those elements, patterns that guide their
composition, and constraints on the patterns.
 Considers system as a collection of
components and their interactions.

5. Components & their Interactions
 Components are such things as clients and
servers, databases, layers, etc.
 Interactions among components can be procedure
calls, shared variable access, etc.
 At the architectural level, we also consider system-
level issues such as capacity, consistency,
performance, etc.

6. Software Architecture
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 [IEEE standard 1471–2000 ].
 Software Architecture defines the observable properties
of a software system
Software architecture of a program or computing system is
the structure or structures of the system, which comprise
software elements, the externally visible properties of
those elements and the relationships among them (Len
Bass)
 Software architecting means the process of creating
software architectures

7. Architecture vs. Design
 “All architecture is design, not all design is
architecture”.
 Architectural design is outward looking
 Focus on stakeholders, not technology
 Architecture doesn't describe the complete
characteristics of components – Design does.

8. Architectural influences
 Influences
 System Stakeholders
 Developing organization
 Architects’ background and experience
 Technical environment
 Ramification of influences on architecture
 Know your constraints
 Early engagement of stakeholders

10. Influences on the architecture

11. The Architecture Business Cycle

12. Ramification of influences on architecture
 Know your constraints
 Early engagement of stakeholders

13. Architecture Business Cycle (ABC)
 Software architecture is a result of technical,
business and social influences.
 These are in turn affected by the software
architecture itself.
 This cycle of influences from the environment
to the architecture and back to the
environment is called the Architecture
Business Cycle (ABC).

14. ABC Activities
 Creating the business case for the system
 Understanding the Requirements
 Creating/selecting the architecture
 Communicating the architecture
 Analysing or evaluating the architecture
 Implementation based on architecture
 Ensuring conformance to an architecture

15. Software Architecture
 What is the nature of the elements?
 What are the responsibilities of the elements?
 What is the significance of the connections?
 What is the significance of the layout?
Figure: Underwater Acoustic System

16. Architectural Patterns
An architectural pattern is a description of
element and relation types together with a set
of constraints on how they may be used
 these constraints define a set or family of
architectures that satisfy them
 They exhibit known quality attributes
 client-server is a common architectural pattern
 Client and server two elements
Coordination described by the protocol server uses
Multiple clients can exist

17. Reference Model
 A reference model is a division of
functionality together with data flow between
the pieces
 reference model is a standard decomposition
of a known problem into parts that
cooperatively solve the problem
 Show the maturity of a particular domain
 What the various parts of a compiler?
 How they interact with each other to perform a
particular task?

18. Reference Architecture
 A reference architecture is a reference model
mapped onto software elements (that
cooperatively implement the functionality
defined in the reference model) and the data
flows between them.
 Java Platform, Enterprise Edition (Java EE)
 Java Platform, Enterprise Edition (Java EE) s

19. Other point-of-views
 Software architecture is concerned with:
 Stakeholders
 System-Level Structures
 System qualities
 Software architecture involves:
 Understanding domains, problems and solutions
 Making design decisions & tradeoffs
 Delivering working systems

20. Importance of Software Architecture
Communication among stakeholders
 SA presents a common abstraction of a system
 Customers are concerned that
 Software is reliable and available
 Architecture can be implemented on schedule and within
budget
 SA allows teams to work independently

21. SA for early design decisions
Implementation constraints
 Implementation must follow the structural design decisions
 Describe prescribe elements, their interaction and the
responsibilities
 Resource allocations as constraints on implementation
Organizational structure
 SA defines the highest level system decomposition
 This is used for the work breakdown
 Planning, budgeting, scheduling, teams, communication
channels, configuration management etc.

22. SA for early design decisions …
SA as system quality enabler
 Architecture defines whether a system will inhibit the
desired/required qualities or not
 High performance – manage time base behavior of the elements
 Inter-element communication ?
 Modifiability – responsibilities to elements
 Security – inter-element communication and access control
 Scalability – localization of resources
 Incremental release – manage inter-component usage
 Re-usability – restrict inter-element coupling

23. SA for early design decisions …
Managing change
 80% of the cost is after initial deployment
 Change can be partitioned into 3 groups:
 Local: modify a single element
 Non-local: multi-element change
 Architectural: change the way elements interact with
each other
 Deep understanding of the relationships,
performance and behavior of the system is
required to decide on such changes

24. SA for early design decisions …
 Evolutionary prototyping
 An executable system in the early DLC
 Cost and schedule estimation
 Team/work distribution more clear
 Identify challenging parts
 Identify required resources/competencies

25. Architectural Structures and Views
 A Structure is the set of elements itself, as they exist
in software or hardware.
 A View is a representation of a coherent set of
architectural elements as written by and read by
system stakeholders
 A module structure is the set of the system’s module and
their organisation.
 A module view is the representation of that structure as
documented by and used by some system stakeholder
 Both terms are used interchangeably

26. Types of Architectural Structures
Module structure
 The elements are modules – units of
implementation
 Assigned areas of functional responsibilities
 What is the primary functional responsibility assigned to
each module?
 What other software elements is a module allowed to
use?

27. Types of Architectural Structures …
Component-and-connector structures
 elements are runtime components (which are the
principal units of computation) and
 connectors (which are the communication
vehicles among components)
 Can answer questions as:
 major executing components and how do they interact?
 What are the major shared data stores?
 Which parts of the system are replicated?
 How does data progress through the system?
 What parts of the system can run in parallel?
 How can the system's structure change as it executes?

28. Types of Architectural Structures …
Allocation structures
 Allocation structures show the relationship
between the software elements and the elements
in one or more external environments in which
software is created or executed.
 Can answer questions like:
 What processor does each software element execute
on?
 In what files is each element stored during development,
testing, and system building?
 What is the assignment of software elements to
development teams?

29. broad types of decision that architectural
design involves
 How is the system to be structured as a set
of code units (modules)?
 How is the system to be structured as a set
of elements that have runtime behavior
(components) and interactions (connectors)?
 How is the system to relate to nonsoftware
structures in its environment (i.e., CPUs, file
systems, networks, development teams,
etc.)?

30. Common software architecture structures

31. Module based structures
Decomposition
 Relationship between modules is “is a sub-module of”
 The decomposition structure enhances system‘s
modifiability – changes fall in a small number of modules
 The modules have associated products (interface
specifications, code, test plans etc)
Uses
 The units are modules or procedures or resources on the
interfaces of modules.
 One unit uses another if the correctness of the first requires
the presence of a correct version of the second.
 Extend or abstract (extract) functionality

32. Module based structures …
Layered
 a system of layers emerges when uses
relationship is controlled in a particular fashion
 in which a layer is a coherent set of related functionality.
 In strict layered structure: layer n may only use
the services of layer n – 1.
 Layers are often designed as abstractions (virtual
machines) that hide implementation specifics
below from the layers above – portability
Think of an example?

33. Module based structures …
Class or generalisation
 The module units in this structure are called
classes
 The relation is "inherits-from" or "is-an-instance-
of."
 This view supports reasoning about collections of
similar behavior or capability

34. Component-and-Connector
Process or communicating processes
 deals with the dynamic aspects of a running
system
 The units here are processes or threads that are
connected with each other by communication,
synchronization, and/or exclusion operations.
 The relationship is of attachment, showing how
the components and connectors are hooked
together
 It is important to design a system's execution
performance and availability.

35. Component-and-Connector …
Concurrency
 A structure which allows the architect to determine
opportunities for parallelism and the locations
where resource contention may occur
 The units are components and the connectors are
"logical threads."
 A logical thread is a sequence of computation that can
be allocated to a separate physical thread later in the
design process.
Shared data, or repository
 components and connectors that create, store,
and access persistent data

36. Component-and-Connector …
Client-server
 A structure of components and connectors for a
system built as a group of cooperating clients and
servers
 The components are the clients and servers
 the connectors are protocols and messages they
share to carry out the system's work
 Useful for
 separation of concerns
 for physical distribution, and
 for load balancing (supporting runtime performance).

37. Allocation
Deployment
 The deployment structure shows how
software is assigned to hardware-processing
and communication elements
 The elements are software (usually a process
from a component-and-connector view), hardware
entities (processors), and communication
pathways.
 Relations are "allocated-to,"
 which physical units the software elements reside,
 "migrates-to," if the allocation is dynamic

38. Allocation …
Implementation
 This structure shows how software elements
(usually modules) are mapped to the file
structure(s) in:
 system's development,
 integration, or
 configuration control environments.
 Helpful in the management of development
activities and build environment

39. Allocation …
Work Assignment
 This structure assigns responsibility for
implementing and integrating the modules to
the appropriate development teams
 Work assignment structure has architectural
as well as management implications

40. Which structure to choose?
 Not all of them may be relevant
 one of the obligations of the architect is to
understand how the various structures lead to
quality attributes
 Can you relate the 4+1 approach from the
Rational Unified Process ?

41. Use Case View
Logical View
Dynamic View
Implementation View
Deployment View
ud Manage Employees
AutoEdge System
Manager
(from Actors)
Browse Employees
Update Employee
Create Employee
Delete Employee
Create User
«extend»
«include»
«use»
«use»
cd Users
Architecture Entities::User
- UserEmail: CHARACTER
- UserLogin: CHARACTER
- UserPassword: CHARACTER
Architecture Entities::UserGroups
- UserGroupDescription: CHARACTER
- UserGroupName: CHARACTER
Business Entities::Employee
+ Address: CHARACTER
+ City: CHARACTER
+ email: CHARACTER
- EmployeeLanguage: CHARACTER
+ employmentEndDate: DATETIME-TZ
+ employmentStartDate: DATE
+ FirstName: CHARACTER
+ LastName: CHARACTER
+ MobilePhoneNumber: CHARACTER
+ Notes: CHARACTER
+ PhoneNumber: CHARACTER
+ Position: CHARACTER
+ PostCode: CHARACTER
+ createEmployee() : void
+ deleteEmployee() : void
+ findEmployee() : void
+ isAvailable() : LOGICAL
+ updateEmployee() : void
+ validateEmployee() : void
Architecture Entities::
Language
- Description: CHARACTER
- Language: CHARACTER
0..*
1
1
1
0..* 1
sd Login
Client
(from Architecture Components)
Server Gateway
(from Architecture Components)
Security
(from Architecture Components)
Session Context
(from Architecture Components)
Request("Security", "Login", ...)
isValidUser(Login, password)
ValidUser
[if Valid User]: createSession
sessionID
[if valid user]: sessionID
id Business Entity (Client)
«Program»
proSIproxy.p
- NEW GLOBAL SHARED VARIABLE ghttProxySIproc: HANDLE
+ fetchWhere(CHARACTER, HANDLE, DATASET-HANDLE*) : void
+ saveChanges(CHARACTER, HANDLE, CHARACTER*) : void
«Program»
ClientXxx.p
«Include»
proSIproxyStart.i
- NEW GLOBAL SHARED VARIABLE ghProxySIproc:
«Include»
dsXxx.i
- DEFINE DATASET <dataset-def>:
«Include»
etXxx.i
«include»
ttContext.i
«includes»
includes
includes
«includes»
«realize PERSISTENT»
includes
dd Integration
HQ System
Sonic
Dealer
System 1
Sonic
Dealer
System 2
Sonic
Dealer
System 3
Sonic
Dealer
System n
Sonic

42. 4 + 1 View
 Logical. The elements are "key abstractions,"
objects or object classes
 Process. This view addresses concurrency and
distribution of functionality.
 Development. This view shows the organization of
software modules, libraries, subsystems, and units
of development.
 Physical. This view maps other elements onto
processing and communication nodes

43. References and further readings
 Chapter 1 &2 from “Software Architecture in
Practice” by Len Bass