1. An Introduction to Software Architecture

2. Introduction

3. Informal Definition of SA
First step in developing the solution
Overall (high level) structure of the software system
Software architecture = Components + Connectors
What are components and connectors?

4. A simple example Component 1 Component 2 Component 1.1 Database

5. Why Software Architecture?
Complexity → Divide and Conquer
Process: Divide design process to phases
Architectural design
Detailed design
Product: Decompose system to components
Assuring fulfillment of required quality attributes (performance, changeability, etc) from the beginning

6. Roots of Software Architecture
Software architecture is similar to building architecture in many ways.
The idea is not new. Concepts related to SA have been in the literature since 60’s and 70’s (e.g. modularity, info. hiding).
However, the term is new.
During the past 10 years SA have received considerable attention and have been subject to many research projects.

7. Architecture Business Cycle

8. Motivation
We add a new role to software development team: Software Architect
What does software architect do? Simply drawing the some diagrams?
What else is related to SA?
Are 2 SAs developed in different environmental conditions for a single system the same?
This part covers two issues:
What influences software architecture?
What are influenced by software architecture?

9. Who influences SA?

10. Customers and End Users
Requirements (including qualities such as performance, maintainability, etc)
Budget Limitation
Time Limitation
Force to apply specific technology, methodology, or organizational discipline

11. Developing Organization Concerns
Business issues
investing in, and then amortizing the infrastructure (domain analysis rather than application analysis)
keeping cost low
simplicity of implementation
Organizational issues
using the current organizational structure
utilizing personnel

12. Technical Environment
Current trends: today’s information system are web-based and use middleware systems (e.g. J2EE, .Net)
Available technology: decisions on using a centralized or decentralized system depend on processor cost and communication speed; both are changing quantities.

13. Architect’s Background
Architects develop their mindset from their past experiences.
Prior good experiences will lead to replication of prior designs.
Prior bad experiences will be avoided in the new design.

14. Summary: Influences on the Architect

15. Architecture Influences the Development Organization
Organizational Structure and Recourses
Work units are organized around architectural units
Schedule
Budget
Enterprise Goals
Expertise in building a kind of systems
Success in a market
Evaluating a market
Product-line assets

16. Architecture Influences Customer Requirements
Knowledge of customers to ask for particular features in next systems.
Support of upgrade, adaptation, etc.

17. Architecture Influences the Architect’s Experience and Technical Environment
Creation of a system affects the architect’s background.
Occasionally, a system or an architecture will affect the technical environment.

18. Architecture Business Cycle

19. Process Steps in Architecture-Based Development
Understanding the requirements
Creating, customizing, or selecting the architecture
Representing and communicating the architecture
Analyzing or evaluating the architecture
Implementing based on architecture
Ensuring conformance

20. What is Software Architecture

21. Is this diagram an architecture? (ATM Software)
Control
Card
Interface
Cash
Dispenser
Keyboard
Interface

22. What are ambiguities in the previous diagram?
Nature of the elements (process, class, object, module, function, processor, or etc)
Responsibility of elements
Type of connections (calls, invokes, uses, signals, sends data, controls, sub-class)
Significance of layout
Run-time operation of system

23. Definition
The 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.

24. Externally Visible vs. Internal Properties of Component
Externally visible properties are what assumption other elements can make of an element
Provided services (and interface to access those services)
Performance
Fault handling
Shared resource usage …
SA intentionally abstracts away internal properties of elements (to better encounter complexity)

25. Some Points
Every software system has an architecture (SA ≠ specification of SA)
Specification of architecture can comprise more than one structure
Behavior of elements and relationships are defined in SA (abstractly)
The definition do not talk about Good and Bad architectures: SA evaluation methods
In the literature:
Component = Element
Connector = Relationship

26. What issues are architectural?
Architectural issues are those issues that are important to us at the SA abstraction level.
An issue is architectural if it is not internal to any element. e.g.:
Performance is an architectural quality attribute
Behavior of an element is architectural to the extent that influences how other elements must be developed

27. Architectural Pattern
An architectural pattern is a description of element and relation types together with a set of constraints on how they may be used.
example: client-server, layered, data-centered
unresolved issues of a pattern:
Exact number of elements and relations during application
Behavior of elements during application
Configuration (Topology) during application
Patterns define constraint on architecture but are not architecture themselves. Patterns are abstraction for a set of architectures.

28. Reference Model
A reference model is a division of functionality together with data flow between pieces.
A standard division of a known problem (a mature domain) into parts.
e.g. compiler and DBMS
Reference model is not architecture

