Software architecture is a central part of software engineering and plays a crucial role in the success of software applications, both in terms of business and engineering aspects. Deciding on a specific software architecture requires careful analysis of the software application’s requirements and is not trivial.
Architectural patterns are general design structures that have been used successfully in software architecture design. They provide rules and guidelines to describe high-level software components and the interrelation between them, and address commonly occurring issues in software architecture design, such as limitations in software performance, availability or minimization of business risk. Architectural patterns are similar to software design patterns but have a broader scope.
Selecting an architectural pattern is a challenging task for a software architect.
Software architecture design is typically made in the early stages of a software development life cycle and is very crucial for the quality, success and further management of the software. Selecting an architectural pattern is a challenging task for a software architect. It requires not only technical knowledge about these patterns, but also expertise in deciding which pattern is the most suitable architecture for a software system (considering its requirements).
While modern software development practices benefit from strong tool support offered by IDEs (features like build automation, debugging, refactoring, code search, continuous integration and continuous deployment), the need for a support system for architectural pattern selection is still not sufficiently met in practice. In particular, software engineers could greatly benefit from tool support that assists them in their architectural pattern decision process.
To address this issue we developed a framework for architectural pattern selection (APS) that can be integrated as a tool support feature in IDEs. Our framework currently supports the following six common architectural patterns:
- Layered architectural pattern
- Event-driven architectural pattern
- Microkernel architectural pattern
- Microservices architectural pattern
- Service-oriented architectural pattern
- Space-based architectural pattern
In order to provide tool support for the decision-making process of architectural pattern selection, certain information about the software design and requirements must be acquired. Our framework for architectural pattern selection uses four specific categories of high-level information about the application to be developed and the architecture for it. These categories are as follows:
- Application domain: The general domain of the software application such as web-based systems, distributed systems, cloud computing applications, mobile applications etc.
- Application properties: High-level properties of the software application such as specifications of application components or business constraints.
- Non-functional requirements: General operational specifications of the software application such as maintainability, performance, portability, reliability and security.
- Architectural features: High-level properties of the software architecture such as specifications of architecture component communication, component interoperability and data volume.
These categories are explored through a survey where at least one question per category can be asked to a software developer/architect. This survey is designed to collect both the background information about the application and the preferences in terms of the operational capabilities of the application as well as the desired features of the architecture.
A scoring system associates every survey item to each of the six supported architectural patterns, to provide an evaluation. These values indicate how strongly an architectural pattern is suitable to the given specification. This evaluation is based on a comprehensive state-of-the-art analysis of architectural patterns and their relation to application domains and architecture requirements. The scoring values are used to calculate the total value of each architectural pattern. The pattern with the highest total score indicates the most suitable pattern based on the data input. The top three highest ranking patterns and their ranking can be suggested for the user’s consideration.
The APS framework is implemented as a backend service that provides a REST API for the survey content and its evaluation. The API implementation is independent of the survey content and the specific scoring values used for the evaluation. The survey content is prepared and stored as a JSON object that can be retrieved and used to create and present it in an IDE. The scoring values used for the evaluation are also stored as a JSON object. Both of these JSON objects are configurable within the API if desired. This makes the backend API generic in terms of API functionality and it can be integrated in IDEs to offer tool support for architectural pattern selection.
The APS framework and its backend API are currently being integrated within the SmartCLIDE research project. Architectural pattern selection is supported in the SmartCLIDE IDE as part of the service creation process using the user frontend of the IDE. The service creation flow begins with the user starting to create a new service, which is followed by the selection of a Git system to be used together with corresponding credentials. After the user provides the details of the service to be created the next step is architectural pattern selection. This step provides assistance to the user if the user decides to choose an architectural pattern for their service. This assistance is optional and is provided via the APS wizard.
The APS wizard first provides a list of supported architectural patterns to the user to choose from. The user can choose one pattern from this list and proceed to the next step. In case the user does not know which architectural pattern to choose, they can further use the APS wizard to receive a list of suggestions which patterns would be most suitable for their service based on high-level information about their service that they can provide at this stage. If the user decides to skip the selection or the application of an architectural pattern, the user front end finishes the service creation.
The backend API will be extended with the implementation of the architectural pattern application that finalizes the service creation flow in the IDE. The APS framework will be evaluated in various industrial use cases of the SmartCLIDE project. Based on the use case results, the survey content and evaluation values can be improved and re-configured in the IDE if necessary. Further future work includes increasing the number of supported architectural patterns. Currently, all supported architectural patterns are individual patterns. It would be desirable to support combinations of individual patterns as well.
No responses yet