Introduction to Software Architecture (1.5 Software Architecture Design…
Introduction to Software Architecture
Goal of software design
to build a model that meets all customer requirements and leads to successful implementation
Any software, regardless of its application domain, should have an overall architecture design that guides its construction and development.
The success of a software product or system largely depends on the success of its architecture design.
What is the architecture design?
The architecture design representation is derived from the system requirement specification and the analysis model.
“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 theway in which architecture can be implemented” (Garlan and Shaw, 1996)
Who is responsible for developing the architecture design?
Software architects and designers are involved in this process
They translate (map) the software system requirements into architecture design.
During the translation process, they apply various design strategies to divide and conquer the complexities of an application domain and resolve the software architecture.
Why is software architecture design so important?
A poor design may result in a deficient product that doesnot meet system requirements, is not adaptive to future requirement changes, is not reusable, exhibits unpredictable behavior, orperforms badly.
Without proper planning in the architecture design stage, software production may be very inefficient in terms of timeand cost.
In contrast, a good software design reduces the risks associated with software production, helps development teams worktogether in an orderly fashion, makes the system traceable for implementation and testing, and leads to software products that havehigher quality attributes.
When is software design conducted?
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
What is the outcome of the software architecture design?
The IEEEStd 1016-IEEE Recommended Practice for Software
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 eachmodule
design overview, purpose, scope
decomposition description (module, data, process)
dependency and connection description (between modules, data, and processes)
user interface description
detailed design (module and data)
1.2 Software Architecture: Bridging Requirements and Implementation
mechanisms used to specify a software requirement
software architect's tasks
Perform static partition and decomposition of a system into subsystems and communications among subsystems. A software element can be configured, delivered, developed, and deployed, and is replaceable in the future. Each element's interface encapsulates details and provides loose coupling with other elements or 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 trade-off analysis on quality attributes and other nonfunctional requirements during the selection of architecture styles. The selection of element type and connector type will have a direct impact on system properties and its quality attributes. Many quality attributes must be taken into account early in the design phase. For example, in order to increase a distributed system's extensibility,portability, or maintainability, software components and Web services may be the best choice of element types, and a loose connection among these elements may be most appropriate. The architects need to have stakeholders involved in this process.
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. If it is not possible to satisfy all requirements, system analysts and software architects can use the architecture designs to communicate with stakeholders.
Role of Software Architecture in SDLC
The architecture design provides a blueprintand guideline for developing a software system based on its requirement analysis specification.
The architecture design embodies the earliest decisions that have a decisive impact on the ultimate success of the software product.
The design shows how the system elements are structured, and how they work together.
An architecture design must cover the software's functional and non-functional requirements as well.
It serves as an evaluation and implementation plan for software development and software evolution.
what an architecture design typically looks like
Notice that it does not contain the complete set of information found in a development blueprint.
In Figure 1.2, each element (also called a “subsystem”) symbolizes a sole responsibility such as business logic processing, logic control, interface presentation, data gathering, and service brokering and mediating.
This division of elements is based on their functionality, location, and runtime images.
The elements may be in the form of modules, objects, packages, deployed elements, tasks, functions, processes, distributed programs, etc.
The topology of the static structure focuses on the system composition configuration such as layered, flattened, star-typed, centralized, or distributed
The dynamic runtime connectors may be batch-sequential, multithreaded, explicit direct invocation, implicit indirect invocation (such as message queue or event notification), synchronous or asynchronous communication, peer-to-peer message exchange or message broadcasting, or another applicable coordination and cooperation mechanism among the elements
1.3 Architecture Styles
What is it?
An architecture style (also known as an “architecture pattern”) abstracts 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 run-time interaction of flow control and data transfer.
elements that perform functions required by a system
connectors that enable communication, coordination, and cooperation among elements
constraints that define how elements can be integrated to form the system
attributes that describe the advantages and disadvantages of the chosen structure
multi-tier architecture style
How it work?
The middle-ware element gets the requests from the client element, processes the requests based on the business logic, and sends a data request to the back-end tier
The data store server element manages data querying and updating
The client element is responsible for GUI interface presentation, accepting user requests, and rendering results.
What is it?
Multi-tier architecture is commonly used for distributed systems. It usually consists of three element types: client, middle-ware server, and data server.
the data store plays a central role and it is accessed frequently by other elements that modify data.
input data is transformed by a series of computational or manipulative elements
functions and procedures are the elements organized in a control hierarchy with a main program invoking several subprograms.
elements are represented as objects that encapsulate data and operations, and the communication among them is by message passing
each module or package completes tasks that progress in a framework from higher-level abstractions to lower-level implementations
Why are architecture styles so important?
Because each style has a set of quality attributes that it promotes.
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
What is quality attributes?
Each architecture style has its advantages, disadvantages, and potential risks
Choosing the right style to satisfy required functions and quality attributes is very important.
Quality attributes are identified in the requirement analysis process
categorized of quality attributes
Implementation attributes (not observable at runtime)
universal accessibility and the ability to exchange data among internal components and with the outside world.
Interoperability requires loose dependency of infrastructure.
Maintainability and extensibility
the ability to modify the system and conveniently extend it.
the degree to which the system facilitates the establishment of test cases.
Testability usually requires a complete set of documentation accompanied by system design and implementation.
the system's level of independence on software and hardware platforms.
Systems developed using high-level programming languages usually have good portability.
One typical example is Java—most Java programs need only be compiled once and can run everywhere.
a system's ability to adapt to an increase in user requests.
Scalability disfavors bottlenecks in system design.
the ease of system modification to cater to different environments or problems for which the system was not originally designed.
Systems developed using component-based architecture or service-oriented architecture usually possess this attribute.
Runtime attributes (observable at runtime)
increasing a system's efficiency with regard to response time, throughput, and resource utilization, attributes which usually conflict with each other.
the level of human satisfaction from using the system.
Usability includes matters of completeness, correctness,compatibility, as well as a friendly user interface, complete documentation, and technical support.
a system's ability to cope with malicious attacks from outside or inside the system
Security can be improved by installing firewalls, establishing authentication and authorization processes, and using encryption.
the failure frequency, the accuracy of output results, the Mean-Time-to-Failure (MTTF), the ability to recover fromfailure, and the failure predictability.
a system's capability to be available 24/7
Availability can be achieved via replication and careful design to cope with failures of hardware, software, or the network.
Maintainability (extensibility, adaptability, serviceability, testability, compatibility, and configurability):
the ease of software system change.
Time to market:
the time it takes from requirements analysis to the date a product is released.
the expense of building, maintaining, and operating the system.
the period of time that the product is “alive” before retirement.
Typical quality attribute tradeoff
In many cases, no single architecture style can meet all quality attributes simultaneously.
Software architects often need to balance tradeoffs among attributes.
Tradeoff between reliability and performance
For instance, Java programs are well protected against buffer overflow due to security measures such as boundary checks on arrays
Such reliability features come at the cost of time efficiency, compared with the simpler and faster C language which provides the “dangerous,” yet efficient, pointers.
Tradeoff between scalability and performance.
For example, one typical approach to increase the scalability of a service is to replicate servers.
To ensure consistency of all servers (e.g., to make sure that each server has the same logically consistent data), performance of the whole service is compromised.
Tradeoff between space and time
For example, to increase the time efficiency of a hash table means a decrease in its space efficiency.
1.5 Software Architecture Design Guidelines
Think of what to do before thinking of how to do it.
Functional and nonfunctional requirements should be identified, verified, and validated before architecture and detailed design work is done.
Using an abstract architecture design to communicate with stakeholders helps avoid the need to overhaul the system design in later stages of the software development cycle.
Think of abstract design before thinking of concrete design
Always start with an abstract design that specifies interfaces of components and abstract data types.
Use multiple levels of abstraction if necessary.
Make implementation decisions based on the abstract interfaces instead of the concrete ones because those are more stable—they are the contracts between service providers and service requesters, so they are defined at the early stages of the software development cycle.
Think of nonfunctional requirements early in the design process.
Communicate with stakeholders and document their preferences for quality attributes.
If it is not possible to find a design that meets all quality attributes, try to find the right balance of quality attributes and consider heterogeneous architecture styles when necessary.
When you map functional requirements to an architecture design, you should consider nonfunctional requirements as well.
Think of software reusability and extensibility as much as possible.
For most software systems, it is likely that new functionalities will be added after the systems are deployed.
You 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.
Try to promote high cohesion within each element and loose coupling between elements.
loose coupling means less inter-dependency between components, so the change of one component is not likely to cause ripple-changes of other components.
A highly coherent subsystem, component, or module performs one sole function.
Tolerate refinement of design.
Never expect to have software design completely perfect in one step. You may need to use prototyping and iteration to refine the design.
Avoid ambiguous design and over-detailed design
Ambiguous design lacks constraints and over-detailed design restricts implementation.