Revision Control

In software development, source code is the statements that a developer enters into a computer that defines the instructions or declarations that a program's behaviour is based on. Source code allows the developer to communicate with the computer using a programming language. The term "source code" is also often abbreviated to just "source" in developer conversations. Just as software programs have multiple revisions over their lifetime, so do the individual source code files as developers make changes over time.

It is good development practice to store the source code files in a revision control system. This is a database from which all versions of a source file can be extracted at will. It is important to use a revision control system in any non-trivial software development scenario to be able to practically manage the software development process. We currently use the Visual Source Safe revision control system from Microsoft. It is actually quite an old source control package that has been much maligned. Regardless, for the size of our development team it has served us well. We will likely change to an open source revision control system in the future but at the time of writing Visual Source Safe is the revision control system we use.

The following images provide an example of what a source file looks like to a developer within the development environment and an example of the history of changes made to a source file and stored in the revision control system. These source files are compiled to generate the programs used by our clients. Every change to a program's source code is logged with a date/time and the developer that made the change. Each revision is identified by a revision number. This revision control information helps us as developers manage the software development process over the lifetime of the software products we maintain.

Torq Framework

The Torq Framework is a set of .NET libraries and a base architecture that is designed to be re-used across a number of business software scenarios. Torq Software uses the framework as the basis for building new software products without having to repeat software development actions across multiple projects. It is currently being used as the basis for products in the MacroView Industrial Automation and the Iris Debt Collection software product sets. The bottom line is that the framework helps us build better software faster for you.

Layered Architecture

The underlying Torq Framework architecture is based on five separate software layers. Each layer has a standard set of libraries that are used for building applications. Each layer only depends on the layers below it ensuring a consistent program structure.

Applications built using the Torq Framework can get a running jump on development by leveraging off of the framework at various levels within the application. The typical Application will need specific implementations of the higher level layers only e.g. the business domain layer, presentation layer and user interface layer.

Foundation Layer

The Foundation layer provides the base architecture for the framework and applications built with the framework. The functionality areas include:

• Additional meta-data concepts oriented towards being able to model business concepts more easily than with the standard .NET framework functionality.
  
• An object source abstraction which allows difference database and data persistence mechanisms to be plugged in.
  
• An Authorization system for identifying which users have access to which areas in a business domain.
  
• Abstractions of general Windows and .NET concepts that allow limit the coupling of application code to a particular implementation. This facilitates flexibility and automated testing.
  
• Extensions to the core .NET functionality that makes it easier to develop asynchronous programs.
  
• A variety of convenience classes to help in day to day programming.
  

Mapping Layer

Business Domain Layer

The Torq Framework includes a set of business domain classes that are common across multiple application domains. These include but are not limited to code for the following abstractions:

 

Party Person Organization	Place Region	Thing Vehicle Delivery	Time
Task	Document Attachment	Account Transactions	User Administrator
Phone	Address	Fax	Email
License	Passport	Characteristics

The business domain layer uses the Role pattern to allow the core domain objects to be able to be extended with additional functionality without modifying the core object’s code. For example, a person can take on multiple roles within a system. Example of roles people can play in a system include User, Administrator, Manager, Agent, Coordinator and other business domain specific roles. The Role pattern allows an Application to easily extend the Torq Framework for its needs without modifying the framework code.

The re-use of the business domain layer also extends to the presentation of the business objects. For example, the Torq Framework has a variety of graphical objects that present business objects to users and can be used to update the business objects.

An example of such a graphic object is the PartiesControl object. This object displays a list of parties (People and/or Organizations). It automatically adjusts its display to the type of people and organizations it is supplied. The tree view on the left adjusts based on the relationships between people and the organizations they are associated with. The window area on the right shows the selected party, all of their contact details, ID information and the roles they play in the current application.

All of this is done automatically and with knowledge of the extensions made by an Application beyond that provided by the Torq Framework. The graphical object shown above is based on Windows Forms graphics. There’s also a separate Web based user interface PartiesControl object in the framework:

The architecture of the business domain layer and its extensible structure allows us to leverage the Torq Framework in new Projects and Products without having to modify the existing framework code. This extensibility applies to the presentation and user interface layers as well.

Presentation Layer

The Presentation layer in the Torq Framework is a means of modeling user interface concepts without actually being tied to a particular user interface implementation. The classes in this layer can also be called a “view model” or a model of a view. It allows presentation oriented concepts to be implemented once and then re-used across products with different user interface front ends.

An example is the implementation of a Find dialog which needs to run in both a Windows application and a Web application. Rather than implementing the core Find logic multiple times, it is implemented once in the presentation layer with no specific graphic output – only information output. The presentation layer approach reduces the duplication of effort and encourages the re-use of software code. The underlying find dialog code is the same for both of the following user interface implementations (Windows Forms and Web).

User Interface Layer

The user interface is where the rubber hits the road as far as the users of a software system are concerned. It’s what people see the most and what they associate with a software system or product. The Torq Framework is structured so that the choice of user interface is a separate decision from the core implementation.

This approach allows a software application to be built with one user interface technology, but then be extended to use another without a major architectural change. Torq applications use a variety of .NET user interface technologies and the framework will evolve as the technology landscape evolves.

Windows Forms

A Windows Forms based user interface is a typical industry standard Microsoft Windows graphical application. The Windows Forms environment has the advantage of having a large number of third party components to leverage off of and produce highly functionality applications quickly.

Visual Web GUI

The Visual Web GUI (VWG) user interface framework is an innovative approach to developing Web Applications. Torq Software is excited about the prospects of this user interface framework as it provides a means for developing business web applications quickly and efficiently. It allows a web application to be developed in a similar way a Windows application is developed, but with all of the benefits of a Web deployment model. More information on the Visual Web GUI approach can be found at www.gizmox.com. The Torq Framework extends the VWG with standard business model user interfaces and integration with our Framework.

Reports

Reports are another means of providing a user interface into a software system. The Torq Framework supports integration with the Active Reports reporting package and includes a Word template based reporting system as an option. Other reporting destinations can easily be added as the underlying architecture has separated out the business model from the form of the user interface.

WPF and Silverlight

The user interface framework of choice for Microsoft .NET applications for the fore-seeable future is the Windows Presentation Framework or WPF. It is a highly advanced framework for developing user interfaces with strengths in the area of graphics animations and transitions. The Silverlight framework is a subset of WPF that can be run in a Web Browser.

Torq Software has invested heavily in WPF and Silverlight functionality going forward. The Torq Framework architecture is well suited to leveraging the strengths of both WPF and Silverlight.

Scrum

A process we follow internally is the use of Scrum for structuring the management of software development projects. Some of the practices that define what Scrum is include time-boxed development sprints, a product backlog defining work to be done on a product, a sprint backlog defining the work to be done in the current sprint, a small team, a stand up meeting every day, the product owner role and the scrum master role.

As with any of the processes or practices we use internally, we do adjust the approach to our company needs. The name we use for sprints is an iteration which we time box at being a fortnight long. Only the scrum master stands up at our daily scrum meetings. The Product Owner role is taken by a representative of our business partner clients. Our product and sprint backlogs are stored in an OnTime database from Axosoft. The sprint backlog is also displayed on a white board in an office hallway that all developers will walk past at various points during the day.

The great people at Axosoft have put together a great video providing an introduction to Scrum. Check it out on their site.

Insight Mercantile