29. Reference Architecture
A reference architecture is a reference model mapped onto software elements and data flows between the components
Elements cooperatively implements the functionality defined in the reference model
Reference architecture is not the final architecture but is not far from it

30. Relationship of the previous concepts
Reference
Model
Reference
Architecture
Software
Architecture
System
Architectural
Pattern

31. Why is architecture important?
Handling complexity
Communication among stakeholders
Requirements and concerns of stakeholders
Time
Budget
Other Resources

32. Why is architecture important? (cont)
Early Design Decisions
Constraints implementation and implementers
Organizational structure
Enables predicting and ensuring quality attributes
Makes it possible to reason about and manage change
Helps evolutionary prototyping (risk reduction)

33. Why is architecture important? (cont)
SA is a transferable, reusable model
Software product lines
Component-based development
Automatic generation of lower-level models
A basis for training
A run-time model in self-adaptive and reconfigurable systems

34. Hazards With regards to SA changes are categorized to
Local (a single component)
Non-local (a few components)
Architectural (architectural style)
Once decided architecture is extremely hard to change
It impossible to reach to some quality attribute if architecture disallows

35. Software Arch. vs. System Arch.
System Arch. is the overall architecture of system including hardware and software architecture
In assuring quality attributes the architect needs to think about system architecture too (e.g. performance or reliability)
But architect has more freedom in software architecture than hardware (hardware choices is less under the architects control)

36. Architectural Structures and Views
In construction, there are blueprints of
Plan
Different sides of construction
Electrical wiring
Plumbing …
Each of these views specifies a single entity (i.e. the construction) from a different perspective (used by a different person, for a different goal).
Similarly there are different structures and views in SA.

37. Structures and Views (cont)
Structures is a set of coherent elements and the relations among them. For each structure these we can specify:
Types of elements
Types of relations
A set of syntactic constraints
Semantics of the diagram
Rationale, principles, and guidelines
For what purposes it is useful
View is a representation of software architecture based on an structure as written by the architect and read by stakeholders (an instance of the structure)
SA is documented by a number of views.

38. Categorization of Structures
Module Structures
Component and Connector Structures
Allocation Structures
Categories are orthogonal

39. 1 Module Structures
Elements: modules (units of implementation). Modules are a code based way of considering the system
Specifies:
Functional responsibility of modules
Other elements a module is allowed to use
Generalization and specialization relations
Run-time operation of software is not a concern from this view

40. 1.1 Decomposition Structure
Elements: modules in a hierarchy
Relations: is a sub-module of, shares secret with
Function Examples:
Contributes to system's modifiability, by ensuring that likely changes fall within the scope of at most a few small modules.
Often used as the basis for the development project's organization: the structure of the documentation, and its integration and test plans.

41. Uses Structure
Elements: modules, procedures, or resources on the interfaces of modules
Relations: uses: one unit uses another if the correctness of the first requires the presence of a correct version (not a stub of) of the second.
Function Example:
Allows incremental development

42. 1.3 Layered Structure Is a subclass of uses structure
Elements: layers: a coherent set of related functionality
Relations: uses (ideally layer n may only use the services of layer n – 1), provides abstraction to
Function Example:
Layers are often designed as abstractions (virtual machines) that hide implementation specifics below from the layers above, engendering portability.

43. 1.4 Class Structure Elements: classes
Relations: inherits from, is an instance of
Function Example:
Allows us to reason about reuse and the incremental addition of functionality

44. 2 Component and Connector Structures
Elements: run-time components (principal units of computation) and connectors (communication vehicle among components.)
Specifies:
Major executing components and how they interact
Major shared data-stores
Which part of system is replicated
Flow of data through the system
What parts can run in parallel
How can system structure change as it executes

45. 2.1 Process Structure Elements: processes or threads
Relations: attachment (that allow communication, synchronization, and/or exclusion operations)
Function Example:
Engineering a system's execution performance and availability.

46. 2.2 Shared Data or Repository Structure
Elements: data stores, data producers, and data consumers
Relations: data-flow
Function Example:
To ensure good performance and data integrity.

47. 2.3 Client-Server Structure
Elements: clients and servers
Relations: protocols and message passing infrastructure.
Function Example:
Separation of concerns (supporting modifiability)
Load balancing (supporting runtime performance)

48. 3 Allocation Structures
Show the relationship between the software and the elements in one or more external environment in which software is created and executed.
Specifies:
The processor that executes each software element
The file that stores each software element during development
Assignments of software to development team

49. 3.1 Deployment Structure Shows how software is assigned to hardware
Elements: software (usually a process from a component and connector view), hardware entities, and communication pathways
Relations: is-allocated-to and migrates-to (for dynamic allocations)
Function Example:
Allows reasoning about performance, data integrity, availability, and security.

