Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Architecture Design - Coggle Diagram
Software Architecture Design
Chap 1 : Introduction of Software Architecture
Software Architecture: Bridging Requirements and
Implementation
The most important job of a software architect is to map the Software Requirements Specification to the software architecture design and guarantee that functional and nonfunctional requirements are met
Role of software architecture
The architecture design provides a blueprint and guideline
for developing a software system based on its requirement analysis specification
Highlights early design decisions
Shows how system is structured
Covers functional and non-functional requirements
Definition of software architecture
IEEE Std 1471 defines system architecture as "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).
Garlan and Shaw define software architecture as "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" (1996) :
Software architect's tasks
Perform static partition and decomposition of a system into subsystems and communications among subsystems
Establish dynamic control relationships among different subsystems in terms of data flow, control flow orchestration, or message dispatching.
Consider and evaluate alternative architecture styles that suit the
problem domain at hand
Perform tradeoff analysis on quality attributes and other nonfunctional requirements during the selection of architecture styles
Architecture Styles
An architecture style (also known as an "architecture pattern") abstracts the common properties of a family of similar designs.
It contains a set of rules, constraints, and patterns of how to structure a system into a set of elements and connectors
It governs runtime interaction of flow control and data transfer.
Key components
Elements that perform functions required by a system
Connectors that enable communication, coordination, and cooperation among elements
Constraints that define how elements are integrated to form the system
Attributes that describe the advantages and disadvantages of the chosen structure
Advantage
Saves cost and time on design
Architecture style represents layout topology of elements
Once overall structure determined, rest are easy to do
How to choose architecture style?
Depends on how quality attributes are satisfied
Each architecture style has its advantages, disadvantages, and potential risks. Choosing the right style to satisfy required functions and quality attributes is very important.
Overview
The goal of software design is to build a model that meets all customer requirements and leads to successful implementation.
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
Software architects and designers are responsible for developing the architecture design
What is architectural design?
It defines the relationship between major structural elements
It also define the styles and design patterns used to achieve requirements
Also the constraints that affects the way architecture can be implemented.
Software design is an early phase of the Software Development Life Cycle (SDLC). During this phase, software designers model the system and assess its quality so that improvements may be made before the software goes into the production phase.
The architecture of a system is its 'skeleton'. It's the highest level of abstraction of a system
Software architecture is more about the design of the entire system, while software design emphasizes on module/component/class level.
System Analyst or Software Architect do the architectural design
Software design
In software design, there are 2 steps
Architectural Design
Architecture design is front strategy for the detailed design
describe user accessible components and the interconnections among them that are visible to stakeholders
Detailed Design/Tactical design
specify the internal details of each component and might introduce new invisible components – to the stakeholder, into the design.
Software Design Description (SDD)
is an overall representation of the software to be build.
Describes high and low level design
Components of the system
Modules of each components
Detailed information of each module:
+Data attributes
+Operations
+Developer
...
DB oriented application - data dictionary like
Tables, columns and definition of terms.
this is the outcome of software architecture design
Depends on the Software Requirement Specification (SRS)
produced by analysis in the first step of SDLC
Quality Attributes
Quality attributes are identified in the requirement analysis process
Base on 3 categories
Implementation attributes
Interoperability
Universal accessibility and ability to exchange data among internal components and the outside world
Requires loose dependency of infrastructure
Maintainability & Extensibility
The ability to modify the system and conveniently extend it
Testability
Whether the system allows easy debugging
Portability
Can the system be deployed on different platforms
Scalability
Can system adapt to increase of requests
Flexibility
Ease of modification of system to cater to a different environment
Runtime attributes
Availability
If system is available 24/7
Can be enhanced by replication
Security
The ability to defend against attacks
Performance
Time efficiency and resource efficiency
Usability
Completeness, correctness, compatibility and user friendliness
Business attributes
Time to market:
The time it takes from requirement analysis to the product is released
Cost:
Expense of the building, maintaining, and operating the system,
Lifetime:
The period of time that the product is alive before retirement.
Quality Attribute Trade-Off
Tradeoff between space and time.
For example, to increase the time efficiency of a hash table or algorithm means to decrease its space efficiency.
Tradeoff between reliability and performance
Java Program – array boundary check => performance down
C/C++ has no such checking and fast
Tradeoff between scalability and performance.
Sacrifice performance for consistency
Software Architecture Design Guidelines
Think of What to Do before How to Do It.
System requirements (functional and non-functional requirements) must be nailed down before design starts
Notice, different stakeholders have different opinions
Clarify priority of all requirements before design
Think about abstract design before thinking about concrete design.
Always starts with abstraction
Use multiple level of abstraction if necessary
Nail down the interface but leave room of change for implementation
Using an abstract architectural design of a system to communicate with stakeholders helps avoid overhauling the system design in later stages of the software development cycle
Make all implementation decisions depend on the abstract interfaces instead of concrete ones because those are more stable
Think of non-functional requirements early in design process
Speed, Reliability, Security have to be considered first
Otherwise, very hard to change your design to reflect these requirements
The earlier, the better
It is not possible to find a design that meets all quality attributes.
Balance the quality attributes, and consider heterogeneous architecture styles when necessary.
Think of reusability and extensibility!
User requirements can change frequently
Extensibility is very important
Leave room for expansion
we need to consider how to reuse existing software components to increase the reliability and cost-effectiveness of new systems
Always try hard to make software extensible in the future
High Cohesion and Loose Coupling
Try to promote high cohesion within each element and loose-coupling between elements
One component (module) should be assigned ONE functionality only
Design should be logically clear
The less correlation between modules, the better!
Easy debugging and maintenance
Also allows great extensibility
Tolerate refinement of design.
Never expect to have software design completely perfect within one step.
We may need to use prototyping and iteration to refine the software design.
Avoid ambiguous design and over-detailed design.
Ambiguous design lacks constraints
Over-detailed design restricts implementation.
Chapter 2 Software Architecture Design Space
Overview
A software architect’s responsibility:
proposing a concrete architecture that best supports the detailed design and implementation of a specific project.
Software architect must understand the software architecture's design space:
design alternatives that can support functional and non-functional requirement specifications
Architectural design space based on quality attributes
Make the decision by balancing on quality attributes.
Types of Software Structures
Software Static Structure
A software project is typically implemented in multiple files . This includes
-Executable files
-Library files
-Binary software component modules
+DLL
+JavaBeans
-Deployment descriptors
-Others resources files
At software development time
+The main software elements are source code files
+Each modules has assigned functional and nonfunctional attributes
+API defined for modules separates module’s interface and implementation
+The connectors at this level are in the form of module dependency
Static connectors may exhibit some attributes
Direction
If module A invokes a method of module B during execution, there is a unidirectional connection from module A to module B
Synchronization
Can be synchronous or asynchronous
Sequence
Some connectors must be used in a particular sequence
At deployment time:
+The elements are binary versions of the project modules and files.
+Several source code modules may be packaged into the same deployment unit
+The connectors in the deployment structures are basically the same as those for the source module structures
Managing Static Structural
The software static structure :
+refers to the organization of physical software modules and their interrelations
+This structure play a critical roles in software architecture design.
tatic structure affects the architecture's clarity, construction strategy, maintenance, reengineering, reusability…
It plays a crucial role in the management of large software systems because it deals with the packaging of software modules in order to facilitate system construction and maintenance through a clear portrayal of intermodule relations.
Managing static structures involves layers of:
+Abstraction for encapsulation
+Refinement showing visibility
Two kinds of static hierarchical relations
A linear client-server relation is formed when a component provides primitive abstractions to another component
A tree-like hierarchy of refinement relations is formed when an abstraction is implemented, and recursively divides into subcomponents. A refinement relation specifies how a module (parent) is decomposed into a refinement module (child).
Software Runtime Structure
A runtime project consists of elements:
+Processes
+Threads
+Web services
+Distributed objects
These elements may run on the same computer or on multiple computers across a network.
Software runtime structures serve as the technical backbone of architecture designs and provide the basis from which other structures are derived.
The same element in a code structure can implement or support multiple runtime elements
The same element in a code structure can implement or support multiple runtime elements
In a client-server application, the same client module may run on many client computers
Several code structure elements may implement or support a single runtime element
Many threads may run multiple methods from different classes that may be packaged in different code units
Run-time Connector Properties
Runtime connectors inherit attributes from their source-code structure counterparts, with a few extra attributes
Multiplicity
One element can be connected to multiple elements if it needs to invoke methods of multiple elements at runtime
Distance and connection media
Two connected element may communicate in the same thread, in the same process , on the same computers, or on different computers across a network
Media can be –
+Copper/optical
+Wired/wireless LAN
decides the system performance and reliability
Universal invocable:
A connector with this attribute set to true allows any external software system to invoke the methods at the connector’s target, irrespective of hardware/software platform, and programming languages
Important for heterogeneous system
Self-descriptive:
A connector with this attribute set to true allows any external software system to invoke its target method without pre-installation of any software specific to the method.
It allows clients to choose service providers dynamically.
Software Elements
At runtime, element is a self-contained component of a system
Has well-defined functions
+Usually interface is public and fixed, and
+Implementation can change with the time
Connected with each other via connector
The basic guidelines for mapping runtime elements into
their implementations
Reentrant
Reentrant describes a computer program or routine that is written so that the same copy in memory can be shared by multiple users.
A computer program or subroutine is called reentrant if it can be interrupted in the middle of its execution and then safely called again ("re-entered") before its previous invocations complete executing
A programmer writes a reentrant program by making sure that no instruction modify the contents of variable values in other instructions within the program.
Commonly required in operating systems and in applications intended to be shared in multi-use systems.
If an element is reentrant
It can be implemented by a thread or a process
It is more efficient because:
+Avoid many synchronization issues and
+Support shared thread or process
If an element is NOT reentrant and multiple threads or process need to communicate with it
It must be run on separate threads or processes in order to be thread-safe.
Handle Bottle-Neck First
Treat bottle-neck functionality using the following approaches
+Wrap it as a separate and highly independent module
Improving its efficiency by replication
Depending on computing needs, allocate cluster or multi-CPU computers for bottle-neck modules in deployment
Make Things Simple
If a module is too large split it into smaller ones
Vertical Layers
+Each upper layer calls the functionality of lower layers
+Typical Example: OS and Network
Horizontal Layers
+Business logic divided into a sequence of stages
+Example: pipeline
Software Connectors
Connects the modules of a system
Should be refined within the design process.
Connector refinement is heavily influenced by a project’s deployment environment
Usually determines the quality attributes of a system
Efficiency
Reliability
Availability
Security
Can be classified into many categories
Software Connectors Guidline
During the refinement of the software architecture
If the two elements are mapped to a single process, the connector could be mapped to a local method invocation
If the two elements are mapped to two different processes on the same computer, then the connector could be mapped to a local message queue or a pipe
If the two elements are mapped to two different computers, then remote method invocation or Web service invocation could be used for the architectural refinement for the corresponding connector between them
Connector type
Initiator
One Initiator
It only allows one of the two connected elements initiates the request, but not another way around
E.g., web-browser and web server
Two Initiator
either of the two elements can make the request
E.g., call-back between two subsystems, the two subsystems must be connected by a two-initiator connector
Based on Synchronization
Non-blocking
A non-blocking connector allows one of its incident elements to send a request to another and continues its execution without waiting for a response.
Blocking
A blocking connector allows one of its incident elements to send a request to another and wait for a response.
The element will be blocked from further execution until it receives a response.
Information Carrier
Global Variable : for elements in the same process
( most efficient)
Environment resource : for elements in different processes of the same system
Method:
+Local invocation
+Remote invocation
Message (most reliable)
Connector Implementation type
Signature based
Usually method invocation
Signature: the method name plus the list of parameter types
Method parameter indicates operation type
Protocol based
A protocol-based connector can implement multiple operation types with a single binding signature
E.g., HTTP, SMTP, etc.
Connector active time
Programmed
A method call will be made at a time specified at programming time
Event-driven
One element will function as an event source
All elements that need be notified of the event will register as listeners of the event source
When the event happens, all the registered listener elements will be notified for potential reaction
=> Method callback can be considered as a special case of this event-driven mechanism
Connector span
Local
Network
-Invocation semantics (tricky)
-Reliability (hard)
-Security (problematic, e.g. RPC)
-However, desperately needed by distributed computing environments
Connector fan-out
1-1
connecting two elements only
1-*
connecting one element with a variable number of elements of the same type
Connector environment
Homogeneous
both elements must be on the same platform
Heterogeneous
both elements can be on different platforms.
An Agile Approach to Software Architecture Design
Traditional Water-Fall Approach
Big gap between Requirement specification and Software Architecture
Iterative Refinement
Refine designs based on changing requirement
the basic structure not changed but the details can be refined
Software Structures
Software architecture in multiple Perspectives
+Static Structure
+Run-time Structure
+Management structure (or Deployment structure)
Different structures use different elements and connectors, and have different performance attributes
Chapter 3 Models for Software Architecture
UML for Software Architecture
Structural Diagrams
Behavioral Diagrams
Architecture View Models
The Scenario View
The Logical or Conceptual View
The Development or Module View
The Process View
The Physical View
The User Interface View
Architecture Description Languages (ADL)
Chapter 4 Object-Oriented Paradigm
Introducing the Object-Oriented Paradigm
Classes and Objects
Relationships
OO Analysis
Step 1: Design of a UML Use Case Diagram
Step 2: Develop an Analysis Class Diagram via
Noun Extraction
OO Design
Step 1: Identify Classes—CRC Card
Step 2: Construct an Interaction Diagram
Step 3: Build a State Machine Diagram
Step 4: Class Specification
Design Principles
Principle of Decoupling
Ensuring Cohesion
Open-Closed Principle
Chapter 5: Data Flow Architecture
Identified Data Flow Architecture
Whole system as transformation of successive sets of data
System decomposed into modules
Connection can be
IO Stream
Files, Buffers, Pipes
No interaction between modules
Modules do not need to know identity of each other
Batch Sequential
Traditional data processing model
Example: mainframe computers using COBOL
Applicable Design Domains:
Data are batched
Benefits
Simple division between sub-systems
Each sub-system can be a stand-alone
Limitation
No interactive interface
No concurrency and low throughput
High latency
Pipe & Filter
Connectors are stream oriented
Concurrent processing
Basic Concepts
Data Source
Data Sink
Filter:
independent data stream transformer
Reads data from input data stream
Process data and write to output stream
Does not wait for batched data as a whole
Does not even have to know identity of i/o streams
Pipe:
data conduit
Moves data from one filter to another
Two types: character or byte streams
Three way to make data flow
Push only (Write only)
Pull only (Read only)
Pull/Push (Read/Write)
Classification of Filters
Active Filter
pulls in data and push out the transformed data (pull/push)
It works with a passive pipe that provides read/write mechanisms for pulling and pushing.
Passive filter
Lets connected pipe to push data in and pull data out.
The filter must provide read/write mechanisms in this case.
Applicable Design Domain
System can be broken into a series of processing steps over data stream, in each step filter consumes and moves data incrementally.
Data format on the data stream is simple and stable, and easy to be adapted if it is necessary.
There are significant work which can be pipelined to gain the performance
Suitable for producer/consumer model
Advantage and Disavantaged
Advantage
Concurrency is high.
Reusability is easy – plug and play.
Modifiability: Low due to coupling between filters
Simplicity: Clear
Flexibility: High, very modular design
Lower latency
Disavantage
Not suitable for dynamic interactions
Data standards (ASCII, XML?)
Overhead of data transformation among filters such as parsing is repeated in two consecutive filters
Difficult to configure a P&F system dynamically.
Error handling issue
Process Control Architecture
Suitable for embedded System
Composed of
Sub-systems
Connectors
Two types of sub-systems
+executor processor unit
+controller unit
System depends on: Control Variables
Data
Controlled variable: target controlled variable
Input variable: measured input data
Manipulated variable: can be adjusted by the controller
Applicable Domains
Embedded software system involving continuing actions.
Needs to maintain an output data at a stable level
The system has a set point which is the goal the system will reach and stay at that level
Pros and Cons
Benefits
+Better for situations where no precise formula for deciding the manipulated variable
+Can be completely embedded
Limitations:
Requires more sensors to monitor system states
Chapter 6: Data-Centered Software Architecture
Overview
Data-centered SW Architecture is characterized by a centralized data store that is shared by all surrounding software components
The connection between the data module and the software components is either implemented by explicit method invocation or Implicit method invocation
Classification
Repository
Data store is passive
Clients of the data store are active
Variants of Data Repository
Virtual repository
+Built up on the top of multiple physical repositories
+Most DB allows users to create views that are virtual repositories since they do not exist physically
Benefits
+Simplify the overall complexity of overall database structure +Security management in terms of scope of data of manipulation for different users
Distributed repository system (distributed database system)
All data are distributed over all sites linked by network
Data are replicated in order to improve reliability and local accessibility
Other issues - concerns
Vertical or horizontal partitions
Synchronization of duplicated data
Cost of data transmission
Collaboration (two-phase transaction commitment)
Suitable for large complex information system
Data transactions drive the control flow
Pros
Data integrity: easy to backup and restore,
System scalability and Reusability of agents: reduce the overhead of transient data between software components
Cons
Data store reliability and availability
High dependency between data structure of data store
Overhead cost of moving data on network
Blackboard
variation of data-centric
Consists of three partitions
Blackboard(Used to store data)
Knowledge Source(stores domain specific knowledge)
controller (initiating the blackboard and knowledge sources)
Blackboard Arch. in Box-Line
Each knowledge source is relatively independent
They don’t need to interact with each other
Only interact and respond to the blackboard subsystem
Pros
Scalability: easy to add new knowledge source
Concurrency: all knowledge sources can work in parallel
Reusability of knowledge source agents
Cons
Tight dependency between the blackboard and knowledge source
Synchronization of multiple agents is an issue
Debugging and testing of the system is a challenge
Application Domain
Suitable for solving immature and complex AI problems
The problem spans multiple disciplines, each of which has complete different knowledge expertise
Optimal, partial, or approximate solution is acceptable
Exhausted searching is impossible.