Several years I attempted to create a local, German photo-community page, a PHP and Web Design site and some other web pages. Why did I do that? Because I believed to understand something about how the pages should be designed. Maybe I was mistaken, but probably there is another important reason, that I was neglecting. Communities are not built around good-looking, convenient, user-friendly platforms, but much more around a unique idea, which I never had. There are hundreds of web-technology pages and journals, and many German local photo pages. And the fact that I know five web-interested people and fifteen hobby photographers seems to be not enough to maintain and fill the page.

I had an interesting discussion with Alex regarding the fact, if it is a good idea to create several, narrow-topic pages or one blog with all topics. My opinion was that a clear-addressed page will attract more people, than one page reporting about all subjects. I must concede that in theory I still believe that, but in practice it doesn’t work if you are the only person posting. And sorry to say that, but in the end I was the only one writing. In the same time, I already have a page on which I’m the only writer – this one.

A further reason of separating pages is the language of writing. I’m writing English and German (my Russian writing went never so far, that it would be not possible to write them in one of the already mentioned languages) and it seems that it is not a good idea to mix different languages on the same page. Bojidar gave me an advice to write English, since most people using Internet like I do, understand English. On the other hand, it seems stupid to write English for Germans living in the same German city, so my photo page was in German. Surprisingly, after I started to write this post (and decided to close the DigitalExperiement site), there is a new idea and justification for letting it online. I never finished the gallery section of the page and found out that this is probably the most important part. I’m posting my best photographs in different photo community sites, mostly for the reasons of getting feedback. In fact I don’t like any of the pages seriously, so I will re-post the best pictures on Digital Experiment someday. In fact I found at least two other people who are interested in putting their high-gloss pictures into the gallery. But as long as it is not ready, I just cleaned up the content and removed the unneeded content from the page.

An additional reason for creating pages, was my interest in small PHP projects. I’m a big fan of WordPress and Dokuwiki, so I spend a reasonable amount of time integrating these two systems. This included designing templates/themes which look the same on both platforms to allow for a seamless integration of the two systems into one web page. My TechJava Journal uses that, the Digital Experiment used it too. TechPHP was a kind of project home for all templates and plug-ins. In the end, WordPress 3 break the API completely and didn’t describe the login procedure in detail, so I didn’t want to reverse-engineer it again. Since the page was not hosted by me alone (but Alex participated in the project too), we decided to take the page offline.

The same will happen with TechLinux, a site produced to be an place to post about experiences in Linux administration and usage. It was never really useful, even if the page was a case study of how to program dynamic pages in PHP. It was a kind of own-written CMS with structure and content stored in the database.

Finally, I’m not taking all pages offline. I still host my high-school class homepage and the homepage of my first band. Probably, my most successful page is TechJava. I’m continuously posting on it and its Eclipse Category is aggregated on some important community sites. The official TLA+ Page is also doing well and become more and more attention by people interested in Temporal Logic of Action and PlusCal by Leslie Lamport. I decided to create some new content there about the history of TLA+. Since my employment at Holisticon AG I started to post on its blog. The blog is in German and discusses topics like software architecture, agile project management and other and I post regularly.

So, less is more on the web too…

• SANY – Syntax Analyser for TLA+ specifications
• TLC – A modelchecker / simulator for TLA+ specifications
• TLATeX – LaTeX typesetter for TLA+

The PCal Translator is not covered in this post and will be introduced in a separate post, together with PCal language.

SANY

SANY is a syntax analyser for the TLA+ language. The purpose of it is to check the syntax of the specifications (including some static semantics) and provide the errors to the user. As all of the TLA+ Tools currently available, SANY is a command line tool and reports the errors back to the console. In fact SANY is a front-end of the compiler (lexer, parser, semantic analyser). In order to invoke it call:

java -cp %TLA_CLASSPATH% tla2sany.SANY fowler.tla

