Hi Teemu,
I've not tried this for a long time, so I don't remember all the details. The basic idea is that you have to define the messages - the actual 'flows' of information - first, and then reuse them in your flow properties and specifications.
[This approach is a common theme in Sparx add-ins. It helps to set up all the lower-level stuff before you get too far into your model. This makes it easier, and much less frustrating, when it you do the high-level stuff.]
I think you might need to do the definition on another diagram. [Where and what you use for this I simply don't remember.] Once you've got the appropriate messages defined, the flows realized list will be populated.
Unfortunately this is - or was back when I tried it out - not clearly documented (if it is covered at all) in the SysML add-in documentation. Unfortunately Sparx does not seem to publish the documentation for the add-ins on their site, so I cannot look it up for you without installing a trial kit, and I really don't want to do that.
--- OK, you can stop reading now if you want. ---
[This is another common situation with Sparx add-ins, weak documentation seems to be a common problem. Despite the tremendous improvements in core EA documentation, this remains a problem. My personal feeling is that the root cause of this problem is the way in which documentation is handled at Sparx, rather than the team behind the products and documentation.]
[IMHO (note the emphasis) the Sparx methodology for getting products out the door really lets us down here. During the beta period and at first release documentation is sketchy at best, and 'catching up' is often the best that can be done; this seems to be the reality for rapid product release across the bulk of the industry. But Sparx tends to release updates to documentation with new builds of products. The add-ins have extremely long cycle times compared to the core EA product, being the equivalent of major updates. This not only delays documentation updates but allows them to become lower priorities; there's no need to make updates for a release in the next few weeks. New documentation must wait until significant new features or changes warrant a major product revision. The cannot be done in advance of the decision to change the product - who knows what it will look like until then - and become subject to the same beta and new release issues that are the root problems.]
[For me - and this does not in any way suggest the same would hold true for anyone else - this is the single greatest common problem I have the the non-core EA software. To this point it has been sufficient to stop me from adding any of the 'options' to my standard configuration, even though I am enthusiastic about the features provided. I simply do not have the time to hunt down each idiosyncrasy every time a client needs advice on how a feature was implemented, let alone do so for myself.]
Sorry about the rant, but I tried to put the 'good stuff' at the beginning.
HTH, David
