New webinar – Introducing OCL: fast ways to deploy business rules

Tricia Balfe from Nomos Software has offered me an online introduction to OCL. The conversation started here getting-benefit-from-ocl-rules-with-nomos

She said she will show me how to deploy the business rules into Java. I asked her to keep it simple! She has set up a webinar and said anyone can join. Tricia is a genuine expert, so it will be good. Webinar: Introducing OCL: fast ways to deploy business rules

A great model driven success story

There are not many documented, well thought through success stories in the model driven world. Tricia Balfe at Nomos-Softyware has written one that is really well thought through. Not only that, it is not about her or Nomos, it is about a globally used solution for the finance industry. http://nomos-software.com/blog/a-model-driven-success-story

Spring Framework – the model model driven target?

I had an interesting conversation with Tricia Balfe from Nomos Software last week (all conversations with Tricia are interesting!).

If we are generating solutions from abstract level models, what are the attributes of a good target technology?

3 things I argued for:

A) Separate the assembly of the system components from the components themselves.
B) Full visibility of the code, one of the advantages of open source.
C) Separation of concerns.

Doubts about my convictions, unusually, occurred. Am I prioritising these because I am using Spring Framework, and these are the core strengths of Spring? The Dependency Injection of Spring means components are wired together in an independent layer. And Spring makes heavy use of Aspect Orientated Programming, which is great for separation of concerns. For me, makes it easy to assemble solutions from the widest possible choice of generation approaches.

By what attributes should a target technology be measured?

What is model driven testing?

Model driven testing is the process of generating test strategy, test cases and test data from business models. Traditionally testers do these steps done manually, often by a separate testing team.

What is the problem?

HIGH COST: Testing is up to 50% of a systems development cost.

100% CORRECTNESS: IT solutions must be 100% right – no one can afford errors and certainly not the reputational risk of customers find something wrong.

HIGH RISK: The end users don’t trust IT departments. So the end-user departments invest over heavy in testing.

HIGH COMPLEXITY: IT environments are large and complex, so getting the testing processes working is expensive.

TAKES TOO LONG: Testing can be 30% of projects elapsed time. Testing is largely manual so it all takes too long. Most shops don’t start planning testing till late in the life-cycle, adding it to the critical path.

UNCERTAIN: Since you don’t know what you will find in testing the time is unknown (so you have to pad!)

What does model driven testing offer?

Cost and time reduction, while improving testing quality.

How?

BETTER SPECS: In my experience, 50% of bugs are in the specs. Model driven functional, business rule and data specs are more accurate, complete and consistent.

MODEL DRIVEN TEST DESIGN: Our Cameo Model Driven Testing Plugin enables business analysts and testers to “mark up” the design documents with testing strategy and approach – far more efficient. Correctness and completeness can be proven. We can bring forward test planning as we write tests against the models, not the designs and or functional specs – so saving elapsed time.

CORRECT CODE: Generated code is correct so does not need unit and system testing in the traditional sense.

TEST AUTOMATION: From the data structures and business rules in the models we generate java and other code to test data based on what is in the specifications.

AUTO GENERATED TEST DATA: Getting test data that exercises all the test cases is very labour intensive. However, with a good model of the business domain, test data can be generated programmatically.

USE EXISTING LIBRARIES: There are a number of existing model driven testing frameworks. For example, banks that process payments have the choice of existing testing frameworks and test harnesses.

Would you like to see model driven testing in action?

I would be interested any sharing of ideas about model driven testing. It would be no effort to set up a short web-based meeting to walk through what I have working.