SANY is currently the only official way to find out, if the specification complies to the rules of the TLA+ language. It is absolutely a non-trivial program, basically because of the complexity of the TLA+ grammar. Especially, the parts responsible for precedence-checking and level-checking are use complex algorithms.

TLATeX

As noticed by Peter, the language has a special notation, which could appear cryptic to someone who see them for the first time. The reason for this is pretty simple: TLA+ is a mathematical language and the ASCII version TLA+ is very close to LaTeX notation of the corresponding mathematical symbols. Everyone, who is aware of LaTeX can read and write TLA+ easily. For others, the ASCII specification can be translated into a TeX file and rendered to a DVI, PS or PDF. A piece of specification of the secret compartment ( download full TLA file), looks as follows rendered as PDF ( download as PDF).

The question of WYSIWYG editor support involves not only rendering of the symbols (that is the easiest part), but the input of these symbols by the user. Therefor, the ASCII version of TLA (we could also speak about ASCII encoding), which uses at least in certain areas know LaTeX-like encoding is a convenient way for editing specs. There are attempts to create WYSIWYG formula editors, which work pretty good, but the these have to be used with a mouse and the input speed is not comparable with the typing plain LaTeX.

The usage of TLATeX is simple. After the installation of TLA Tools, the TLATeX is invoked from the command line:

java -cp %TLA_CLASSPATH% tla2tex.TLA -shade fowler.tla

The tool produces a .tex file which can be included in the existing document. It also can be rendered directly if LaTeX is installed on machine.

TLC

TLC is a model checker for TLA+ specifications. It’s main purpose is to find bugs in specifications. For this purpose it creates the state-space described in the specification and checks the properties (safety and liveness). In contrast to SANY which is responsible for syntax and static semantics check TLC is checking the dynamic semantics of the specification. At this point I only want to mention, how TLC is invoked. I’ll cover some advanced TLC topics in the later posts:

java -cp %TLA_CLASSPATH% tlc2.TLC fowler.tla

In addition to the TLA file, containing the specification itself, TLC requires a CFG file, which describes the model, that has to be checked. This fact appears unusual to the TLA beginners, but is easy to clarify. The specification of the system is a description of systems behavior. To a given behavior, several models can be constructed. In addition, specifications can be combined resulting in bigger specifications. In the specification, there are no real differencies between actions: (Init, TypeInv, CloseDoor or Spec). Thus, the user has to specify which of these actions are actulally the parts to check.

