Introduction
The purpose of software architecture is to solve issues and design problems beyond the basic algorithms and data structures used in software instead of focusing on structural phenomena. These include gross organization and global control structure, communication protocols, data access, synchronization issues, and functionality. Other critical issues attributed to software architecture include the assignment of functionality as well as distribution, composition, scaling, and performance of design elements. Lastly, software architecture seeks to provide alternative design options available for selection. The purpose of this paper is to demonstrate the application of common architectural styles in three case studies involving KWIC (Key Words in Context), instrumentation software, and compilers.
Similarities and Challenges
All three case studies are different one from another in both the scope of the addressed problem and the type of software architecture implemented. However, there is an overarching similarity that unites all situations as one of the core challenges faced in each situation involves implementing a system capable of withstanding design changes and managing various heterogeneous types of data. At the same time, each of the cases also presents a set of issues associated with a specific architectural design.
The challenge with KWIC revolves around circularly shifted sentences as the program does not identify the first word in a sentence, instead using an arbitrary word and continuing to list all words until reaching the end of the sentence, and then wrapping around the start (Garlan and Shaw, 1, p. 16).
The second case study features a challenge associated with data heterogeneity, as the oscilloscopes utilized by Tektronix were created by different product divisions and follow their own software organization, conventions, and development tools (Garlan and Shaw, 1, p. 22). Another challenge involves poor capabilities at user-specific configuration as a result of various different modes within a larger software.
The third case study features an issue related to the oversimplification and misrepresentation of the compiler with sequential data flow (Garlan and Shaw, 25). While the traditional compiler model demonstrates it as a pipeline process, the reality of software functionality is closer to a tree/symbol table structure similar to that used in a Blackboard. As a result of this simplification, the focus shifts from central shared representation to the sequence of passes.
Key Word in Context Architectural Solutions
Architectural solutions offered in the first case study include Abstract Data Type (ADT) software design, a flow chart model, a pipe-and-filter model, and an implicit invocation structure (Garlan and Shaw, 1, p. 18). Each of these solutions has its own set of advantages and disadvantages. The flow chart model, also described as main program subroutine with shared data, allows for computations to occupy the same storage space.
It also isolates different modules from one another, making the model an intuitive choice. However, the system requires an almost complete restructuration whenever a change is needed. The reuse potential of the system after decomposition is low.
The second solution involves an ADT software design, which has several advantages over the flow-chart: the system is more outfitted towards changing individual modules and has a greater reuse potential (Garlan and Shaw, 1, p. 19). However, these gains also come with a distinct set of weaknesses to the system. Namely, while the system does accommodate changes within a specific framework, it does not offer much support to structural enhancements since the modification or addition of existing modules compromises the simplicity and integrity of the design.
The implicit invocation option uses shared data, similar to the approach taken in the first solution (Garlan and Shaw, 1, p. 20). However, because of data access abstraction and implicit computation, the system is better-suited to alterations, upgrades, and data reuse. The interaction is based on an active data model. At the same time, its particular flaws include inefficient use of decomposition space and difficulty of order processing control.
The fourth solution involves resolving the KWIC problem utilizing a pipes-and-filters software architecture. This system uses four filters in order to separate the data processes, which are as follows: input, shift, alphabetize, and output (Garlan and Shaw, 1, p. 23). This system has an intuitive flow of processing, supports reuse, and is simple to modify. However, it is virtually impossible to upgrade to an interactive system and is inefficient in the usage of storage space.
As it is possible to see, each of the four choices comes with a distinct set of strengths and weaknesses. There is no definite advantages or disadvantages to either of the proposed solutions, as the choice should be made based on the specifics of a particular system. A pipeline system, for example, may present itself as efficient in a situation when storage space use and interactivity are not a primary concern, whereas ADT might be preferable in a situation when major changes to the system are not planned in any foreseeable future (Richards, 2, p. 45).
Domain-Specific Versus Non-Specific Systems
Domain-specific software architecture (DSSA) is a type of software architecture focused on a specific domain with a purpose to constrain space and facilitate focused development in the scope of a singular problem (Richards, 2, p. 63). This type of architecture is useful when solving a specific issue or having a very narrow scope of design. A contrast to DSSA is a heterogeneous architecture design, which may use two or more domains in order to achieve specific objectives.
This is done by either allowing an architectural component to be shared between different designs, by establishing a joint active database, or by elaborating a level of architectural description in a completely different style. Developing domain-specific software significantly simplifies and narrows the planning and testing phases during the software development lifecycle, as the scope of specific domains, as well as their weaknesses, are already well-known (Richards, 2, p. 86).
Related Uses to Compiler Architecture
The compiler code structure is versatile and can be used in an assortment of applications not directly involved with compiling or intercepting code. One of such examples involves interpreter types of programs, which bear some resemblance to the revisited canonical compiler model (Shahid, Keung, and Khan, 3, p. 227). It was chosen because the information of the computation is located centrally, similar to the structure presented in the third case.
It allows independent computations to interact only through shared data. The difference lies in the purpose of the program, however, as interpreter systems are used for recognition and interpretation rather than interception and compilation of information.
Conclusion
Different architectural systems allow delivering a product in line with various requirements presented in the three cases explored throughout this paper. The first case featured four solutions with their specific strengths and weaknesses, in line with different specifications that might have risen. The modified pipe and filter model from the second case managed to answer the issues of setting parameters and modifying them in accordance to specified needs by using a modified pipe and filter model, with a specific filter associated with the control interface. The tree-symbol table structure was considered optimal for data compilers from the third case, as it accommodated various tools that operated on the internal representation rather than the textual form of a program, such as analysis and syntax-directed editors.
Sources
- David Garlan and Mary Shaw. 1994. An Introduction to Software Architecture. pp. 16-28. Web.
- Mark Richards. 2015. Software Architecture Patterns. pp. 45-86. Book.
- Shahid Hussain, Jacky Keung, and Arif Ali Khan. 2017. Software Design Patterns Classification and Selection Using Text Categorization Approach. pp. 225-244. Applied Soft Computing, vol. 58.