The system software architecture depicts the organization or structure of a system and provides an explanation of how it behaves. A system is a set of components that perform a particular function or set of functions. In other words, software architecture provides a solid foundation on which software can be built.
Software architecture is the structure of a program or computing system that includes the software components, the externally visible properties of those components, and the relationships between them. The term also refers to the documentation of software architecture. Documenting the software architecture facilitates communication between stakeholders, allows decisions made early in the design process about high-level system design, and allows the components of that design and patterns to be reused in other projects.
A number of architectural decisions and tradeoffs affect the quality, performance, maintainability, and overall success of the system. Failure to consider common problems and long-term consequences can put your system at risk.
There are many high-level architectural schemes and principles commonly used in modern systems. These are often referred to as architectural styles. The architecture of a software system is rarely limited to a single architectural style. Instead, a combination of styles often makes up a complete system.
The software architecture design process consists of designing the structure of all of its components that are functionally related to the task at hand, including the interfaces between them and the requirements for them.
Software architecture in the traditional sense includes the definition of all program modules, their hierarchy, and the interfaces between them and the data.
If an individual program is being developed, the input to this process will be detailed external specifications.
If a software product system is developed, the input data for this process will be detailed external specifications and the functional architecture of the system.
The traditional method of dealing with complexity, the “Divide and Conquer” principle, is often referred to as “Modularization”.
During the development of software architecture, its modular-hierarchical construction is performed.
A module is a closed program that can be called from any other module in the program and can be separately compiled.
The tendency to create modular programs is explained by the following factors:
- Program modules tend to solve a small functional problem and use little data as input and output. The internal variables of a module are not related to the internal variables of other modules. Therefore, individual modules can be created and debugged independently by different developers;
- Modular programs are easy to read, maintain and modify. Fixing an individual module causes minimal changes in other modules related to it by control and information;
- Modular programs have higher reliability because in their development it is possible to distribute the work on the creation of modules of different complexity and importance among programmers of different qualifications;
- It is possible to create libraries of the most used subprograms which can then be used as components in the development of other applications;
- The procedure of loading the whole program into RAM is simplified by the overlay method;
- There are many natural control points to monitor the progress of the project in terms of control and information.
A hierarchy is a property of an ordered set of components, between which a priority relationship is established. Components between which there is no preference form one hierarchical level.
The minimum components from which modules are constructed are the operators of the programming language. The variety of operators is comparatively small (50 – 100 types), and each operator is implemented by an algorithm based on an average of 1 – 10 machine instructions of a computer. The functional complexity of operators increases as the programming language level increases.
The lower hierarchical level of software product architecture corresponds to software and information modules, which are highly independent.
Program modules solve a small functional problem and are implemented by 10 – 100 operators of high-level programming language or 100 – 1000 assembler operators. As a result the module program has 100 – 1000 machine instructions. Each module can use about a dozen types of variables as input. The amount of output data is somewhat less. If the solution of a small functional task requires 500 operators or more, it is reasonable to decompose the task into several simpler ones, each of which will require a module realized by 50 – 500 operators.
- Modules (10 – 100 pcs.) are combined into groups of programs of a certain functional purpose with an autonomous target task.
- Several (5 – 20) groups of programs form a complex of programs. In especially complex cases it is possible to create a system of programs from several interacting complexes.
Functional groups of programs and complexes of programs are formed on the basis of dozens of modules and solve complex autonomous functional tasks. Approximately 10 thousand commands are used for their implementation in the computer. Accordingly, the number of variable types used and the variety of output data increase. The number of variable types processed by a module and localized within one or several modules grows much faster.
As a result, all sets of programs are combined into one big software.
Large software is created to solve particularly complex control and information processing or computational problems in science and technology. Several or dozens of software complexes are combined into a large software to solve a common target problem.
The size of large software means is counted in hundreds of modules, and tens and hundreds of thousands of machine instructions. There are software tools containing up to two to three dozens of structural hierarchical levels built from modules.
Software architecture as a hierarchical system has a number of properties, the most important of which are:
- Vertical co-subordination, which consists in a sequential ordering of the interacting components that make up a given set of programs;
- Components of one level provide the implementation of the functions of the components of the next level;
- Each level of the hierarchy is implemented through the functions of the components of lower levels;
- Each component knows about the components of lower levels and knows nothing about the components of higher levels;
- Right of intervention and priority influence on components of any levels by components of higher hierarchical levels;
- Interdependence of actions of components of upper levels on reactions to influences and on the functioning of components of lower levels, information about which is transmitted to upper levels.
As a result, two flows of interactions between components of different levels are formed in the hierarchical structures of program complexes:
- Top-down – coordinating and controlling influences of the upper levels of the hierarchy on the lower ones.
- Bottom-up – the transmission of information about the state and implementation of the prescribed functions by the components of the lower levels of the hierarchy to the upper level.
Interaction of system components involves selecting a way to coordinate and implement coordinating algorithms with the development of appropriate impacts on them.
Coordinated components have some autonomy of behavior and preparation of local decisions. The degree of autonomy of components and the intensity of coordinating influences is set by a compromise in the allocation of hierarchical levels.
It is advisable to limit the interaction of components within one level of the hierarchy as much as possible, which simplifies the overall coordination of components and conduct it only vertically.
The components of the lower levels of the hierarchy influence the higher levels directly, supplying information about their state and the results of functioning, as well as indirectly, preparing possible decisions for their selection at higher levels.
Information about the results of the functioning of the upper levels of the hierarchy can be taken into account by the components of the lower levels to improve their own decisions and for indirect coordination. Thus, the lower levels of the hierarchy are the main components that process the information and prepare the data for release outside the software environment.
Usually, only the components of the highest and the lowest levels of the hierarchy can be inferred from the problem statement: the highest level is the required development system, and the lowest level is the available resources: hardware, operating system, development tools, available libraries, etc. The intermediate levels of the hierarchy are defined by the developers of the system. In order to transfer a software system with a tiered architecture to another platform, it is sufficient to redo only the components of the lowest level of the hierarchy.
There are two types of tiered architectures: closed and open.
In a closed architecture, each level of the hierarchy is built on the basis of the level immediately following it. This reduces dependencies between levels and simplifies changes to the system.
In an open architecture, each hierarchy level is built on the basis of all the levels that follow it. This reduces the need to redefine an operation at each level and results in a more efficient and compact code. However, it does not satisfy the principle of information hiding, because changes in any subsystem may require corresponding changes in higher-level subsystems.
What is software design?
Software design is the process of conceptualizing software requirements into software implementations. It is the initial step in the software development life cycle (SDLC) – shifting the focus from the problem to the solution.
In software conceptualization, the design process establishes a plan that takes user requirements as tasks and works to find optimal solutions. The plan must define the optimal design to implement the intended solution.
Software design includes all of the activities that contribute to the transition from requirements specification to implementation. The major artifacts of the software design process include:
A software requirements specification. This document describes the expected behavior of the system in the form of functional and non-functional requirements. These requirements should be clear, feasible, measurable, and traceable to business needs. The requirements should also define how the software should interact with people, hardware, and other systems.
High-level design. High-level design breaks down the architectural design of a system into a less abstract view of subsystems and modules and maps their interactions with each other. This high-level design approach focuses on how the system, along with all of its components, is implemented as modules. It recognizes the modular structure of each subsystem and their interaction with each other.
Detailed Design. Detailed design involves the implementation of what is seen as the system and its subsystems in a high-level design. This activity is more detailed in relation to the modules and their implementation. It defines the logical structure of each module and their interfaces to interact with other modules.
What is the relationship between software architecture and design?
Software architecture reveals the structure of the system while hiding implementation details. Architecture also focuses on how elements and components of the system interact with each other. Software design delves into the details of system implementation. Design tasks include the selection of data structures and algorithms or implementation details of individual components.
Architecture and design issues often overlap. Rather than using hard and fast rules to distinguish between architecture and design, it makes sense to combine them. In some cases, the solutions are clearly more architectural in nature. In other cases, the solutions focus heavily on design and how it helps to realize that architecture.
An important detail to note is that architecture is design, but not all design is architectural. In practice, it is the architect who draws the line between program architecture (architectural design) and detailed design (non-architectural design). There are no rules or guidelines that fit all cases – in general, attempts have been made to formalize this distinction.
Current trends in software architecture assume that the design evolves over time and that the software architect cannot know everything in advance to fully architect the system. The design usually evolves during the implementation phases of the system. The software architect is constantly examining and testing the design for real-world requirements.
What is software architecture?
The software architecture of a system depicts its organization or structure and gives an idea of how it behaves. A system is a collection of components that perform a selected function or set of functions. In other words, software architecture provides a solid foundation on which software is often built.
A number of architectural decisions and tradeoffs affect the quality, performance, maintainability, and overall success of the system. Failure to think about common problems and long-term consequences can put your system at risk.
There are many high-level architectural schemes and principles commonly used in modern systems. They are often referred to as architectural styles. Software architecture is never limited to one style of architecture . Instead, a mixture of designs often structures the entire system.
What is software design?
Software design is the process of conceptualizing software requirements into a software implementation. It is often the initial step within the software development life cycle (SDLC)-shifting attention from matter to response.
In software conceptualization, the planning process creates an idea that takes user requirements as challenges and works to find optimal solutions. The plan should define the simplest possible design for implementing the intended solution.
Software design includes all the activities that help in the process of moving from requirements specification to implementation. The major artifacts of the software design process include:
Software Requirements Specification. This document describes the expected behavior of the system within a kind of functional and non-functional requirements. These requirements should be clear, feasible, measurable, and traceable to business needs. The requirements should also define how the software should interact with people, hardware, and other systems.
High-level design
The high-level design breaks down the architectural design of a system into a less abstract view of subsystems and modules and maps their interactions with each other. This high-level design approach focuses on how the system, along with all of its components, is implemented within a type of module. It recognizes the modular structure of each subsystem and their interaction with each other.
Detailed Design. Detailed design involves the implementation of what is seen as a system and its subsystems during high-level design. This activity is more detailed with respect to modules and their implementation. It defines the logical structure of each module and its interfaces to interact with other modules.
What is the relationship between software architecture and design?
Software architecture reveals the structure of the system while hiding implementation details. Architecture also focuses on how the weather and components within the system interact with each other. Software design delves into the details of system implementation. Design problems include the choice of knowledge structures and algorithms, or implementation details of individual components.
Architecture and style often overlap. Rather than using hard and fast rules to distinguish between architecture and style, it is wise to mix the two. In some cases, solutions are clearly more architectural in nature. In other cases, the solutions are heavily oriented toward design and how it helps to understand that architecture.
An important detail to note is that architecture is design, but not all design is architectural. In practice, the architect is the one who paves the way between program architecture (architectural design) and detailed design (non-architectural design). There are no rules or guidelines that fit all cases – in general, there are attempts to formalize perfection.
Current trends in software architecture suggest that planning evolves over time, where the software architect cannot know everything in advance to fully architect the system. The software architect is constantly learning and reviewing planning for compliance with global requirements.
Organizations that fail to integrate architecture and style reviews into their development process are often surprised to find that their software suffers from system failures both at the planning level and during implementation. In many cases, defects identified by penetration testing are easier to identify using other methods – earlier in the lifecycle. Testers who use the results of architectural analysis to guide their work often reap greater rewards.
