An introduction to software architecture pejman salehi
1 / 66

An Introduction to Software Architecture Pejman Salehi - PowerPoint PPT Presentation

  • Uploaded on

An Introduction to Software Architecture Pejman Salehi. Table of content. Introduction Architecture Business Cycle Architectural Structures and Views Quality Attributes Achieving Qualities Attribute Driven Design. Introduction. Definition.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'An Introduction to Software Architecture Pejman Salehi' - saskia

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
An introduction to software architecture pejman salehi l.jpg

An Introduction to Software ArchitecturePejman Salehi

Slide2 l.jpg

Table of content

  • Introduction

  • Architecture Business Cycle

  • Architectural Structures and Views

  • Quality Attributes

  • Achieving Qualities

  • Attribute Driven Design

Definition l.jpg

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.

Externally visible vs internal properties l.jpg
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)

Some points l.jpg
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

Why is architecture important l.jpg
Why is architecture important?

  • Handling complexity

  • Communication among stakeholders

    • Requirements and concerns of stakeholders

    • Time

    • Budget

    • Other Resources

Why is architecture important cont l.jpg
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)

Why is architecture important cont9 l.jpg
Why is architecture important? (cont)

  • SA is a transferable, reusable model

    • Software product lines

    • Component-based development

    • Automatic generation of lower-level models

Hazards l.jpg

  • 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

Software arch vs system arch l.jpg
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)

Architectural structures and views17 l.jpg
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.

Structures and views cont l.jpg
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.

Categorization of structures l.jpg
Categorization of Structures

  • Module Structures

  • Component and Connector Structures

  • Allocation Structures

1 module structures l.jpg
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

1 1 decomposition structure l.jpg
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.

1 2 uses structure l.jpg
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

1 3 layered structure l.jpg
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.

1 4 class structure l.jpg
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

2 component and connector structures l.jpg
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

2 1 process structure l.jpg
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.

2 2 shared data or repository structure l.jpg
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.

2 3 client server structure l.jpg
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)

2 4 concurrency structure l.jpg
2.4 Concurrency Structure

  • Elements: Component

  • Relations: Logical Thread.

  • Function Example:

    • managing the issues associated with concurrent execution.

      • resource contention

3 allocation structures l.jpg
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

3 1 deployment structure l.jpg
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.

3 2 implementation structure l.jpg
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

3 3 work assignment structure l.jpg
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.

Notes l.jpg

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

Traditional classification of requirements l.jpg
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).

Functionality and architecture l.jpg
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.

Architecture and qualities l.jpg
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

Architecture an qualities l.jpg
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

Classification of quality attributes l.jpg
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.

System quality attributes l.jpg
System Quality Attributes

  • Availability (related to Reliability)

  • Modifiability (includes Protability and Reusability, Scalability)

  • Performance

  • Security

  • Testability

  • Usability (includes Self-Adaptability and User-Adaptability)

Business qualities l.jpg
Business Qualities

  • Time to market

  • Cost and benefit

  • Predicted lifetime of the system

  • Targeted market

  • Rollout schedule

  • Integration with legacy systems

Qualities of the architecture l.jpg
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

System quality attributes45 l.jpg
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.

Quality attribute scenario l.jpg
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.

Quality attribute scenario cont l.jpg
Quality Attribute Scenario (cont.)

  • General Scenario

Quality attribute scenario cont48 l.jpg
Quality Attribute Scenario (cont.)

  • Sample Scenario

The whole story l.jpg
The Whole Story





Tactics Selection

Tactics Implementation:

Architectural Patterns

Tactics l.jpg

  • 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

Patterns l.jpg

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

Relationship of tactics to patterns l.jpg
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.

Famous pattern style categories l.jpg
Famous Pattern (Style) categories


  • Repository

  • Blackboard (publisher-subscriber)

  • Structural solution to integrability of data

  • Scalability

  • Modifiability

  • Client


    Shared Data



    Famous pattern style categories57 l.jpg
    Famous Pattern (Style) categories


    • Bach sequential

    • Pipes and filters

  • Reusability

  • Modifiability

  • Not interactive

  • Poor performance

  • Famous pattern style categories58 l.jpg
    Famous Pattern (Style) categories

    Virtual Machine

    • Interpreter (e.g. Adaptive Object Model)

  • Portability

  • Simulation

  • Adaptability

  • Low performance

  • Famous pattern style categories59 l.jpg
    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

    Famous pattern style categories60 l.jpg
    Famous Pattern (Style) categories

    Independent components

    • Communicating Processes

      • Scalability

    • Event Systems

  • Modifiability

  • Example atm software l.jpg
    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

    Attribute driven design l.jpg
    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