Waterloo, ON - January 23, 2012 - OpenText (NASDAQ: OTEX, TSX: OTC) today announced the expansion of its global alliance agreement with Microsoft Corp. to include wider support for Microsoft cloud computing initiatives. As part of the agreement, OpenText’s

WATERLOO, ON – January 18, 2012 – OpenText’s (NASDAQ: OTEX, TSX: OTC) Business Process Solutions (BPS) group today announced that OpenText-Metastorm has been positioned in the Leaders quadrant of the 2011 Magic Quadrant for Business Process Analysis Tools report published by David Norton on December 12, 2011.

A question I’ve been asked a lot lately is, “How do I make use cases work in an agile setting?” I found myself struggling for an answer because a) agile is a mindset not a methodology and b) I didn’t think there was anything about use cases that prevented them from being used in an agile setting. So just do it. But I think the questioners were looking for something more prescriptive. So let’s break it down.

The Backlog

For starters, use cases are a form of requirements, and when we’re being agile, requirements go in the backlog. Often, those requirements take the form of user stories, but they could also be use cases. If they were, how might this work? Consider the composition of the backlog. The items down at the bottom, furthest away from being implemented, are described in a coarse manner. Probably just a name and maybe a description. This feels right since you don’t want to invest much time or energy in requirements long before they will be designed or implemented. That would be the opposite of agile.

So use cases would enter the backlog as a simple name and description. Almost like a placeholder – or an agreement to have a conversation later. This reminds me of the definition of a user story actually. One difference would be, we’d eventually write down parts of that conversation in the form of a use case.

As use cases percolate higher up in the backlog, we’d add more detail to them: a success scenario, some alternate scenarios, maybe related requirements or a wireframe. The risk to avoid here is investing too much effort in detailing use cases that are further down in the backlog. Don’t write documentation you don’t need. The line you want to to be weary of crossing is writing more detail than what is needed to deliver your next iteration.

A Use Case: Too Big for a Sprint?

I think of use cases as one way to group a set of requirements: a user goal, scenarios, constraints, business rules, wireframes, diagrams, etc. As much as I like use cases, one challenge with agile will be, they are too large to be considered an atomic unit of work. By themselves, they don’t make for a useful burn down chart. In fact, you might not fit a complete use case into a single sprint. So the use case – this grouping of requirements – needs to be broken down into some other logical chunks of work.

I’ll cover what those chunks are in my next post.

What do you think? Are use cases and an agile backlog a complete mismatch? Let me know in the comments.

Eclipse is turning 10 years – and we have been in a mood to celebrate it. We have been involved in a lot of Eclipse related events in the past, but wanted to do something special this year. If you are in Boston, come join us next week. We will be having free pizza, beer [...]

Here at Abstratt we are big believers of model-driven development and automated testing. I wrote here a couple of months ago about how one could represent requirements as test cases for executable models, or test-driven modeling. But another very interesting interaction between the model-driven and test-driven approaches is test-driven code generation.

You may have seen our plan for testing code generation before. We are glad to report that that plan has materialized and code generation tests are now supported in AlphaSimple. Follow the steps below for a quick tour over this cool new feature!

Create a project in AlphaSimple

First, you will need a model so you can generate code from. Create a project in AlphaSimple and a simple model.

package person;

enumeration Gender
  Male, Female
end; 

class Person
    attribute name : String;
    attribute gender : Gender;
end;

end.

Enable code generation and automated testing

Create a mdd.properties file in your project to set it up for code generation and automated testing:

# declares the code generation engine
mdd.target.engine=stringtemplate

# imports existing POJO generation template projects
mdd.importedProjects=http://alphasimple.com/mdd/publisher/rafael-800/,http://alphasimple.com/mdd/publisher/rafael-548/

# declares a code generation test suite in the project
mdd.target.my_tests.template=my_tests.stg
mdd.target.my_tests.testing=true

# enables automated tests (model and templates)
mdd.enableTests=true

Write a code generation test suite

A code generation test suite has the form of a template group file (extension .stg) configured as a test template (already done in the mdd.properties above).

Create a template group file named my_tests.stg (because that is the name we declared in mdd.properties), with the following contents:

group my_tests : pojo_struct;

actual_pojo_enumeration(element, elementName = "person::Gender") ::= "<element:pojoEnumeration()>"

expected_pojo_enumeration() ::= <<
enum Gender {
    Male, Female
}
>>

A code generation test case is defined as a pair of templates: one that produces the expected contents, and another that produces the actual contents. Their names must be expected_<name> and actual_<name>. That pair of templates in the test suite above form a test case named “pojo_enumeration”, which unsurprisingly exercises generation of enumerations in Java. pojo_enumeration is a pre-existing template defined in the “Codegen – POJO templates” project, and that is why we have a couple of projects imported in the mdd.properties file, and that is why we declare our template suite as an extension of the pojo_struct template group. In the typical scenario, though, you may would have the templates being tested and the template tests in the same project.

Fix the test failures

If you followed the instructions up to here, you should be seeing a build error like this:

