The non-functional characteristics of software have a significant impact on the development and maintenance effort of the software system, the overall operability, and the computer resources consumed. In addition to affecting the quality and architecture of the application, non-functional characteristics also affect the functional characteristics of the system. The larger the scale of the software system, the higher the complexity, the longer the life cycle and the more important the non-functional features.
Software Architecture Non-Functional Characteristics
- Modifiability
- interoperability
- effectiveness
- reliability
- Testability
- reusability
1. Modifiability
The life cycle of large industrial and commercial software systems is usually very long, sometimes as long as 20 years or more. Many of these applications are not static after development, but evolve throughout their life cycle. The original needs will change, and new needs will emerge. In order to reduce maintenance costs and modification efforts, an application's software must be ready for modification and evolution.
Causes of software aging
- Immutable (
lack of mevement): If the software is not updated, it will inevitably age - Blind (
ignorant surgery): The person who modified the software did not understand the original design, and the software architecture was gradually destroyed - Software is inflexible from the start
- Insufficient documentation and less and less clear understanding of the system over time
Consequences of software aging
- Increasingly difficult to keep pace with the market by introducing new features
- Performance is getting lower and lower
- Reliability is getting worse
Solution
- Provide accurate documentation
- Retain the original structure when modifying
- careful review
- Software should be ready for modification from the beginning
Modifiability includes content
maintainability
Mainly refers to repair problems, that is, the "repair" of the software system after an error occurs. If the software architecture is adequately prepared for maintenance, this usually requires only local changes, and the side effects of changes to other components can be minimized.
Scalability
Mainly refers to adding new functions to a software system, replacing components with improved versions, and removing redundant or unnecessary functions and components. To improve scalability, the components of a software system must be loosely coupled. This creates an architecture that lets you replace components without affecting its clients, and supports adding new components to existing architectures
reorganization
To reorganize the components of a software system and their relationships, such as adjusting the location of a component and moving it to another subsystem, to support software system reorganization, the relationship between components must be carefully designed. Ideally, it should be possible to configure the component flexibly without affecting other major parts of the implementation
portability
Refers to modifying a software system to support a variety of hardware platforms, user interfaces, operating systems, programming languages, or compilers. To provide portability, the software system needs to be organized in such a way as to identify dependencies on hardware, other software systems, and environments. part, put it in special components such as system library and eternal interface library.
2. Interoperability
Software in a system is not independent and often needs to interact with other systems or environments. To improve interoperability, software architectures must provide explicit access to externally visible functions and data structures.
Another aspect of interoperability is the interaction of programs with software systems written in other programming languages.
3. Efficiency
Efficiency is related to the resources used to execute the software and its impact on responsiveness, throughput, and storage space consumption.
To improve the efficiency of the application, it is not just relying on the use of sophisticated algorithms, it is also important to reasonably allocate responsibilities between components and the degree of coupling between components.
In distributed software systems, efficiency also plays an important role. The underlying IPC (inter-process communication) of distributed applications must be fast enough to transmit messages and data at a high enough speed. Patterns such as Forwarder-Reciever are dedicated to Solving efficiency problems, however, many patterns add a degree of indirection to solving problems, which may reduce rather than increase efficiency
4. Reliability
Reliability is the ability of a software system to continue to function regardless of whether an application or system fails or is used in an unexpected or erroneous manner by a user. Generally, reliability can be divided into two aspects.
- Fault Tolerance: Its goal is to ensure correct behavior and self-healing when an error occurs, such as a distributed software system re-establishing a connection to a remote component when the connection is lost, after fixing such an error, the software system can continue or re-execute when the error occurs The operation being performed.
- Robustness: refers to the protection of an application against incorrect usage and invalid input, ensuring that it is in a specified state in the event of unexpected errors. Note that, unlike fault tolerance, robustness does not necessarily mean that the software will continue to run in the event of a spontaneous error, it may only guarantee that the software will terminate in a specified manner.
Software architecture has a significant impact on the reliability of software systems. In order to improve reliability, software architecture can take the following methods:
- Intentionally adding redundancy to the application
- Integrated monitoring components or error handling
5. Testability
Software systems are growing in size and complexity, especially for industrial software, making testing more difficult and expensive.
To simplify the evaluation of the correctness of software systems, it depends on the support of the architecture. The software architecture that supports testability helps to find and fix bugs, and it is also easier to temporarily integrate debug code and debug components.
6. Reusability
Reusability is one of the most discussed topics in current software engineering. It is expected to reduce the development time and cost of software systems and improve software quality. Reusability mainly includes two aspects: developing software through reuse and considering reuse during development.
- Develop software through reuse: This means reusing components and artifacts of existing projects or commercial libraries, design analysis, design specifications, or code components.
- Consider reuse when developing software: Focus on generating components that can be reused in future projects when developing software. This requires that the software architecture of the currently developed application allows the older parts to be independent of each other, so that they can be used in other systems without major modifications. use them
concluding remarks
Non-functional features can be both contradictory and complementary. For example, when providing duplicate application functionality to support fault tolerance, the resulting fabric is inefficient and expensive compared to a fabric that does not provide this redundancy. Determining the non-functional requirements of a software architecture obviously requires considering the interdependencies between different non-functional requirements and making necessary trade-offs, as well as determining the priority of different non-functional requirements, giving priority to one requirement in the event of a conflict, while Let go of another need.
Although non-functional characteristics are very important for software architecture, it is difficult to measure the extent to which these characteristics are possessed. Among the detailed indicators that software architecture must meet, only a few non-functional characteristics are included. Therefore, Estimating the extent to which a software architecture possesses a given non-functional characteristic relies primarily on the experience of the software engineer.