50. 3.2 Implementation Structure
Shows how software elements (usually modules) are mapped to the file structure(s) in the system's development, integration, or configuration management environments.
Elements: any logical unit (e.g. module)
Relations: implemented in
Function Example:
management of development activities and build process

51. 3.3 Work Assignment Structure
Assigns responsibility for implementing and integrating the modules to the appropriate development teams
Elements: any logical unit (e.g. module)
Relations: is assigned to
Function Example:
The architect will know the expertise required on each team
The means for factoring functional commonalities and assigning them to a single team, rather than having them implemented by everyone who needs them.

52. Notes
Each structure is useful on its own right but not all structures are used in all projects.
Structures are not independent and must be considered together
e.g. relationship of modules with components (many to many)
Some structures may be the same in some systems
Some structures may be combined (e.g. all component and connector structures may be combined in a single structure)

53. 4 + 1 View Model of Architecture
Logical: objects and classes (a module view)
Process: (a component and connector view)
Development: modules, libraries, subsystems, and units of development (an allocation view)
Physical: mapping of elements to hardware and communication (an allocation view)
Scenarios (Use-cases) view is not itself architectural.

54. Quality Attributes

55. Traditional Classification of Requirements
Functional
Non-Functional (Quality Attributes)
A popular software myth: first we build a software that satisfies functional requirements, then we will add or inject non-functional requirements to it.
This idea leads to loss of resources and finally poor quality.
So we should design for qualities from the very beginning (architecture level).

56. Functionality and Architecture
Functionality and quality attrs are orthogonal [in theory]. But not all qualities are achievable to any level desired with any functionality.
Functionality may be achieved in many ways (it is not so architectural.)
Architecture is a means of achieving quality attributes by structuring functionality into elements.

57. Architecture and Qualities
Achieving qualities must be considered throughout design (including SA), implementation, and deployment.
Qualities have both architectural and non-architectural aspects. For example
In usability: selecting form elements vs. supporting undo operation
Performance: amount of communication among components vs. algorithms

58. Architecture and Qualities
Quality attributes are not independent and may not be achieved in isolation.
Positive Correlation; e.g.
Modifiability and Buildability (in many cases)
Negative Correlation (conflict); e.g.
Reliability vs. Security-The most secure system has the fewest points of failure—typically a security kernel. The most reliable system has the most points of failure—typically a set of redundant processes or processors where the failure of any one will not cause the system to fail.
Performance vs. All Other Qualities

59. Classification of Quality Attributes
Qualities of the system: availability, modifiability, performance, security, testability, and usability.
Business qualities (such as time to market) that are affected by the architecture.
Architecture qualities, such as conceptual integrity.

60. System Quality Attributes
System quality attributes have been of interest to the software community at least since the 1970s
Shortcoming of the previous work:
The definitions for an attribute are not operational.
Modifiability with regards to which aspect?
Which quality a particular aspect belongs to.
Is a system failure an aspect of availability, an aspect of security, or an aspect of usability?
Each attribute community has developed its own vocabulary.
Performance community events, security community attacks, availability community failures, and usability community user input may actually refer to the same occurrence.

61. Classifications of System Quality Attributes
Observable via Execution
e.g. performance and security
Not observable via execution
e.g. modifiability and testability
The categories are totally independent (orthogonal), although members of the second category indirectly affect members of the first.
Non-observable qualities are important too. (sometimes even more important!!!)

62. Quality Attribute Scenarios
Is the solution to the stated problems.
A QAS is a quality-attribute-specific requirement, that consists of:
Source of stimulus: actuator; e.g. a human or computer system
Stimulus: event.
Environment: the condition under which the stimulus occurs; e.g. system is overloaded.
Artifact: pieces of system that is stimulated.
Response: desired reaction
Response measure: response should be measurable in some fashion so that the requirement can be tested.
Scenarios may be general or concrete (for specific system)

63. Example: Availability General Scenario

64. Example: Availability Concrete Scenario

65. Modifiability Concrete Scenario

66. Notes on Scenarios
Concrete scenarios role for quality attribute requirements is similar to use cases role for functional requirements.
A collection of concrete scenarios can be used as the quality attribute requirements for a system.
One of the uses of general scenarios is to enable stakeholders to communicate.

67. System Quality Attributes
Availability (related to Reliability)
Modifiability (includes Protability and Reusability, Scalability)
Performance
Security
Testability
Usability (includes Self-Adaptability and User-Adaptability)

68. Business Qualities Time to market Cost and benefit
Predicted lifetime of the system
Targeted market
Rollout schedule(ارائه محصول به بازار)
Integration with legacy systems