(* ************************************ *)
(* Controller of the secret compartment *)
(* of Mrs. H, who loves secrets!        *)
(* Following the example of M. Fowler,  *)
(* which can be found at:               *)
(* http://martinfowler.com/             *)
(* ************************************ *)
------------- MODULE fowler --------------
(* ************************************ *)
(* Variables                            *)
(* ************************************ *)
VARIABLE
  state, \* the state for display, only
         \* to be compliant with  Fowler
  light, \* state of the light
  draw,  \* state of the draw
  panel, \* state of the secret panel
  door   \* state of the entry door

TypeInv ==
(* ************************************ *)
(* Type invariance                      *)
(* ************************************ *)
  /\ state \in { "idle",
                 "active",
                 "waitingForDraw",
                 "waitingForLight",
                 "unlockedPanel" }
  /\ light \in { "on", "off" }
  /\ draw \in { "opened", "closed" }
  /\ door \in { "locked", "unlocked"}
  /\ panel \in { "locked", "unlocked" }

Init ==
(* ************************************ *)
(* Initial state                        *)
(* ************************************ *)
  /\ state = "idle"
  /\ light = "off"
  /\ draw  = "closed"
  /\ door  = "unlocked"
  /\ panel = "locked"
------------------------------------------
(* ************************************ *)
(* Actions                              *)
(* Note that the state variable is not  *)
(* used for the determination of the    *)
(* actual state, but only for display.  *)
(* This shows that this variable        *)
(* is not required in TLA+              *)
(* ************************************ *)

CloseDoor ==
(* ************************************ *)
(* Closes the door, to activate         *)
(* ************************************ *)
  /\ door = "unlocked"
  /\ door' = "locked"
  /\ state' = "active"
  /\ UNCHANGED << panel, light, draw >>

LightOn ==
(* ************************************ *)
(* Switch on the light, if the draw is  *)
(* opened, this opens the secret panel  *)
(* ************************************ *)
  /\ light = "off"
  /\ light' = "on"
  /\ IF draw = "opened" THEN
       /\ state' = "unlockedPanel"
	   /\ panel' = "unlocked"
	   /\ door' = "locked"
	 ELSE
	   /\ state' = "waitingForDraw"
	   /\ UNCHANGED << panel, door >>
  /\ UNCHANGED << draw >>

OpenDraw ==
(* ************************************ *)
(* Open the draw, if the light is on,   *)
(* this opens the secret panel          *)
(* ************************************ *)
  /\ draw = "closed"
  /\ draw' = "opened"
  /\ IF light = "on" THEN
       /\ state' = "unlockedPanel"
	   /\ panel' = "unlocked"
	   /\ door' = "locked"
	 ELSE
	   /\ state' = "waitingForLight"
	   /\ UNCHANGED << panel, door >>
  /\ UNCHANGED << light >>

ClosePanel ==
(* ************************************ *)
(* Closes the secret panel and move the *)
(* system to initial state              *)
(* ************************************ *)
  /\ panel = "unlocked"
  /\ panel' = "locked"
  /\ light' = "off"
  /\ draw' = "closed"
  /\ door' = "unlocked"
  /\ state' = "idle"
------------------------------------------
Next ==
(* ************************************ *)
(* All possible actions                 *)
(* ***********************************  *)
  \/ CloseDoor
  \/ LightOn
  \/ OpenDraw
  \/ ClosePanel

Spec == Init /\ [][Next]_<< panel, light,
  draw, door, state >>

THEOREM Spec => []TypeInv

Inv ==
(* ************************************ *)
(* The panel is never unlocked          *)
(* by opened door                       *)
(* ************************************ *)
  \/ panel = "unlocked" => door = "locked"
  \/ door = "unlocked" => panel = "locked"
==========================================

In order to run a model checker, the configuration file fowler.cfg needs to be created. It says which part of the model is the specification, and what should be checked. In the example above, the specification action is called Spec and states, that if the Init action is executed, the Next action can always be executed by allowing stuttering steps by changing values of the variables panel, light, draw, door and state. The actual property we want to check is the fact, that the compartment is really safe, which means that the secret panel can be unlocked if and only if the door is closed. This is stated in the property Inv which has to be an invariant property of the system.

SPECIFICATION   Spec
INVARIANT       Inv

Running TLC on this specification, with configuration file provided above produced the following output:

TLC2 Version 2.01 of February 23, 2008
Model-checking
Parsing file fowler.tla
Semantic processing of module fowler
Finished computing initial states: 1 distinct state generated.
Model checking completed. No error has been found.
Estimates of the probability that TLC did not check all reachable states
because two distinct states had the same fingerprint:
calculated (optimistic):  2.927345865710862E-18
based on the actual fingerprints:  1.2569902552401487E-14
15 states generated, 9 distinct states found, 0 states left on queue.
The depth of the complete state graph search is 3.

This means, that it reached all states with very high probability and checked in every state the required property.
The compartment of Martin is safe! Modelchecked by TLC.

Since Prof. Dr. Vogt is going to retirement and leaves his position as head of the Institute of Telematics of Hamburg University of Technology a small farewell party has been organized. The most to prominent guests from the computer science community were Leslie Lamport and Manfred Broy. Leslie spoke about the benefits of usage of +CAL, a language for algorithm specification built on top of TLA+. Manfred spoke about requirements engineering and the utmost important of requirements for the quality of the software. The event has been finalized by a delicious buffet.

The pictures are available at http://www.ti5.tu-harburg.de/graphic/photos/symposium/