Wyvern Architecture Language

Software architecture refers to the “set of structures needed to reason about the system which comprises software elements, relations among them, and properties of both.”¹ There is a strong focus on structure and design to achieve a set of qualities—just as the term “architecture” implies. The concept of building architecture might involve a blueprint layout representation comprising construction elements, design decisions, and structural specifications. This outline can serve as a design tool to the architect, a construction guide for the contractor, a starting reference for future renovators, or even a map for inhabitants and visitors. In nature and utility software architecture is very similar. The architecture of a program is a high-level abstraction of the fundamental structural elements within a system representing their organizational relation and relative function. This architecture is integral to the coherence of a project.

To promote the structural lucidity of software, the architecture often arranges related features relevant to separate stakeholders into specifications that deal with different aspects of the software. These specifications are called views. The most common architectural views of a program involve a module view of its units of functionality, a connector-and-component (CnC) view of its runtime entities, and a deployment view of program configurations and component allocations. The use of separate views might allow the software architect to ignore runtime configuration details or a developer to focus on implementation of a specific component. This separation of concerns generally reduces design complexity. For instance, if the programmer wanted to change the implementation of a connector from a Java Database Connectivity connector to a NoSQL connector, the modification would be contained within the CnC view and its application greatly simplified for the programmer.

As a programming language, Wyvern prioritizes robust program security and architectural integrity. Elements of closely related data and functionality are organized into implementation units called modules. Modules are innately stateless and without access to any stateful thing unless the capability is explicitly given to the module. This way the procedures within a module have effects that are controlled and well-defined, so architectural integrity on the modular level is preserved. Preservation of designated architecture on a larger scale can be realized with an architecture description language, or ADL, to specify the architecture of a system with well-defined structures and parameters. However, even with clear architectural descriptions, it can be difficult to enforce the intended design on the software itself. Unlike that of buildings, it’s in the nature of software to evolve rapidly over time. No homeowner experiments with interior design by digging into the building foundation and switching out kitchen tiling every few days, but it’s not uncommon for a programmer to test different implementations by swapping out modular pieces of code. It becomes easy for the programmer to unintentionally stray from the architecture since they are given free rein to arbitrarily call libraries and rephrase code. Moreover, as new programmers who aren’t accustomed to the architecture are introduced to the project, edits and additions to the source code introduced might seem innocuous but go against the original design principle. So, while the intended software architecture might document a tidy and secure system, the actual source code could be filled with extraneous dependencies, unsafe data-sharing, or various other security defects.

In light of such architectural drift and erosion, the original strategy of the architect becomes moot, possibly introducing a number of vulnerabilities. In the case of a three-tier server-client system, the architecture is meant to guarantee that there exists server-client and server-database communication but no client-database communication. However, the programmer can create a communication path between the client and database, introducing a dependency violating the architecture and contributing to erosion. This dependency may become a security liability or force a modification in one component if the other is changed. If more and more alterations like these are made to the source code, the architectural violations accumulate and the nature of the program drifts even further from the original three-tier architecture. One possible way an ADL can preserve the integrity of its architecture is to somehow project the architecture onto software and maintain design consistency. The Wyvern architecture language is a formal ADL that will support multiple view descriptions of a program. Given a certain architecture, the Wyvern ADL places limitations on the changes and implementations the programmer can make so no specifications are violated. The programmer provides the module definitions and component implementations referenced in the architecture. This way not only does the program maintain its architectural integrity to ensure safe internal communication and data access, large, complex software systems can be divided into more digestible, coherent elements with well-defined functionality and clean dependencies. Alterations to the code in one distinct functional unit can be made without having to reason about collateral effects rippling indefinitely to other parts of the project.

Software architecture provides programmers with the tools to reason about large, distributed systems and to create coherent designs consistent with project demands and limitations. A common problem that arises is the rift between design and implementation. The Wyvern architecture language addresses the primary concerns of preserving communication integrity and low design complexity between architecture and application. It does so by accepting CnC and deployment view descriptions as indicated in Wyvern ADL, and then creating the as-intended program scaffolding that incorporates the capability-safe implementations provided by the programmer. This protects against the possible introduction of code that might violate the architectural design principle in place. The incorporation of multiple architectural views ensures as-intended communication integrity and structural organization, effectively bridging the disparity between software architecture and software.

---

¹ Paul Clements et al., Documenting Software Architectures: Views and Beyond, 2nd ed. (Addison-Wesley Professional).