an introduction to software architecture. introduction
TRANSCRIPT
![Page 1: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/1.jpg)
An Introduction to Software Architecture
![Page 2: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/2.jpg)
Introduction
![Page 3: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/3.jpg)
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?
![Page 4: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/4.jpg)
A simple example
Component 1.1
Component 1.2
Component 2
Database
Component 1
![Page 5: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/5.jpg)
Why Software Architecture?
• Complexity → Divide and Conquer– Process: Divide design process to phases
1. Architectural design 2. Detailed design
– Product: Decompose system to components
• Assuring fulfillment of required quality attributes (performance, changeability, etc) from the beginning
![Page 6: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/6.jpg)
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.
![Page 7: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/7.jpg)
Architecture Business Cycle
![Page 8: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/8.jpg)
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?
![Page 9: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/9.jpg)
Who influences SA?
![Page 10: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/10.jpg)
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
![Page 11: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/11.jpg)
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
![Page 12: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/12.jpg)
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.
![Page 13: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/13.jpg)
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.
![Page 14: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/14.jpg)
Summary: Influences on the Architect
![Page 15: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/15.jpg)
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
![Page 16: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/16.jpg)
Architecture Influences Customer Requirements
• Knowledge of customers to ask for particular features in next systems.
• Support of upgrade, adaptation, etc.
![Page 17: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/17.jpg)
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.
![Page 18: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/18.jpg)
Architecture Business Cycle
![Page 19: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/19.jpg)
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
![Page 20: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/20.jpg)
What is Software Architecture
![Page 21: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/21.jpg)
Is this diagram an architecture? (ATM Software)
Control
KeyboardInterface
Cash Dispenser
CardInterface
![Page 22: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/22.jpg)
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
![Page 23: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/23.jpg)
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.
![Page 24: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/24.jpg)
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)
![Page 25: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/25.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
![Page 26: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/26.jpg)
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
![Page 27: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/27.jpg)
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.
![Page 28: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/28.jpg)
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
![Page 29: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/29.jpg)
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
![Page 30: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/30.jpg)
Relationship of the previous concepts
Reference Model
SystemSoftware
ArchitectureReference
Architecture
ArchitecturalPattern
![Page 31: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/31.jpg)
Why is architecture important?
• Handling complexity
• Communication among stakeholders– Requirements and concerns of stakeholders– Time– Budget– Other Resources
![Page 32: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/32.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)
![Page 33: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/33.jpg)
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
![Page 34: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/34.jpg)
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
![Page 35: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/35.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)
![Page 36: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/36.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.
![Page 37: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/37.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.
![Page 38: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/38.jpg)
Categorization of Structures
1. Module Structures
2. Component and Connector Structures
3. Allocation Structures
Categories are orthogonal
![Page 39: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/39.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
![Page 40: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/40.jpg)
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.
![Page 41: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/41.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 (not a stub of) of the second.
• Function Example:– Allows incremental development
![Page 42: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/42.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.
![Page 43: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/43.jpg)
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
![Page 44: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/44.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
![Page 45: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/45.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.
![Page 46: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/46.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.
![Page 47: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/47.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)
![Page 48: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/48.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
![Page 49: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/49.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.
![Page 50: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/50.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
![Page 51: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/51.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)• 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.
![Page 52: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/52.jpg)
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)
![Page 53: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/53.jpg)
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.
![Page 54: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/54.jpg)
Quality Attributes
![Page 55: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/55.jpg)
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).
![Page 56: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/56.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.
![Page 57: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/57.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
![Page 58: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/58.jpg)
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
![Page 59: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/59.jpg)
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.
![Page 60: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/60.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.
![Page 61: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/61.jpg)
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!!!)
![Page 62: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/62.jpg)
Quality Attribute Scenarios• Is the solution to the stated problems.• A QAS is a quality-attribute-specific
requirement, that consists of:1. Source of stimulus: actuator; e.g. a human or
computer system2. Stimulus: event.3. Environment: the condition under which the stimulus
occurs; e.g. system is overloaded.4. Artifact: pieces of system that is stimulated. 5. Response: desired reaction 6. 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)
![Page 63: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/63.jpg)
Example: Availability General Scenario
![Page 64: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/64.jpg)
Example: Availability Concrete Scenario
![Page 65: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/65.jpg)
Modifiability Concrete Scenario
![Page 66: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/66.jpg)
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.
![Page 67: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/67.jpg)
System Quality Attributes
• Availability (related to Reliability)• Modifiability (includes Protability and
Reusability, Scalability) • Performance• Security• Testability• Usability (includes Self-Adaptability and
User-Adaptability)
![Page 68: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/68.jpg)
Business Qualities
• Time to market• Cost and benefit• Predicted lifetime of the system• Targeted market• Rollout schedule( بازار به محصول (ارائه• Integration with legacy systems
![Page 69: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/69.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
There should be a way to evaluate SA
![Page 70: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/70.jpg)
Achieving Qualities
![Page 71: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/71.jpg)
The Whole Story
Tactics Selection
QualityRequirements
BusinessRequirements
Tactics Implementation:Design Patterns &
Architectural Patterns
![Page 72: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/72.jpg)
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
![Page 73: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/73.jpg)
Availability Tactics
![Page 74: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/74.jpg)
Modifiability Tactics
![Page 75: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/75.jpg)
Patterns• Ripple effect: بازدارنده اثر• Intermediary:واسط،میانجی
![Page 76: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/76.jpg)
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.•
![Page 77: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/77.jpg)
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.
![Page 78: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/78.jpg)
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)
![Page 79: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/79.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.
![Page 80: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/80.jpg)
Famous Pattern (Style) categories
Data-centered– Repository– Blackboard (publisher-subscriber)
• Structural solution to integrability of data• Scalability• Modifiability
Client
Client Client
Client
Shared Data
![Page 81: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/81.jpg)
Dataflow– Bach sequential– Pipes and filters
• Reusability• Modifiability• Not interactive• Poor performance
Famous Pattern (Style) categories
![Page 82: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/82.jpg)
Virtual Machine– Interpreter (e.g. Adaptive Object Model)
…
• Portability• Simulation• Adaptability• Low performance
Famous Pattern (Style) categories
![Page 83: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/83.jpg)
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) categories
![Page 84: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/84.jpg)
Independent components– Communicating Processes
• Scalability
– Event Systems
• Modifiability
Famous Pattern (Style) categories
![Page 85: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/85.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
![Page 86: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/86.jpg)
Shared-Memory Style
![Page 87: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/87.jpg)
Abstract D
ata Type Style
![Page 88: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/88.jpg)
Layered Style
![Page 89: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/89.jpg)
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
![Page 90: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/90.jpg)
Software Architecture Analysis Method (SAAM)
![Page 91: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/91.jpg)
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
![Page 92: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/92.jpg)
Steps of SAAM
• Develop Scenarios• Describe Candidate Architectures• Classify Scenarios
– Direct– Indirect
• Perform Scenario Evaluations (for indirect scenarios)
• Reveal Scenario Interaction
![Page 93: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/93.jpg)
Scenarios for ATM example
0. Withdraw money
1. New service: close account and withdraw the remained balance
2. Change hardware
3. Change DBMS
4. Change account record format
![Page 94: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/94.jpg)
AD
T S
tyle Architecture
![Page 95: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/95.jpg)
Layered Style A
rchitecture
![Page 96: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/96.jpg)
Comparison
Scenario 0
Scenario 1
Scenario 2
Scenario 3
Scenario 4
Contention
ADT Direct 0 - 0 0 -
Layered Direct 0 + 0 0 +
For these scenarios layered architecture is superior to ADT architecture
![Page 97: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/97.jpg)
Other Issues about SA
• Product-Line Architectures• Architecture Description Languages (ADL)
– Run-Time Re-Configuration of Architecture• Architecture Reconstruction• Information Architecture• Enterprise Architecture
![Page 98: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/98.jpg)
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
![Page 99: An Introduction to Software Architecture. Introduction](https://reader035.vdocument.in/reader035/viewer/2022081417/56649da75503460f94a93631/html5/thumbnails/99.jpg)
Good References
Pattern Books:• Design Patterns: Elements of Reusable
Object-Oriented Software• Analysis Patterns: Reusable Object
Models• Pattern-Oriented Software Architecture