69. Qualities of the Architecture
Conceptual Integrity
Conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas. [Brooks 75]
Correctness and Completeness
Buildability
There should be a way to evaluate SA

70. Achieving Qualities

71. The Whole Story Business Requirements Quality Requirements
Tactics Selection
Tactics Implementation:
Design Patterns &
Architectural Patterns

72. Tactics
A tactic is a design decision that influences a quality attribute.
e.g. using redundancy to increase availability
Tactics can be refined to other tactics to become more concrete; e.g. redundancy: redundancy of data + process

73. Availability Tactics

74. Modifiability Tactics

75. Patterns
Ripple effect: اثر بازدارنده
Intermediary:واسط،میانجی

76. Patterns
Binding at runtime means that the system has been prepared for that binding and all of the testing and distribution steps have been completed.
Deferring binding time also supports allowing the end user or system administrator to make settings or provide input that affects behavior.

77. Patterns
Runtime registration supports plug-and-play operation at the cost of additional overhead to manage the registration. Publish/subscribe registration, for example, can be implemented at either runtime or load time.
Configuration files are intended to set parameters at startup.
Polymorphism allows late binding of method calls.
Component replacement allows load time binding.
Adherence to defined protocols allows runtime binding of independent processes.

78. Patterns
A pattern is a common abstract solution to a common abstract problem that
Can be tailored to a given situation
Has predefined characteristics
Abstraction level of patterns
Business
Analysis
Architecture
Design
Implementation (Idioms)
Test Patterns (or guideline to testing patterns)

79. Relationship of Tactics to Patterns
An architect usually chooses a pattern or a collection of patterns designed to realize one or more tactics.
However, each pattern implements multiple tactics, whether desired or not.

80. Famous Pattern (Style) categories
Data-centered
Repository
Blackboard (publisher-subscriber)
Structural solution to integrability of data
Scalability
Modifiability
Client
Client
Shared Data
Client
Client

81. Famous Pattern (Style) categories
Dataflow
Bach sequential
Pipes and filters
Reusability
Modifiability
Not interactive
Poor performance

82. Famous Pattern (Style) categories
Virtual Machine
Interpreter (e.g. Adaptive Object Model) …
Portability
Simulation
Adaptability
Low performance

83. Famous Pattern (Style) categories
Call and Return
Main program and sub-routine
Modifiability
Remote procedure call
Performance tuning
Object-oriented or abstract data type
Reuse
Layered
Portability

84. Famous Pattern (Style) categories
Independent components
Communicating Processes
Scalability
Event Systems
Modifiability

85. Example: ATM Software
Develop 3 different architectures for ATM software and compare them regarding fulfillment of quality attributes.
ATM = Automatic Teller Machine
User operations:
Insert card and enter PIN
Withdraw money
Check Balance

86. Shared-Memory Style

87. Abstract Data Type Style

88. Layered Style

89. Analysis and Comparison
Shared-Mem
ADT
Layered
Performance 3 2 1
Change account record format
New service: close account and withdraw the remained balance
Portability
Availability and Reliability
Buildability and Integrability
Sum 9 13 15

90. Software Architecture Analysis Method (SAAM)

91. Topics about SAAM Why analysis?
Selecting system to buy
Developing different architecture and comparing them
What specifies the metric for evaluations?
Goal(s)
How to evaluate SA with regards to goals?
Write scenarios to analyze the system against goals

92. Steps of SAAM Develop Scenarios Describe Candidate Architectures
Classify Scenarios
Direct
Indirect
Perform Scenario Evaluations (for indirect scenarios)
Reveal Scenario Interaction

93. Scenarios for ATM example
0. Withdraw money
New service: close account and withdraw the remained balance
Change hardware
Change DBMS
Change account record format

94. ADT Style Architecture

95. Layered Style Architecture

96. Comparison
Scenario 0
Scenario 1
Scenario 2
Scenario 3
Scenario 4
Contention
ADT
Direct -
Layered +
For these scenarios layered architecture is superior to ADT architecture

97. Other Issues about SA Product-Line Architectures
Architecture Description Languages (ADL)
Run-Time Re-Configuration of Architecture
Architecture Reconstruction
Information Architecture
Enterprise Architecture

98. Good References SEI Software Architecture Series:
Software Architecture in Practice, 2nd Ed.
Documenting Software Architecture
Evaluating Software Architecture: Methods and Case Studies
Software Product Lines

99. Good References Pattern Books:
Design Patterns: Elements of Reusable Object-Oriented Software
Analysis Patterns: Reusable Object Models
Pattern-Oriented Software Architecture