How software architecture influences source code efficiency?
Software development is a complex process which includes system design. System design is about the individual modules and components of the software,aggregated to deploy a software architecture. Whereas software design is one of the juvenile phases of the software development life cycle. The components are analysed and built according to stakeholder and consumer requirements. It is important to design for scalability and performance of code — code efficiency. Some algorithms are more heavy and resource-intensive while accomplishing the same task than another algorithms. Practicing creating a low file size and low resource algorithm results in an efficient program.
When determining the software architecture, it is the system that comes in the first place in the design. From system design, software and hardware design is determined. Software is becoming more important in design and is closely connected to
system design, while the computer hardware can undergo more amendments, whilst the software architecture has not changed. There is increased focus on software to support engineering, programming , commissioning and operation.
Software Architecture (SA) and Source Code (SC) are two intertwined artefacts that represent the interdependent design decisions made at different levels of abstractions — High-Level (HL) and Low-Level (LL). An understanding of the relationship between SA and SC is expected to bridge the gap between SA and SC for supporting maintenance and evolution of software systems.
Software Architecture (SA) represents the high-level structure of a software system. It characterizes the key design decisions taken to achieve the functional and non-functional requirements of a system. The representation of SA is described from different perspectives by using architectural styles, views, patterns, tactics and decisions. Due to the difference in the abstraction levels (i.e., HL and LL), there exists a gap between SA and Source Code (SC). This gap leads to a problematic situation exacerbated by a general lack of efforts allocated to keep the SA documentation updated. Even if SA is well documented or updated, it is still a challenge about how to embody SA in implementation and update SA and SC synchronously to ensure their consistency during software evolution. Several different approaches already address the problem of narrowing the gap to align and evolve SA with SC over time.
During the software development life cycle, architectural level elements, e.g., modules, components, decisions, tactics and patterns are transformed to low-level design elements to be implemented. SA elements of a system can also be reconstructed by reengineering the SC elements of a system. When an SA is modified to satisfy new requirements, its corresponding SC also gets changed when a software system evolves to avoid architecture erosion. When anomalies in architecturally relevant SC are detected and corrected, the corresponding SA problems should also be fixed to maintain a system. It is important to analyze and leverage the relationship between SA and SC to effectively improve the maintenance and evolution of a software system.
Understanding of the Relationships between SA and SC
Transformability :
Transformability means that SA can be transformed into SC. The architecture defines the structure and organization of the code. Architecture defines the components, their structural organization, their interfaces, and the interactions required to perform the required overall system functions. It also defines the sequences of interactions required to execute overall system functions.
Code is generated from or implements architecture specifications, architecture diagrams, or reference architecture. Because any architecture needs implementation. Which is done by code. Patterns, practices and project-specific decisions instruct how architecture ought to be implemented in code.
Arch and code are on opposite sides of the abstract/concrete spectrum. Architecture views reflecting the code aspect such as module views, code views, etc. directly represent the system’s code structure.
Traceability :
Traceability denotes that software architecture can be traced to the source code of a system and vice versa. Dynamic traceability in practice, which can help them figure out the actual operation and execution of systems, such as how system services and processes interact at runtime. Static traceability between structure and source code, because their goals are to check whether the implementation realizes the functionalities of modules defined in architecture without considering how the modules interact and execute at runtime.
Consistency :
Refers to the relationship between SA and SC that the intended architecture should be consistent with the implemented system. Code adheres/diverges in various ways from architecture. Either code follows architecture or architecture follows code. In agile, the evolutionary architecture follows code. Architecture and code should be changed synchronously due to, e.g., new requirements.
Interplay :
Interplay means that architecture quality influences code quality, and vice versa. Software architecture defines programming languages, layers, components, middleware etc., which heavily influence the relevant code patterns. This feature refers to the situation where a poorly conceived and defined architecture can cause code flaws, defects, or anomalies, whereas the subfeature Architecture leads or guides code emphasizes that architecture decisions or patterns can determine the decisions of code structure and patterns.
Recovery :
Architecture recovery is a process to extract architecture information from entities at the code level. The elements in architecture design (e.g., tactics, components, and interfaces) can be reflected in code. The code reflects software architecture components and structure definitions. Architecture can be identified from code artefacts (e.g., code structure or elements). Design patterns are one of them, the structure of the code (say the folder structure, and the file naming policies) will show them too (say, if you are using MVC patterns, you’ll see the models, views and controllers in different folders, quite easy to find).
Interrelationships between the SA and SC relationships
The five features of relationships (Transformability, Traceability, Consistency, Interplay, and Recovery) between SA and SC are reported in the literature. A few dedicated approaches and tools in the literature are employed to identify, analyze, and use specific relationships, such as consistency. It is critical to identify, analyze, and use the relationships in order to improve system qualities, especially maintainability and reliability. The cost and effort are the major barriers that hinder identifying, analyzing, and using the relationship. Therefore, the ignorance of the relationship between SA and SC could bring short-term gains for fast development and delivery, but more effort is required to maintain systems in the long run. The benefit of maintainability can be improved by analyzing and using the relationships between SA and SC. Currently, no effective approaches have been available to quantify the benefits and costs. Therefore, the unclear cost-benefit quantification and time pressure for fast delivery hinder the consideration of identifying, analyzing, and using the relationships between SA and SC.
