Editing without Palette

From Arctis version 1.0.0.M0341 you can edit activities without using the palette. Just use the context menu. In case you want to de-select an activated tool, just use the ESC-key. For now, the context menu makes the same functions available as the palette, but we will add more context-specific actions in the future. Try it. You can save a lot of movement with the mouse pointer!




You can de-activate the palette altogether using the Preferences under Arctis / Editor. For COCOA-users on Mac OS the palette is not shown anymore to minimize errors of SWT on Cocoa as documented in Bug 323670

Simplifications on Outgoing Flows

From version M0332 onwards, the syntax for ending a flow is less strict. Operations that do not have an outgoing flow are treated as if they were followed by an edge and a flow final node. Similarly, output pins of inner blocks that have no outgoing flow are treated as if they were followed by an edge and a flow final node.

The old way is of course still valid, so you do not have to change anything in your existing building blocks.

Simplifications on Signals

Internal signals are there to listen in your specification that something has happened in your code: That a listener has been called, or that a long-running method has returned. Some of you may know that in order to make such a signal unique even if you have several instances of the same building block type, you should add "_{blockID}" to the end of the signal name, and also use the block ID in the Java code that actually sends the signal.

Things just got easier with version 1.0.0.M0318.

From now on, it is not necessary to append the block ID in the signal declaration. When you are using the sendToBlock() method from class Block or its descendant AndroidBlock, you can forget the blockID as well. (If for some reason you use the methods from AbstractRuntime, you still need those. But we recommend to use class Block instead anyways.)

So what do you have to do with your current models?

Nothing. You can still add the blockID, but you do not need to add it for new blocks and can remove it over time from existing block, since it looks nicer and is easier to understand by others.


Why does this change come now?

Arctis is part of a verification project, and we are constantly receiving feedback on how it is used and which features are needed. Based on this feedback we have seen that all signal IDs were specific for the building blocks that they are declared in, with some rare exceptions, which we can treat differently. Finding out what the "normal" and what the "rare" cases are takes time. And based on your feedback, more simplifications and new features are on the way.

Setting the classpath for Android

If you have created projects for Android applications or building blocks, the container "Arctis Android Runtime" was added to your project, containing classes that were useful for building applications with Android. Since these classes are stored in a plug-in and have no access to the Android libraries (residing in your installation of the Android SDK), some types could not be resolved.

We have therefore moved these classes into the project no.ntnu.item.arctis.library.android which you can obtain from the libraries website. Most likely, you already have it in your workspace. The container is then not needed anymore.

To update, do the following:

• Delete the container for "Arctis Android Runtime". (Right-click in the Package Explorer, select Build Path / Remove from Build Path).


• Make sure that any project that contains Android applications or building block refers to the Android library no.ntnu.item.arctis.library.android. Select the project in the Package Explorer, select Build Path / Configure Build Path, and add the no.ntnu.item.arctis.library.android in the project section.
  

Happy coding!

Arctis 1.0.0.M0317

The new version contains some fixes and improvements.

• Applications on Android and Java SE terminate now correctly.


• Context menus for guards and types are less hierarchical and easier to access.


• Partitions cannot be accidentally deleted.


• Arctis Building Block view can be synchronized with the editor.


• Move backwards in the animation with Arrow key "Up" should work.

Arctis 1.0.0.M0311

The new version fixes some minor bugs, including:

• old results from the validation are removed correctly when the validation is started again


• names of parameter nodes are checked more strictly

Arctis 1.0.0.M0260

This update contains some improvements that are best explained by pictures:

Building block that have instance parameters that can be configured show this by a 'P' in their upper left corner. Instance parameters are very handy to define constant values that vary for different block instances, for example the duration of a timer. You can learn more about instance parameters in the guide.

Within the Arctis view, the tooltip on an element reveals now some if its documentation. This should be enough to select among similar blocks that vary in how they can be configured. To reveal the tooltip, select the block and hit the space bar.

Apart from these, there are several other improvements and changes:

• Android support is now part of its own feature 'Arctis for Android', categorized under 'Arctis Extensions'.


• Collaborative blocks are categorized now as an experimental feature and have to be enabled in the preference page for Arctis.


• The transformation by default opens the generated Java projects in the Package Explorer.


• Set Type dialog is not initialized with any existing type on a types node.


• A double click on a project or library in the Arctis View opens the Java project in the Package explorer. A corresponding action is also available from the menu.

Arctis 1.0.0.M0208

This update fixes some issues with updating views and editor figures.

Arctis 1.0.0.M0207

This version improves the way handles of elements are shown in the editor, and constraints how their dimensions may be adjusted.

Arctis 1.0.0.M0202

This update corrects an error with the generation of state machines and initial states.

Arctis 1.0.0.M0200

