This article presents the system architecture and the underlying decisions that were taken to achieve the above requirements. The system requires a repository for sessions, a repository for Brainstorming items and a native Windows application for achieving the baseline of desired features. Thus, a distributed client – server architecture is considered, exemplified below.
Session repository architecture
The above schema represents the Session repository architecture. Its main purpose is to offer two main features:
- communication over network
- means for storing, retrieving and sharing the sessions
The server and the native application can be mixed together, but with limited sharing options. Because of this reason, we will use an already created system which not only that offers through its network module of API (Application Programming Interface) both means of storing and retrieving of the session data, but also allows advanced features of sharing the data in an already familiar interface.
Brainstorming items repository architecture
The architecture for the Brainstorming items repository is similar with the one for Session repository, but the most important feature it brings is the possibility to interface with other devices, not only with the tabletop.
Another reason for creating this secondary architecture is the fact that it easily enables an offline scenario, in which the repository server is not available because of the network availability issues. Nevertheless, the mobile devices can connect to this repository through creating a local wireless network without the need to be connected to the internet. Another advantage is that, because it’s small complexity, can (but it is not required to) be installed on the same tabletop. The offline scenario is not covered in this paper, but rather proposed as future work.
Prototype application architecture
The application conceptual architecture is straightforward, using the separation of layers into Data, Business and Presentation (using the Model-View-ViewModel pattern). This allows having a very modular, easily scalable and flexible application.
The Data layer is responsible with all network communication, hiding the details of this operation to the next layer. This permit isolating the communication in simple methods, returning objects complete with their attributes, instead of local parsing of the web retrieved result. It allows reuse of code, clean separation of concerns and very good testability. Because of different APIs which expose different methods, it consists in several sub modules for each type of system with it interacts with.
Business layer contains the session, a global state object which encapsulates all session related objects like Brainstorming items list, Twitter of Flickr item lists etc. Its main purpose is to provide collections of objects to the UI, separating this way the internal logic from the interface.
The Presentation layer’s purpose is to consume the data made available by the Business layer and present it to the user. This separation of concerns is very effective when more than one part of the User Interface needs the same collection of data, allowing easy update and synchronization between different UI areas.
After we took a look in the architecture let’s move first to the implementation of repositories and then to the Breiny’s implementation.
