Wednesday, October 28, 2009

Policy Activity in Windows Workflow Foundation (WF)

When we think of workflow, we think of business processes. These business processes are based on some predefined business rules or policies like discount rates etc. Though we can define our rules in code activities in workflow foundation but we have better option. This option is by using Policy activity in your workflows.

Policy activity allows more natural processing of business rules than the general procedural execution of rules. It uses forward chaining mechanism of inference engines. This is based on artificial intelligence concepts. Using this mechanism, the engine might evaluate these rules more than once if it these rules are dependent upon each other.

Rule Execution in Forward Chaining System:
There are two methods of reasoning for inference rules in Artificial Intelligence. They are forward chaining and backward chaining. The backward chaining is goal driven. Windows WF uses forward chaining for the execution of its rule sets. This is a data driven mechanism.

Which rule to pick up first: All rules are available for rule engine as a collection of rules. For equal priority rules, they are picked up in the ascending order of their names.

After processing each rule, the WF rule engine checks which rule to process next based on the determined dependencies between rules. It picks up the highest priority rule and executes it. It is possible that it processes the same rule again based on the criteria of rule selection.

Rule Set in Policy Activity:
The rules in the Policy activity are defined with the help of Rule Sets:



This activity allows us to define various rules connected to each other in the form of rule sets. These rule sets might be dependent or independent of each others. Two rules are considered dependent if one modifies a property which another rule is dependent upon.

It must be remembered that any rule might be disabled anytime. If a rule is disabled, then runtime would not be executing that rule.

Structure of a Rule in Rule Set:
A rule has following structure in Policy Activity:

If CONDITION then
ACTION1
ELSE ACTION2


The values for Condition, Action1 and Action2 are provided when a rule is defined. Remember that Action2 is not a required Action. They are basically code blocks which require technical coding knowledge.

Dependencies between Rules:
As we have discussed, multiple rules can be defined in a Policy activity. These rules might be dependent upon each other in different ways.

Since this is a forward chaining mechanism, there must be a way for system to determining dependencies between rules. There are three options to specify such dependencies. They are as follows:

1. Implicit:
As its name implies, the engine automatically finds out about the dependencies between rules. If a rule is modifying a property in its action that is part of condition of another rule then they are considered dependent. It must be remembered that it is basically the direct modification of properties that we are talking about. If a rule is calling a method which is modifying some property that condition of another rule is dependent upon, rule engine would not be able to find such dependencies.

2. Attribute based:
This is used when actions are using some methods which are modifying some properties that another rule is dependent upon. A method must specify the properties it is modifying with the help of attributes. There are following attributes available for such purpose.
1. RuleRead: When a method is using some property but not modifying it.
2. RuleWrite: When a method is modifying some property.
3. RuleInvoke: When this method is calling some other method which might be using or updating the value of some property.

E.g. if a method, named myMethod, is modifying a property, named myProperty, then it is defined as follows:

[RuleWrite(“myProperty”)]
Public void myMethod() {…}