Line	File		Description
3	my_tests.stg	Test "pojo_enumeration" failed: [-public -]enum Gender {\n Male, Female\n}

which is reporting the code generated is not exactly what was expected – the template generated the enumeration with an explicit public modifier, and your test case did not expect that. Turns out that in this case, the generated code is correct, and the test case is actually incorrect. Fix that by ensuring the expected contents also have the public modifier (note that spaces, newlines and tabs are significant and can cause a test to fail). Save and notice how the build failure goes away.

That is it!

That simple. We built this feature because otherwise crafting templates that can generate code from executable models is really hard to get right. We live by it, and hope you like it too. That is how we got the spanking new version of the POJO target platform to work (see post describing it and the actual project) – we actually wrote the test cases first before writing the templates, and wrote new test cases whenever we found a bug – in the true spirit of test-driven code generation.

Can you tell this code was fully generated from a UML model?

• Person class
• Account class

This is all live in AlphaSimple – every time you hit those URLs the code is being regenerated on the fly. If you are curious, the UML model is available in full in the TextUML’s textual notation, as well as in the conventional graphical notation. For looking at the entire project, including the code generation templates, check out the corresponding AlphaSimple project.

Preconditions

Operation preconditions impose rules on the target object state or the invocation parameters. For instance, for making a deposit, the amount must be a positive value:

operation deposit(amount : Double);
precondition (amount) { return amount > 0 }
begin
    ...
end;

which in Java could materialize like this:

public void deposit(Double amount) {
    assert amount > 0;
    ...
}

Not related to preconditions, another case assertions can be automatically generated is if a property is required (lowerBound > 0):

public void setNumber(String number) {
    assert number != null;
    ...
}

Imperative behavior

In order to achieve 100% code generation, models must specify not only structural aspects, but also behavior (i.e. they must be executable). For example, the massAdjust class operation in the model is defined like this:

static operation massAdjust(rate : Double);
begin
    Account extent.forEach((a : Account) {
        a.deposit(a.balance*rate)
    });
end;

which in Java results in code like this:

public static void massAdjust(Double rate) {
    for (Account a : Account.allInstances()) {
        a.deposit(a.getBalance() * rate);
    };
}

Derived properties

Another important need for full code generation is proper support for derived properties (a.k.a. calculated fields). For example, see the Account.inGoodStanding derived attribute below:

derived attribute inGoodStanding : Boolean := () : Boolean {
    return self.balance >= 0
};

which results in the following Java code:

public Boolean isInGoodStanding() {
    return this.getBalance() >= 0;
}

Set processing with higher-order functions

Any information management application will require a lot of manipulation of sets of objects. Such sets originate from class extents (akin to “#allInstances” for you Smalltalk heads) or association traversals. For that, TextUML supports the higher-order functions select (filter), collect (map) and reduce (fold), in addition to forEach already shown earlier. For example, the following method returns the best customers, or customers with account balances above a threshold:

static operation bestCustomers(threshold : Double) : Person[*];
begin
    return
        (Account extent
            .select((a:Account) : Boolean { return a.balance >= threshold })
            .collect((a:Account) : Person { return a->owner }) as Person);
end;

which even though Java does not yet support higher-order functions, results in the following code:

public static Set<Person> bestCustomers(Double threshold) {
    Set<Person> result = new HashSet<Person>();
    for (Account a : Account.allInstances()) {
        if (a.getBalance() >= threshold) {
            Person mapped = a.getOwner();
            result.add(mapped);
        }
    }
    return result;
}

which demonstrates the power of select and collect. For an example of reduce, look no further than the Person.totalWorth attribute:

derived attribute totalWorth : Double := () : Double {
    return (self<-PersonAccounts->accounts.reduce(
        (a : Account, partial : Double) : Double { return partial + a.balance }, 0
    ) as Double);
};

which (hopefully unsurprisingly) maps to the following Java code:

public Double getTotalWorth() {
    Double partial;
    partial = 0;
    for (Account a : this.getAccounts()) {
        partial = partial + a.getBalance();
    }
    return partial;
}

Would you hire AlphaSimple?

Would you hire a developer if they wrote Java code like AlphaSimple produces? For one thing, you can’t complain about the guy not being consistent. Do you think the code AlphaSimple produces needs improvement? Where?

Want to try by yourself?

There are still some bugs in the code generation that we need to fix, but overall the “POJO” target platform is working quite well. If you would like to try by yourself, create an account in AlphaSimple and to make things easier, clone a public project that has code generation enabled (like the “AlphaSimple” project).

Hello all,

we have released the new version 2.4.0 of Oclarity, our OCL authoring environment.

Oclarity main window

This release contains a couple of bug fixes in the parser and the OCL standard library.
In addition, we have updated the XMI Parser to support Enterprise Architect 9.1 and MagicDraw 17.0.

See this page for all changes. You can also read the manual to learn more.

Oclarity is free, so just try it, if you are interested in the Object Constraint Language.

If you have any problems or suggestions we would be happy to hear from you. Just send an email to support@empowertec.de.

Best regards,
Andreas

Technorati Tags: Oclarity, OCL, Object Constraint Language