Genus

Product

Our Genus Desktop client for Microsoft Windows is written in C# and .NET using Windows Presentation Foundation (WPF) and components from DevExpress and Aspose.

We are gradually moving some old code from Embarcadero Delphi to C# and .NET, but no by tedious porting of code line-by-line. Our strategy is to make new C# code modules and integrate these into our existing code by clearly defined XML interfaces over COM Interop. Our new programmers will not be using Delphi, but focus on making new C# modules.

We have made a Genus application model called Actio which we use internally at Genus AS for bug and project management.

This screen shows a Form displaying information about the bugs and tasks I as a programmer are working on right now. We use the word Issue for both bugs and tasks.

The screen exemplifies several concepts or mechanisms:

Active object: Clicking a row in the upper-left table controls the content of the details pane below and the Documents table to the right.
Flexible layout: Controls may be positioned freely, i.e. arranged in groups with positions decided dynamically by layout controls.
Document Preview: The integrated use of Windows Preview Handlers.

This screen is the same as the above, except that the user has selected the second tab in the upper right table, revealing more details, including a table of other issues submitted by the same person (as the issue currently selected in the upper left table).

This screen shows part of the setup of the two screens above.

The setup tool is called Genus Studio, and our modelers use Genus Studio to define and maintain their application models. The behavior and apperance of Actio is determined by the content of the application model, i.e. the model is the application.

Genus Studio also features Object Class Diagram, comparable with entity-relationship diagrams, showing the connections between entities.

Diagrams are used to model the object classes (entities), properties and codes in the application model. Diagrams are typically the first thing a modeler would use when defining a new application model for a customer case, by creating new draft object classes and sketching the connections between them, even discussing the drawings on screen with their customer.

This screen shows some of the underlying object classes and properties for the forms above. Note that Issues are stored in the object class Activity.

The core of our Desktop Client architecture is the Core Event Handler. The Core Event Handler receives requests for data reads and changes from the layer above, handles the requests and returns responses. The requests are truly requests, i.e. the Core Event Handler decides if data is readable or if changes are doable.

The Table controls the tabular presentation of data, and has very flexible layout customization features. The Form presents detailed views of data using a range of controls, such as text edits, number edits, labels etc, and has container controls such as groups and tab sheets. Analysis offers functionality to create multidimensional and aggregated reports. Reports may merge any of your data or Analysis to almost any document format. Various Search functionalities are provided, plus refining of search results.

Tasks are comparable with traditional wizards, where you can assemble multiple actions in order to perform complex operations, with a graphical user interface or not. With Rules you can make your application respond to events. The Navigation Pane provides centralized navigation and easy access to the other objects such as Tables, Analysis, Forms and Tasks.

The Meta-Object Model is interpreted by the Core Event Handler, in order to recognize your business objects, like Projects, Activities, Customers etc. The Meta-Object Model is read into a memory cache at Genus Desktop client start-up from a database using the layers below.

The Transaction Engine Object/Relational Mapper converts data between the object-oriented Meta-Object Model and the relational-oriented database representation. The Mapper is responsible for the security, for SQL generation and the object cache.

The Web Service Access layer is responsible for communicating with our Genus Server (not shown) over http(s).

Such architecture drawings can never be anything but imperfect and overall views of the real thing, namely our program code. But the architecture drawings give direction to our coding, and support the division of the code into clearly defined layers and class diagrams.