The Ottawa .NET Community is please to invite you to a luncheon presentation on "Test Driven Design (aRealWorldExample)". Test Driven Design is a powerful development paradigm and there's nothing like a simple "Real World Example" to help you wrap your head around it. The presentation is scheduled for Wednesday, November 18, 2009 at 12:00 noon. Bring your lunch and see how you can use Test Driven Design in your next project.

Test Driven Design (aRealWorldExample)

This session illustrates Test Driven Design in light of a real world scenario. The scenario involves a legacy class object that needs to be upgraded to meet a new user requirement. You will be walked through the process of creating the test cases that will be used to insure that the user requirement is fully met. You will then see how the solution is developed around these test cases. Note that LINQ functionality will be included in the solution and you will have the added benefit of seeing this technology in action. At the end of this session you will have a better understanding of how to integrate Test Driven Design (and LINQ) into your next project.

About Charles Wiebe

Charles Wiebe is the co-founder of TrackerRealm, a company that specializes in workflow design. He is a Microsoft .NET software architect/designer for Windows Forms and ASP.NET solutions. Charles' expertise lies in the Application Layer, working with Web Parts, and GUI development. He is currently responsible for the User Interface components used in COR, a Content Management System and Jetfire, a workflow domain specific language. Charles is an active member of Ottawa .Net Community; he has coordinated the last 2 Ottawa Code Camps and has played a major role in several ODNC Study Groups. Charles will also be one of the presenters at this year's Microsoft Tech Days Tour taking place in Ottawa next month.

The zip file contains the Visual Studio 2008 solution and PowerPoint used in the presentation.

Presentation covers:

• The objective of upgrading the legacy filter class is to migrate the 'prototype' design done in 2007 and meeting with increasing success in market to a mass deployed component. This means expanding the boundary conditions and improving the test methodology.
  
• Test Driven Development shows how to create a test case, followed by writing the code to "make the test pass".
  
• The legacy Filter class is upgraded to use Generic FindAll and Find methods with anonymous methods
  
• New method is added to Filter class as an extension method – good technique to follow when you want to add code in sand-box and test before submitting to release stream.
  
• Rhino.Mocks used to improve testing methodology.

We were joking around the other day trying to describe Jetfire when we hit upon DC#, for dynamic C#. Now to be fair C# does have dynamic attributes (especially C# 4.0); however most of C# functionality is determined at compile time. Generally to be considered a dynamic language such as IronRuby, or IronPython, most of a language's functionality should be determined at run time. Dynamic languages do sacrifice some performance for increased application flexibility, although some would argue that in real applications there is no sacrifice in performance.

We say Jetfire, at least in jest, should be called DC# because its syntax comes directly from C# and it is a dynamic language. Jetfire has the following dynamic attributes

• Dynamic typing
  
• Dynamic Access Modifiers
  
• Code can be created and executed 'on the fly'
  

Jetfire Links

• Jetfire Site
  
• Download Jetfire
  
• Jetfire Technical wiki
  

Related Articles

• Modeling a Workflow in Software
  
• Writing Jetfire programs
  
• Why use a Language vs a Framework
  
• Workflow Ecosystem
  
• Displaying Workflows
  

On the surface modeling a workflow in software might seem like a very straight forward task.

After all according to wikipedia "A workflow is a depiction of a sequence of operations…". This sounds like a great match for a computer program modeling the workflow.

You could then use the software workflow to

1. Guide you through the workflow process.
   
2. Perform actions through the software such as send email, operate equipment or perform a computational process such as adjust a photograph.
   
3. Facilitate approvals
   
4. Record activity especially when actions were taken.
   
5. Roll up the results and status in other documents
   