This update contains no new features, but removes numerous constraints on building blocks and their ESMs.

• Blocks are not forced to have a state anymore, it is possible to have blocks that start and terminate within the same step, as long as their ESM declares a corresponding transition. This transition goes directly from the initial state to a final state.


• Blocks may define their ESM so that they can be instantly restarted, within the same step.


• When a token tries to enter a block that is switched off, the token just ends outside of the block. We still report a warning on this, since it may indicate a mistake, but in some situations it's handy to just ignore some tokens as we found out.


• When a block does not obey its own ESM, all corresponding steps are filtered out during the transformation, which helps for more robust designs and simplify some specifications considerably.

Arctis 1.0.0.M0140

Improvements:

• Duplicate building block allows now to specify the target project, in which the new block should be copied.
• The last generated project is marked in yellow to be easier visible.

Changes for Models and API:

• The method sendToMe is nor called sendToBlock and only works with the blockID.

Arctis 1.0.0.M0122

Instance Parameters
Blocks can now have instance parameters that make their adaptation to your application easier. For example, a counter could now have an instance parameter value that specifies how high it should count. Each instance of a counter block can then have a different value. A detailed explanation can be found in the documentation.


Building Block IDs
The ID for each building block (short blockID) can be obtained via the interface IArctisBuildingBlock. This is further explained in the documentation.

With the introduction of block IDs, the usage of AbstractRuntime.getRuntime(Object o) is deprecated since the blockID should be used from now on.

Arctis 1.0.0.M0119

• The Arctis Editor warns if a building block refers to projects that are not accessible.


• The model view (inherited from Ramses) now only shows state machine and component models, not the activity models from Arctis.


• The implementation process now also copies all Java files that a referred block needs, as long as they are mentioned in import statement within the Java files.


• Non-Java resources are now also copied, as long as they reside within the source folder of Java packages of a building block.


• The selection dialog for the type of building block now works correctly.

Deprecation of Blocks

You may want to experiment with alternative solutions for a building block, which is made easy with the "Duplicate" action that creates copies of a block. However, often you end up with a project full of similar blocks, loosing overview of which one you actually want to use.

Therefore, you can now deprecate blocks that you do not intend to use, but that are still so valuable that you do not want to delete them yet.

In the overview page within the Arctis editor, simply select "This building block is deprecated".



As a result, the labels are presented as shown below.



For libraries, deprecated blocks are not recommended to use any longer, and could be replaced in the future.

Arctis 1.0.0.M0114

This version fixes some issues with the synchronization: building blocks should now show up in the Arctis view after their creation and after import of projects via SVN.

Arctis 1.0.0.M0102

• All models of the workspace can be unloaded with the actions in the File | Arctis Models menu. This is useful for updating from SVN, to avoid inconsistencies. See this page for details.
  


• The Arctis Editor may now also open UML files directly. This makes it easier to work from the Java Package Explorer, for instance. Just right-click the UML file of a building block and select Open With... | Arctis Editor.

Arctis 1.0.0.M0101

We made the jump to Eclipse 3.5!

Please install Eclipse 3.5 and then Arctis via the update sites. This and future Arctis releases will not work on Eclipse 3.4 anymore.

Update to UML 2.2

Timers loose the duration they were configured with in UML 2.1 models, since UML 2.2 saves them differently. Since there are usually only a few timers in a specification and they are easy to updated, we opted for ignoring previous data and you have to assign the duration to timers again manually. Should be no problem.

Changes to Editor

Unsaved changes are now discarded when you close an editor. This means that a model is reloaded in its previous version if you close an editor without saving it. This makes the editor behave more like any other editor.

Changes in Code Generation

We have removed the discovery protocol from the code generator, so Sun SPOTs, for instance, will not find each other by default. Instead, an explicit block for discovery must be used.

Improvements:

• The Arctis view does not block anymore when loading Arctis models.


• Guards may also check if the data token is 'null', or refer to local variables.


• Switching pages in the editor does not cause building blocks to be marked as update when nothing has changed.
  

Bug fixes:

• Sun SPOT projects do not refer to Java SE 1.5 code anymore.

For Mac users:

Eclipse 3.5 runs on Macs, recommended with Java 1.5. We tried also Java 6 and experienced crashes. So, we recommend sticking to Java 1.5.

Arctis 1.0.0.M0043

• Overview Page for building blocks.Add descriptions, tags, author, and more. The information is saved in an additional file for each building block, stored in folder ".descriptions".
  



• Guards are now easier to set via the context menu on an activity edge. They may also refer to boolean methods of the corresponding partition that have no parameter.



• FIXED: an inspector that reported missing data flows after (correct) merge nodes.

Arctis 1.0.0.M0041

Internal improvements.