Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Architecture Design Illuminated - Coggle Diagram
Software Architecture Design Illuminated
Chapter 1: Introduction to Software Architecture
1.3 Architecture Styles
An architecture style (also known as an "architecture pattern") abstractsb the common properties of a family of similar designs.
An architecture style contains a set of rules, constraints, and patterns of how to structure a system into a set of elements and connectors.
It governs the overall structure design pattern of constituent element types and their runtime interaction of flow control and data transfer.
Key components of an architecture
style are:
Connectors that enable communication, coordination, and cooperation among elements
Attributes that describe the advantages and disadvantages of the
chosen structure
Elements that perform functions required by a system
Constraints that define how elements can be integrated to form
the system
Why are architecture styles so important?
By identifying the styles that a software architecture design supports, we can verify whether the architecture is consistent with the requirement specifications, and identify which tactics we can use to better implement the architecture
1.4 Quality Attributes
By identifying the styles that a software architecture design supports, we can verify whether the architecture is consistent with the requirement specifications, and identify which tactics we can use to better implement the architecture
Quality attributes can be categorized
Implementation attributes (not observable at runtime)
Interoperability
Testability
Interoperability
Testability
Testability
Testability
Runtime attributes (observable at runtime)
Performance
Usability
Security
Reliability
Availability
Maintainability
Business attributes
Cost
Lifetime
Time to market
Typical quality attribute tradeoff pairs include
Tradeoff between reliability and performance
Tradeoff between scalability and performance
Tradeoff between space and time
1.2 Software Architecture: Bridging Requirements and
Implementation
Software architecture
shows how the system elements are structured, and how they work together
must cover the software's functional and
nonfunctional requirements
Provides a blueprint and guidelines for developing a software system based on its requirement analysis specification
serves as an evaluation and implementation plan for software development and software evolution
System Architecture
"the fundamental organization of a system embodied in its elements, their relationships to each other, and to the environment, and the principles guiding its design and evolution" (Maier, Emery, Hilliard)
"the description of elements that comprise a system, the interactions and patterns of these elements, the principles that guide their composition,and the constraints on
these elements" (1Garlan and Shaw-1996)
depends on the Software Requirement Specification (SRS)
produced by analysis in the first step of SDLC.
There are two aspects of software
requirements: functional and nonfunctional.
A functional requirement specifies the functionality of the software system whereas
A nonfunctional requirement specifies system qualities, constraints, and behaviors.
A complete software architecture specification must describe not only the elements and connectors between elements, but also the constraints and runtime behaviors so that developers know what and how the design should be implemented.
Lists a software architect's tasks
Perform static partition and decomposition of a system into subsystems and communications among subsystems.
Consider and evaluate alternative architecture styles that suit the
problem domain at hand.
Perform static partition and decomposition of a system into subsystems and communications among subsystems.
Perform tradeoff analysis on quality attributes and other nonfunctional requirements during the selection of architecture styles.
1.5 Software Architecture Design Guidelines
Think of abstract design before thinking of concrete design.
Think of nonfunctional requirements early in the design process
Think of what to do before thinking of how to do it.
Think of software reusability and extensibility as much as possible
Try to promote high cohesion within each element and loose coupling
between elements.
Tolerate refinement of design.
Tolerate refinement of design.
How are architecture designs described?
UML notation is one of many solutions, in addition to text documentation, that are available to designers.UML provides graphic notations that are available to architects and designers in nearly every stage of SDLC
1.1 Overview
Why is software architecture design so important?
A good software
design
Helps development teams work together in an orderly fashion
makes the system traceable for implementation and testing
Reduces the risks associated with software production
and leads to software products that
have higher quality attributes
A poor design
is not adaptive to future requirement changes
Product does not meet
system requirements
is not reusable
performs badly
exhibits unpredictable behavior
Without proper planning in the architecture design stage, software production may be very inefficient in terms of time and cost.
When is software design conducted?
Software design is an early phase of
the Software Development Life Cycle (SDLC).
Software designers model the system and assess its quality so that improvements may be made before the software goes into the production phase.
Who is responsible for developing the architecture design?
Software architects and designers
They translate (map) the
software system requirements into architecture design.
Apply various design strategies to divide and conquer the
complexities of an application domain and resolve the software architecture.
What is the outcome of the software architecture design?
The SDD serves as the blueprint for the implementation phase. It describes the elements of a system, the modules that compose each element, and the detailed information (such as data attributes, operations, and algorithms) of each module. The SDD is used as a template for software design description
It is an overall representation of the software to be built.
SDD
decomposition description (module, data, process)
dependency and connection description (between modules, data,
and processes)
design overview, purpose, scope
user interface description
user interface description
attributes
The architecture design
defines the relationship between major structural elements of the software, the styles and design patterns that can be used to achieve the requirements defined for the system, and the constraints that affect the way in which architecture can be implemented
The architecture design representation is
derived from the system requirement specification and the analysis model.
Chapter 2: Software Architecture Design Space
2.4 Software Connectors
Software connectors are classified according to many attributes, including synchronization mode, initiator, implementation type, active time span, fan-out, information carrier, and environment.
The connector's
synchronization mode
A blocking connector allows one of its incident elements to send a request (method call or message) to another and wait for a response (method return value or message).
A non-blocking connector allows one of its incident elements to send a request (method call or message) to another and then continue its execution without waiting for a response
The connectors in a software architecture are refined during the design process and are heavily influenced by a project's deployment environment.
The connector's initiator
A one-initiator connector allows only one of its two incident elements to make a request to the other element, but not the another way around.
A two-initiator connector allows either one of its two incident elements to make a request to the other element. For a system to support callback between its two subsystems, the two subsystems must be connected by a two-initiator connector.
The information flow on a connector can be implemented using various information carriers
The implementation type
Signature-based connectors, the method's name indicates an operation, and the parameters carry argument values for the operation's execution.
We assign one or more method parameter to indicate operation types, the connector can be used to implement protocols.
Connector active time
Programmed connectors
Event-driven connectors
Connector span
Local connectors :This connector attribute depends on whether the incident elements are located in the same processor.
Networked connectors are normally implemented with the proxy design pattern to support object-oriented programming paradigm in a distributed environment.
Connector fan-out
1—1 connectors
1—* connectors
Connector environment
The incident elements of a homogeneous connector are implemented with the same programming language and software
framework and run on the same operating system
The incident elements of a heterogeneous connector may be implemented with different programming languages or software frameworks and may run on different operating systems.
2.5 An Agile Approach to Software Architecture Design
Agile approach for developing software architectures that maximizes the reuse of architecture, design, and implementation investments.
Given a project specification, an abstract high-level software architecture will first be proposed, and attributes will be identified for its elements and connectors.
Abstract software architecture will
generally be free of deployment considerations
Abstract software architecture will
generally be free of deployment considerations
The unique features of this approach include the delayed binding of software connectors for more flexible implementation decisions and the seamless integration of multiple architecture styles in realizing different subsystems or levels of the same system.
2.3 Software Elements
At runtime each software element has well-defined functions and connects to the other elements into a dependency graph through connectors.
The elements of a software architecture are usually refined through multiple transformation steps based on their attributes and the project requirement
specifications
the basic guidelines for mapping runtime elements into
their implementations:
If an element is not reentrant and multiple threads or processes need to communicate with it, it must be run on separate threads or processes in order to be thread-safe (meaning that the system behavior is not affected by the multiplicity of threads executing concurrently).
If an element has high multiplicity and its performance is important to the global system performance, an application server (a software system running business logics) should be used for the element's implementation so that it can take advantage of thread and resource pooling, data caching, and dynamic element life cycle management to conserve resources.
If an element is reentrant, it can be implemented by a thread or a
process.
If the elements contain heavy computations for deployment at a particular location, a cluster of processors will enhance CPU data processing power.
If the elements contain heavy computations for deployment at a particular location, a cluster of processors will enhance CPU data processing power.
If the elements contain heavy computations for deployment at a particular location, a cluster of processors will enhance CPU data processing power.
A complex element can be transformed into a sequence of vertical layered elements if each layer provides a virtual machine or nterface to its immediate upper-layer element, and each layered element hides away some low-level system details from the upper layers
A complex element can be transformed into a sequence of vertical layered elements if each layer provides a virtual machine or interface to its immediate upper-layer element, and each layered element hides away some low-level system details from the upper layers
2.2 Types of Software Structures
2.2.1 Software Static Structure
The main software elements are source code
modules or files
Each module has assigned functional and nonfunctional
attributes, and the public APIs
defined for each module separate the module's interfaces and implementations.
Defined for each module separate the module's interfaces and implementations.
Synchronization: A method invocation can be synchronous or
asynchronous.
Sequence: Some connectors must be used in a particular sequence.
Direction: If module A invokes a method of module B during execution, there is a unidirectional connector from module A to module B.
At software deployment time, the elements are binary versions of the project modules and Hies
Static structure affects the architecture's clarity, construction strategy, maintenance, reengineering, reusability, etc.
Managing static structures involves layers of abstraction and of refinement showing visibility and encapsulation, respectively. These two
notions define different kinds of hierarchical relations :
A tree-like hierarchy of refinement relations is formed when an abstraction (i.s., a component) is implemented, and recursively divides into subcomponents.
A linear client-server relation is formed when a component provides primitive abstractions to another component.
2.2.2 Software Runtime Structure
Element
Same element in a code structure
may implement or support multiple runtime elements
Several code structure elements may implement or support
a single runtime element.
Run on the same computer or on
multiple computers across a network.
The connectors
Inherit attributes from their source-code structure counterparts, along with the following other attributes
Distance and connection media: Two connected elements may communicate in the same thread, in the same process, on the same computer, or on different computers across a network.
Universally invocable: A connector with this attribute set to true allows any external software system, no matter what hardware/
software platforms they run on and in which programming languages or software frameworks they are developed, to invoke the method at the connector's target. This attribute is critical for heterogeneous enterprise information systems that must be integrated efficiently.
Multiplicity: One element can be connected to multiple elements if
it needs to invoke methods of multiple elements at runtime.
Self-descriptive: A connector with this attribute set to true can
allow an external software system to invoke its target method without the pre-installation of any software specific to the method.
A software architecture design can be described
with various software structures, each from a different perspective.
Static structure
Software modules
Software component deployment units
Files
Dynamic structure
Processes
Transactions
Threads
Objects
Sessions
Software component instances at execution time.
2.2.3 Software Management Structure
A large software project is normally designed and implemented by several project teams, each having its well-defined responsibilities at specific SDLC process stages
Each element consists of manipulation (design, implementation, debugging, etc.) of specific code units assigned to each project team,
The connectors are derived from runtime dependency among the code units and software process dependencies.
Software runtime structures serve as the technical backbone of architecture designs and provide the basis from which other structures are derived.
2.1 Overview
A software architecture design is a set of software elements connected by a set of connectors.
Dynamic structure
A software element can be a process, an object, an instance of a software component, or a service.
The connectors between a pair of software elements can be implemented in various forms including local method invocations, remote method invocations, service calls, and messaging through a message queue,
The connectors can also work in synchronous or asynchronous nodes.
Static structure
A software element can be a package, a class,
a component, or a loadable library
A software element can be a package, a class,
a component, or a loadable library