However there are issues (you didn't think it could be quite this simple). All of these issues are resolvable, but add an extra layer complexity to modeling a workflow in software.

1. Workflow programs must be able to operate for days, weeks or even years. The implication is that the workflow program must automatically preserve its status. The status must be automatically restored if the computer is restarted.
   
2. Workflows go through states when the operations occur. Operations, or commands, need to work only in the appropriate state. For example a "Complete" command may only valid once the workflow is 'started'.
   
3. Workflows are performed by more than one person. This means that the workflow must be able to support simultaneous users working on different computers or devices.
   
4. Workflows need to be shared, but also be protected from incorrect usage. For an expense workflow the user may need to be a manager to approve it. The workflow program needs support different roles for different users.
   
5. Not everyone who uses a workflow sees the same data. For example an approver's comments may need to be hidden from the applicant.
   
6. Workflows change over time. For example an 'approval' process may change while there are requests in the system. The workflow software must be able to handle 'grandfathering' the process for requests already in the system or optionally support upgrading them.
   
7. Workflow programs need to be simple to design and build.
   

This is rational behind the dynamic language
Jetfire. Jetfire is domain specific language that handles all these issues with ease. Applications can be built quickly. Application code isn't obscured by reams of infrastructure code. With Jetfire the designer of workflow software can concentrate on the application, not the infrastructure. All this makes the workflow program more reliable and much easier to maintain.

Links

• Jetfire Site
  
• Download Jetfire
  
• Jetfire Technical wiki
  

Related Articles

• Writing Jetfire programs
  
• Why use a Language vs a Framework
  
• Workflow Ecosystem
  
• Displaying Workflows

We have been asked a number of times "where is the Jetfire visual designer"? Our attention was aimed at getting the programmatic model correct. We are now starting to deliver purpose-built visual designers. Why multiple designers?

The objective of Jetfire visual designers is to:

• Provide simple GUI's for building applications
  
• Take the 'programming' out of 'application programming'
  
• Easily deploy applications
  
• Provide a one-step process to writing and deploying applications
  

Figure 1: Form Maker in design mode

Our first release for purpose-built visual designers includes Form Maker. It is a simple first step, but designed to be practical. The key features of Form Maker include:

• Add one or more properties
  
• Reorder properties
  
• Identify the property type (text, date, duration, integer, and more)
  
• Build applications based on previous programs
  
• Form validation
  
• One-click deployment
  

Figure 2: Form Maker in layout mode

Click the 'Show Form Layout' link and Form Maker displays how the Form is displayed to a user.

The differentiator of Form Maker is one-click deployment. The user creates an application and with one click adds the application to the Jetfire ecosystem – ready for use.

Figure 3: Property types

Figure 3 shows the types of properties that can be added to a form in Release 1.

'UnknownType is displayed when reviewing an existing program and the property type is unknown, e.g. an enumeration.

In a previous blog, we stated that the "objective of Jetfire is to simplify the workflow creation/modification process so that Power Users can build workflows and upgrade them".

In the early 90's, I worked for a large corporation that implemented ISO-9001. To be compliant with ISO-9001, each department has to show that they followed their processes. The easiest process to show compliance was the software submission process, because it was tooled. Tracking the paper processes required continuous manual intervention.

Continuous Improvement is the name of the game to improve product quality. Software that naturally reinforces the rules is required to support quality processes. Tooling with the ability to easily upgrade is required. With this back-drop, let's look at Jetfire.

1. New Jetfire workflows are easily added, without upgrading system software.
   
2. Jetfire workflows should easily up-version.
   
3. Light-weight workflow ecosystem
   

Jetfire programs are built on an object oriented ecosystem that executes Jetfire code interpretively. This approach allows Jetfire workflows to be easily uploaded, without the need to upgrade the system software.

To up-version code, version is included in every object in the system. New code creates a new version of a Workflow Class, which are related to previous versions of the named workflow class. New and previous versions of the Workflow Class are accessible with the preferred class to be instantiated being the current version.

Finally, the small size of the Jetfire ecosystem provides a compact environment that is targeted at building applications.

Jetfire is a DSL (domain specific language). So what domain are we talking about?

When we started Jetfire, the goal was to create a language that makes workflows easy to write. I can say without reservation that we have achieved that goal. Let's review the differences between Jetfire and C#.

1. Jetfire is based on C#, so that programmers can easily write it.
   
2. The keyword 'workflow' replaces 'class'. 'workflow' is used to activate first class support for workflow constructs.
   
3. Dynamic Access Modifiers are used to make class members public/private depending on who is using the class.
   

The Jetfire domain specific language incorporates first class support for workflow constructs.    

Let's review some examples of how Jetfire simplifies writing workflows.

Example 1: States – Some workflows are state driven. Jetfire Methods include a new type of method: the state method. 'enterstate' is a keyword used to promote the workflow into the specified state.

Example 2: Dynamic Access Modifier example using states – the AddData method is public when the workflow is in the Start state. Otherwise, the AddData method is private.

Example 3: Dynamic Access Modifier example using access – the DoSomething method is public if the logged in user has the Role 'Approver'. Otherwise, the DoSomething method is private.

These are some powerful examples how a domain specific language can simplify writing workflows.

If you are a programmer you use frameworks. Some frameworks such as a collection framework are almost indistinguishable from the language. I know in my C# code I find almost all my classes contain either 'List' or 'Dictionary'.

Other frameworks such as ADO .net are very large and require quite a bit of time learn. They provide an indispensible service to your application but are very difficult to learn and use. The application code that employs the framework is almost unintelligible. Adding more comments or the more judicious use of variable names seems to have no effect on making the code look better. The problem is that most frameworks need to expose details of internal concepts to application as numerous tunable parameters and properties. This is required since a typical framework has no other mechanism of inferring intent.

The need for the framework to have numerous tunable parameters and properties (lazy loading, concurrency issues, etc) compounds usage problems. This is because in order to be used correctly they need to be understood. Subtle errors in understanding a concept of a framework produces either subtle errors in the application or causes the application not to run a peak performance.

Using a domain specific language addresses a number of these problems.

1. A domain specific language after all is just another language. Most languages can be learned in a few hours to a few days. When we wrote Jetfire we started with C# syntax adding few specific features. A programmer's investment in understanding languages could be reused. The additional features in Jetfire, for example, are consistent with the C# programming paradigm.
   
2. The code in a DSL is designed to be understandable and compact. Unlike working with a framework where hundreds of lines of code are required just to provide initialization, working with a DSL typically requires very little code.
   
3. When you write code in a DSL the language is able to understand the programmer's intent and therefore is able to hide most of the complexity. For example Jetfire understands that variables should be saved to persistent storage. Therefore Jetfire does this automatically without the application programmer writing extra code. Jetfire also knows if a variable is used inside a method that it doesn't need to be saved because that variable is only valid as long the method is executing.
   

Further reading:

Why The Next Five Years Will Be About Languages