An Introduction to Software Architecture Pejman Salehi

1
An Introduction to Software ArchitecturePej
man Salehi
2
Table of content

• Introduction
• Architecture Business Cycle
• Architectural Structures and Views
• Quality Attributes
• Achieving Qualities
• Attribute Driven Design

3
Introduction
4
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.

5
Externally Visible vs. Internal Properties

• 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)

6
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

7
Why is architecture important?

• Handling complexity
• Communication among stakeholders
• Requirements and concerns of stakeholders
• Time
• Budget
• Other Resources

8
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)

9
Why is architecture important? (cont)

• SA is a transferable, reusable model
• Software product lines
• Component-based development
• Automatic generation of lower-level models

10
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

11
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)

12
Architecture Business Cycle
13
Who influences SA?
14
Summary Influences on the Architect
15
Architecture Business Cycle
16
Architectural Structures and Views
17
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.

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

19
Categorization of Structures

• Module Structures
• Component and Connector Structures
• Allocation Structures

20
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

21
1.1 Decomposition Structure

• Elements modules in a hierarchy
• Relations is a sub-module of, shares secret with
• Function Example
• Contributes to system's modifiability, by
  ensuring that likely changes fall within the
  scope of at most a few small modules.

22
1.2 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.
• Function Example
• Allows incremental development

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

24
1.4 Class Structure

• Elements classes /objects
• Relations inherits from, is an instance of
• Function Example
• Allows us to reason about reuse and the
  incremental addition of functionality

25
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

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

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

28
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)

29
2.4 Concurrency Structure

• Elements Component
• Relations Logical Thread.
• Function Example
• managing the issues associated with concurrent
  execution.
• resource contention

30
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

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

32
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

33
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), team
  structure
• 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.

34
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)

35
Structures
36
Quality Attributes
37
Traditional Classification of Requirements

• 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).

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

39
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

40
Architecture an Qualities

• Quality attributes are not independent and may be
  achieved in isolation.
• Positive Correlation e.g.
• Modifiability and Buildability (in many cases)
• Negative Correlation (conflict) e.g.
• Reliability vs. Security
• Performance vs. All Other Qualities

41
Classification of Quality Attributes

1. Qualities of the system availability,
   modifiability, performance, security,
   testability, and usability.
2. Business qualities (such as time to market) that
   are affected by the architecture.
3. Architecture qualities, such as conceptual
   integrity.

42
System Quality Attributes

• Availability (related to Reliability)
• Modifiability (includes Protability and
  Reusability, Scalability)
• Performance
• Security
• Testability
• Usability (includes Self-Adaptability and
  User-Adaptability)

43
Business Qualities

• Time to market
• Cost and benefit
• Predicted lifetime of the system
• Targeted market
• Rollout schedule
• Integration with legacy systems

44
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

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

46
Quality Attribute Scenario

• Solution
• Quality Attribute Scenarios as a means of
  characterizing quality attributes
• consists of six parts
• Source of stimulus.
• Stimulus.
• Environment.
• Artifact.
• Response.
• Response measure.

47
Quality Attribute Scenario (cont.)

• General Scenario

48
Quality Attribute Scenario (cont.)

• Sample Scenario

49
Achieving Qualities
50
The Whole Story
Business Requirements
Quality Requirements
Tactics Selection
Tactics Implementation Architectural Patterns
51
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

52
Availability Tactics
53
Modifiability Tactics
54
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)

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

56
Famous Pattern (Style) categories

• Data-centered
• Repository
• Blackboard (publisher-subscriber)
• Structural solution to integrability of data
• Scalability
• Modifiability

Client
Client
Shared Data
Client
Client
57
Famous Pattern (Style) categories

• Dataflow
• Bach sequential
• Pipes and filters
• Reusability
• Modifiability
• Not interactive
• Poor performance

58
Famous Pattern (Style) categories

• Virtual Machine
• Interpreter (e.g. Adaptive Object Model)
• Portability
• Simulation
• Adaptability
• Low performance

59
Famous Pattern (Style) categories

• Call and Return
• Main program and sub-routine
• Modifiability
• Remote procedure call
• Performance tuning
• Object-oriented or abstract data type
• Modifiability
• Reuse
• Layered
• Modifiability
• Portability

60
Famous Pattern (Style) categories

• Independent components
• Communicating Processes
• Scalability
• Event Systems
• Modifiability

61
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

62
Shared-Memory Style
63
Abstract Data Type Style
64
Layered Style
65
Analysis and Comparison
Shared-Mem ADT Layered
Performance 3 2 1
Change account record format 1 3 3
New service close account and withdraw the remained balance 1 2 3
Portability 1 2 3
Availability and Reliability 2 2 2
Buildability and Integrability 1 2 3
Sum 9 13 15
66
Attribute-Driven Design

• bases the decomposition process on the quality
  attributes.
• quality requirements should be expressed as a set
  of system-specific quality scenarios.
• Steps
• Choose the module to decompose
• Refinement
• Choose the architectural drivers
• Choose an architectural tactic and pattern
• Instantiate modules and allocate functionality
• Define interfaces of the child modules
• Verify and refine use cases and quality scenarios
  
• Repeat the steps above for every module