Architecture
The ecosystem of Black Fennec can be divided into four components and the means by which they interact. From the architectural standpoint, Black Fennec provides the interfaces between the components and also some services to solve common problems. These interfaces and services are largely independent and allow for the high degree of cohesion and low coupling which is required to manage the complexity in this project. The following graph gives a good overview. It does not strive to be a perfect reflection of the code and its complexity but instead should serve as an entry point for new developers.
Black Fennec is a desktop application without backend integration. All code runs within a single tire. However, the project entails a fair amount of engineering challenges.
- User Data
User data is the information the user is viewing/editing with Black Fennec. As such it is not part of the source code. When it’s loaded from a file into Black Fennec it is deserialized into the object model. The resulting structure will be interpreted through the type system, visualized partially by extension provided views, and displayed by a presenter.
- Types
Types can be added by extensions. The richer the ecosystem and the more available types the better the interpretation. At least that’s the theory.
- Actions
Actions are extension defined procedures which the user can trigger. They can define preconditions in the form of a type and are able to run code and manipulate the structure.
- Resource Types
A Resource Type enables access to a specific type of resource. It is registered to a protocol and provides the implementation to read and write to it. It is used by the document system to abstract the access to the resource.
- Mime Types
A Mime Type is responsible for parsing the contents of a Resource and is identified by a string. In combination it allows the document system to abstract the access to the resource and mitigates the combinatorial explosion of possible file formats and protocols.
- Views
Visualisations are the visual representation of the Structure. They play a big role in what the user sees and interacts with. Internally, MVVM is used to decouple view and logic. Note that this - from the point of view of Black Fennec - is an implementation detail and neither enforced nor required by extensions.
- Presenters
The presentation is the responsibility of the presenter. It displays the interpreted structure which are requested from the interpretation service. The presenter also observes the navigation service for navigation request and is responsible for acting on them.
Black Fennec
When we take a closer look at the interfaces and services used by the “external” components, we can identify some concepts that can be found throughout this documentation. These are the high-level concepts which are important to understand the bigger picture. Each component is conceptually largely independent of the others. This allows us to tune their view of the system to their needs. Think of the facade pattern but towards the core and not to hide legacy code and thus minimizes complexity whereby development efficiency is maximized.
- Structure
The structure is the parsed user data. It is the foundation upon which the interpretation is built and the fabric in which navigation is performed. It is implemented in our object model and can be further preprocessed by layers such as the overlay. The layers allow specialized usage of the structure without manipulating the underlying data (underlay).
- Type System
The type system is represented as a collection of known types that can be used to interpret the structure. They are stored in a registry. This allows runtime loading and unloading of the available types and is an important enabler of the extension infrastructure. The interpretation service does most of the heavy lifting as it decides which types from the type system ought to be used to visualize a given structure. The service can be configured on a ‘per request’ basis with a specification, giving fine-tuned control to the user of the service.
- Action System
The action system is responsible to execute actions. It is the interface between the user and the action and is responsible to check the preconditions and to execute the action. It is also responsible to provide the user with a list of available actions.
- Document System
The document system is responsible to import a structure from sources such as files. With that it is responsible to abstract the access protocol and mime type, both of which can be loaded at runtime by extensions.
- Presentation System
The presentation system manages the available views and presenters. It hides all the complexity and ought to provide an intuitive interface for all possible interactions with the system.
Further information and more detailed descriptions of the mentioned components can be found in the domain model. If you are interested in the documentation of the source code follow this link