You would be glad to know that you can use wildcard (*) if you want to specify that a method is modifying more than one properties. E.g. a method is modifying all the properties of customer class. It should be specified as [RuleWrite(“Customer/*”)]

3. Explicit:
Attribute based dependencies specification works in all scenarios except when you don’t have access to the code directly and you are using libraries which are modifying some properties. Since you can not modify the code of libraries for introduction of attributes, there is another feature provided for dependencies specification. It is based on explicitly specifying that this method call could modify some field / property. Update statement is used for this purpose. E.g. a method is used which modifies some property myProperty. This has to be specified like this:

this.myMethod()
update(myProperty)


Priority of Rules:
Priority affects in the evaluation of rules when more than one rule is part of a Policy Activity. These rules are evaluated in the descending order of their priorities. The rules with the same priority are executed in the alphabetical order of their names.

The value of Property must be an integer value. It can not be blank.



What if two rules have same priority?
If two rules have same priority then they are executed in the ascending order of their names. Two rules can not have same names. Remember that their appearance in the Rule Set Editor might not be the same as their order of execution.

Chaining of rules:
This is used to control the forward chaining behavior of rule sets. There are three options possible:



1. Full Chaining:
This is the default forward chaining behavior. This would keep tract of all dependencies between rules and evaluates and re-evaluates rules as per the requirements.

2. Sequential:
This option specifies to the engine that it evaluates every rule once and only once no matter any THEN or ELSE action is executed or not. Only priority is considered for the execution of rules.

3. Explicit updates only:
This is extreme control of chaining. This means to avoid all the implicit and attribute based dependencies. Only those dependencies are considered which have explicit Update statement.

Reevaluation Options:
There are two reevaluation options available for rules. They are as follows:

1. Never: This rule is evaluated only once and never be reevaluated based on the execution of rules executed after this rule. If the rule has not yet executed any THEN or ELSE action, it would still be re-evaluated.

2. Always: All rules, which are executed after this rule, will cause reevaluation of this rule.



Rules file:
If you want to have a look at how these rules are managed by Windows WF, open the rules file in your workflow. This is an xml file. As we have seen that the rules in the Policy Activity are defined in the form of rule sets. The skeleton definition of these rule sets in the workflow file is as follows:

<RuleDefinitions>
<RuleDefinitions.RuleSets>
<RuleSet>
<RuleSet.Rules>
<Rule>
<Rule.ThenActions>
<RuleStatementAction>
</RuleStatementAction>
</Rule.ThenActions>
<Rule.Condition>
<RuleExpressionCondition>
</RuleExpressionCondition>
</Rule.Condition>
</Rule>
</RuleSet.Rules>
</RuleSet>
</RuleDefinitions.RuleSets>
</RuleDefinitions>


Though this seems that, since this is based on xml, we can update these rules whenever we want without needing any recompilation again, but it is not that easy. All the code statements still are code statements which are referenced in this xml.

Halt Command:
HALT Command: It is a special statement which can be provided in the action list of any rule. This statement halts the execution of the rule set. After this statement is executed, no more rule from the rule set are executed.

Sunday, October 25, 2009

Basic features of a good Business Rule Framework

While working on business logic side of our application, it is often advised to have a centralized mechanism for management and execution of business logic. I have thought about some of the features that this Business Rule Framework should have. Having the features before hand would provide ease in evaluating various Business Rule frameworks available in the market.

While reviewing the text, I could see some of the overlaps between various features. But, I think, it is good to keep them separate.

1. Nesting and Sequencing of rules: The rule framework must provide us the ability to nest rules. This would allow us to decide the nested rules to be selected based on certain other rules.

2. Logical relationship between rules: For a condition, all rules should be satisfied or any rule should satisfy. In technical terms we have certain logical relationships like AND, OR etc. We want our rule engine to be providing such conditions.

3. Enabling / Disabling the rules: We should be able to enable / disable a rule under any circumstance. It means that we don’t have to delete the definition of rule but just disable it somehow so that it is not applied.

4. Rule Profiles: I don’t know this should be the name of title that I want to discuss. Let me explain what I have in mind, the rule engine must be able to decide application of rules based on the user / role / group. Its designer and engine should be able to access directory service. This would not only make the life of architect easier coz you wouldn’t have to decide in the code to select rule, this service would automatically be provided by the rule framework.

Doing so, it should be able to access the directory services so that It could select groups / users and design / apply rules based on their roles.

This profile can also be selected based on the source type. This source might include regions, devices. This is because certain regions and countries might have different rules e.g. financial and our rule framework must be able to see the source and decide which rules should be applied accordingly.

5. Business User interface: The rule framework should provide ability to provide some interface to business user so that not only they could understand the rules easily (language should be easy) but they might also be able to update those rules.

The system should also give the business users ability to create new rules and inject them at the required step.

6. Dynamic Updates: No compilation and build should be required to update business rules. It should be dynamic. As soon as rules are updated, the effect should be visible in the application.

7. Communication abilities: The business rule framework must provide abilities so that it could communicate with the hosting environment both ways. This feature should be available as desired in addition to the instant when they are called.

It should also provide ability so that it can communicate outside the hosting environment i.e. it could access any service across the available networks supporting the service oriented architecture.

8. Documentation Support: Business rules System should provide documentation feature. This can be stored as metadata of the business rules. It should allow different views of this documentation for business and technical users.

Users should be allowed to extract information from the documents by exporting them to formats generally used by users like word, CHM and Visio diagrams etc.

9. Instrumentation: This should support instrumentation so that logs can be created. It should support major instrumentation frameworks like WMI. It should allow different logging mechanisms like email, Windows Event log, log files etc.

Users should be allowed to define the formats of these logs. They should be allowed to define what information should be logged. The framework should provide certain variables like source information (user and machine), time of day etc.

10. Events for Rule Execution: There should be events for rule execution. The events might be fired on the basis of pre or post execution of rules. We might create other events which we can think of. In those events, we might be able to cancel the rules if certain condition is not satisfied.

11. Reliability and Availability: The rule engine should be reliable. It should allow consistency for users. It might also support redundancy as part of its design in case off any failure. Keeping single Rule Engine Server would introduce the Single Point of Failure in the design.

12. Storage Options: These rules might be stored in any or the combination of database, XML, compiled code options. Updating the storage options should not be visible to the client applications.

13. Seamless Just in Time Deployment: Clients must not be bothered when these rules are updated and deployed. This operation should be seamless.

This is really tricky because there would be some users which would already be executing rules at any instance.

14. Versioning of rules: System should support to maintain versions of these rules. Administrators should be allowed to maintain these versions. Client applications should be given flexibility to specify any particular version or latest version (as desired) for these rules.

15. Security: The rules must be secure. There should be some authentication mechanism. This would secure the rules from being updated by unwanted users. There should be category of rules which should be allowed to be updated by certain roles. These groups and users might be the same users as in the directory services.

16. Available for different Programming platforms: Organizations evolve. Some of the applications lose their values with time. So they are replaced with new systems. Doing that, these organizations have many applications running at the same time. They are developed in different programming platforms. (.net, java etc). The rule engine must be open to accept and services the requests from any platform. Being service oriented is the key for this.

17. Scalability and Performance: Response time is the key in in current businesses because we don't want our users to wait for the response drumming the keyboard. The system should be scalable to the number of users. This might provide provide documented hardware specifications based on the number of users. For good performance, the engine must be as light weight as possible for faster execution of rules.

18. Adaptable workflow for rules management (Approval mechanism) and Audits: We can not trust an individual for managing all the rules in every application in the entire organization. There should be some kind of approval mechanism so that updated rules are monitored and controlled. There should be detailed history of these approvals.

19. Pre-production release of rules: Organizations generally have three different environments. First is development in which the applications are developed. After development is complete, they are released for User Acceptance Testing (UAT). Once they pass UAT, they are released to Production environment. Our rule system must allow us to work like that i.e. we should have different environment to work. We should be able to release it in these environments to be satisfied before ruining the actual production processes.

20. Audits of Rule Execution: The user should be given option of creating the audit trail of execution of rules. The audit trail should have details like user, application. The system should allow user to view this information in the form of reports.

Tuesday, October 13, 2009

Visual Studio Team System (VSTS) 2008 Code Metrics & Complexity

In today's discussion, let us discuss about different code metrics provided by VSTS. How to look at different values of these code metrics? We would also be discussing about how these metrics are calculated by Visual Studio.

A metric is actually a representation of quantatively specifying the maintainability of the code. You can have an idea about the code quality by just looking at the value of desired code metric.

Available Code Metrics:
There are following code metrics available by Visual Studio Team System 2008.

1. Lines of code
2. Cyclomatic Complexity
3. Class Coupling
4. Inheritance Depth
5. Maintainability Index

Let us discuss about each of the metric in detail:

Lines of Code:
Lines of code is not only used for sizing of a software system but also to define the quality and complexity of it. If you are writing your modules as small sub-systems then it might be a better design instead of writing big classes and their methods with multiple responsibilities.

Although people might argue in the effectiveness of using line of code as a tool for software estimation and sizing but it can surely be used a tool for representing code complexity. The bigger the code block the more difficult is to develop, maintain and test it.

The metric calculation excludes comments, white spaces, braces and declarations.

Depth of Inheritance:
This is the only purely class level metric available of the list. This specifies the number of levels of inheritance to the class under consideration starting from System.Object. (Note: All classes are implicitly inherited from System.Object). Numerically it is equal to number of classes between the class and System.Object plus one.

As you might have imagined, the smaller values would be better. This is because of complexities that come with adding layers to the inheritance hierarchy.

Class Coupling:
This is one of the object oriented code metric in VSTS. This is also based on industry standard code metric. It is equal to number of distinct classes that your class depends upon.

As we know from a long time “Our code should have low coupling and high adhesion”, so this metric is expected to have low value.

This metric can also be specified at method level. In that case, it would show the number of distinct classes this method is using. This doesn’t include the class that this method is part of. The metric for a class is the number of distinct classes used anywhere in the class. For the instance / class level variables use, it would show as coupled with the constructors of the class.

Though some people have this misunderstanding that Visual Studio Team System does not provide information, about classes of other assemblies, being used by any particular class, but this seems to be far from truth in practice.

You should remember that class level metric is not the summation of the metric values for all its methods. As I see it, this may be because of two reasons: First, the methods may be using some similar classes and for the calculation of metric only distinct class coupling is considered. Second, as we have seen the class level variables are shown as coupled with all the constructors, which is also repetitive for all constructors. The same discussion is true for the metric calculation for modules and namespaces.

Cyclomatic Complexity:
This metric was proposed by McCabe in 1976. The metric value is calculated by creating a control flow graph of the method. Its formula for a single connected graph may be presented as follows:

Cyclomatic Complexity = The number of edges - The number of nodes + 1

The value of cyclomatic complexity is basically the number of linearly independent paths through the source code. As you might have guessed, this might also be equal to the number of test cases for the module. The value of complexity should be controlled during design and development of modules. If a module has a complexity more than a specific value (generally 10 or 15), it is recommended to be divided into simpler modules. But this restriction might be relaxed if needed. It is recommended to write explanation under such cases of relaxations.

This metric may be calculated by assigning exact numerical value to various programming constructs e.g. loop (like for and while), branching (like if and switch).The lower the value the more maintainable, testable and understandable the code is.

The metric value of Cyclomatic complexity of a class is the sum of Cyclomatic Complexity of all its methods. In the same way, the metric for a namespace is the sum of metrics of all classes within the namespace.

Maintainability Index:
Of the available metrics, this is the only metric for which higher values are considered better. The formula for maintainability index as specified on Code Analysis and Code Metrics team blog is as follows:
Maintainability Index = MAX (0, (171 - 5.2 * log2 (Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * log2(Lines of Code))*100 / 171)
This is an updated version of Maintainability index formula as developed in Carnegie Mellon University. Compared to the original formula, this formula avoids negative metric value. Like other metrics, this formula also doesn’t take comments into consideration. The possible values for this metric can lie between 0 and 100. The higher the value the more maintainable the code is.

As you can infer from the formula that lower values of Halstead Volume and Cyclomatic Complexity favors high value of Maintainability Index resulting in more maintainable code.

There are three color icons based on this metric value. They are Green, Yellow and Red.
Green: 20-100
Yellow: 10 – 19
Red: 0 - 9

Note:
Halstead Volume is one of the oldest metrics to represent code complexity. This is used in the formula to take into consideration the computational complexity of the code. This method looks at the code in the form of tokens. There are two types of tokens i.e. Operators and Operands. Its formula is as follows:

V= N * log2 n (where N (Program Length) is the sum of total number of operators and operands in the code and n (Vocabulary Size) is the sum of number of unique operators and operands)
Halstead is a comprehensive metrics. It provides various other calculations to calculate program difficulty level, effort to implement, Time to implement and approximate number of delivered bugs.

Limitations of Code Metrics in VSTS:
1. Customized metric can not be defined.
2. Calculation of code metrics cannot be set as check-in policy.


Auto Generated Code:
Modern IDEs provide us the ability to generate code easily for repetitive tasks. But we don’t want this generated code to be included as part of the calculation for code metrics.

Actually, this would certainly not be considered for calculating metrics if it is decorated with CompilerGeneratedAttribute available in System.Runtime.CompilerServices namespace. If a method or a class is decorated with this attribute, this would not be used for calculation of metrics.

Surely, you can use this attribute for classes / methods that you don’t want to be used for calculation.

Tuesday, October 6, 2009

Changing Working Folder in VSTS

Though it is rarely required but sometimes we need to change the local folders of the code. The local folder is called “Working Folder” in Visual Source Safe and we are used to this term.

If you want to change the local folder in VSS, you just right click and change the working folder. It is that easy.

Working on VSS for so long, we expect that using the same steps, we could change the working folder in Team System but there is no option like that. Seeing this one wonders if we are able to change the location of working folder in Team System. The answer is “Yes”.

As you know code is organized in VSTS in the form of “Workspaces”. We need to go through them in order to change the local folder. Don’t right click anything and just go directly to the File menu.



As soon as you click this menu, the following form is displayed:




As you can see that the available workspaces are listed in the form. Using this form we can add new workspaces. We can also update or remove any existing workspace.

To change the local path, we need to select the desired workspace in the list and select ‘Edit’. Doing this would open the following form:



As you can see that under Working folder’s list, there is a column called Local Path. Choose any working folder and hit … button to change the folder to you desired folder. This would open the following form:



Just select the folder and click OK.

You have successfully changed the local working folder. Great!!!

Monday, October 5, 2009

Shelving / Unshelving in Team System

I want to review some fellow's code. But the thing is that I would have to sit with him for that. This would definitely depend upon his availability. Can I do it from my PC? Sure you can!

For that he has to check-in his code.

What!!!???

But I don't want him to check-in his code because it hasn't been reviewed.

This is a general discussion that we used to have before Microsoft introduced a new concept in Visual Studio. A developer can make his code available for others even when he doesn't want it to be part of the checked-in clean code. This is called 'Shelving'. We would be discussing about it today.

Besides reviewing, it also keeps the code from being picked up by automatic build process which might be triggered at each check-in checking the sanity of the code.

Just right click the code file / project or solution. As you know it provides various options including the options related to source control like getting latest version and comparing the local code with version of code on the source control.

If you look closely, then you might find two new options. They are as follows:
1. Shelve Pending Changes
2. Unshelve Pending Changes

These options would provide shelving facility within source control in Visual Studio Team System.



This option is also available when you want to view pending changes. Just look at the window opened when you choose that option and notice the changes incorporated in order to support shelving of the code.


As you might know that, in Team System Source control, code is organized in terms of workspaces. You might want to evaluate policies and check-in notes before shelving the code. This option is also provided by the Team System.