jastram.de Blog - Software

Guess how much Software there is in a Car

micky@alum.mit.edu (Michael Jastram) — Tue, 02 Mar 2010 21:42:33 -0500

Did you know that a third of the cost of a plane goes towards the fuselage, a third towards the engines, and a third towards software? It's getting there for cars, too. Here is a great article that is full of interesting trivia.

Running Rodin 1.1 with Ubuntu 9.10

micky@alum.mit.edu (Michael Jastram) — Fri, 06 Nov 2009 23:30:52 -0500

I had a few issues getting Rodin 1.1 to work properly after Updating Ubuntu to 9.10. The main issue is the HTML-Viewer that Eclipse uses. It wraps Firefox/xulrunner in an SWT-Control. Unfortunately, Firefox 3.5 (xulrunner 1.9.1) is incompatible with Eclipse 3.4, on which Rodin is based.

To work around this problem, you need to install xulrunner 1.9.0. I installed it locally at ~/opt/xulrunner-1.9.0.15

Next, you need to edit your rodin.ini (in the Rodin installation directory) and add the following line:

-Dorg.eclipse.swt.browser.XULRunnerPath=~/opt/xulrunner-1.9.0.15

That's it! This also works for running Eclipse 3.4 (in that case, you have to edit eclipse.ini).

Good luck!

Building a GWT app that is an Eclipse Plug-In

micky@alum.mit.edu (Michael Jastram) — Wed, 23 Sep 2009 11:28:03 -0400

For my own reference:

Create a new GWT-Project
Give it a standard Plug-In name (e.g. de.jastram.gwtexample)
Give the Project the Plug-In Nature (Right-click on Project > Configure > Convert to Plug-in Projects...)
Add Dependency to de.jastram.jettyrunner
Add Extension de.jastram.jettyrunner.warrunner
Add a war-element
That's it - don't forget to compile.

Using Map Requirements Modelling with the B-Method

micky@alum.mit.edu (Michael Jastram) — Mon, 27 Jul 2009 17:10:15 -0400

A colleague recommended a paper by Babar, Tosic and Potter, entitled "Aligning the Map Requirements Modelling with the B-method for Formal Software Development." There is certainly some overlap with my research, and it's interesting for me to see Problem Frames being integrated in the approach presented as well.

To be honest, I was a little disapointed. The most crucial part of the method is how to get from the requirements to the formal model. This is described in Sec. 3, but in such an informal manner that I don't see that much value. It shows that the methods are compatible, but little beyond that. I guess that's what the authors mean by "aligning" the methods.

Independent Verification and Validation of Software pays of (big time!)

micky@alum.mit.edu (Michael Jastram) — Tue, 21 Jul 2009 15:15:21 -0400

Just finished a paper Evaluating the effectiveness of independent verification andvalidation by Arthur et.al. What the authors state is not that surprising: independent verification and validation (V&V) efforts result in significantly better results than V&V done by the same team. This paper is interesting for a number of reasons:

The result stem from a controlled study of two identical projects, one realized with "normal" V&V (done by the team), the other using independent V&V
The independent V&V group detected significantly more critical faults (97 vs. 58). Why? The authors conclude that a new class of faults was identified by the IV&V group: "The IV&V team from Group 1 identified an additional class of critical faults not found by Group 2. More specifically, a substantial number of the critical faults reported by Group 1 stem from the detection and recording of ambiguous or unclear statements in the requirement specifications and design documents. (...) Group 1 reported 40 such faults. (...) Group 2 reported only one such fault."
Even though both projects were completed and considered a success, things during acceptance testing looked different. An independent acceptance test suite consisting of 36 tests was provided. The non-independent V&V group's software passed only 11 tests, while the independent V&V group's software passed 33.

Analyzing Natural Language Requirements - automatically?

micky@alum.mit.edu (Michael Jastram) — Sun, 14 Jun 2009 10:31:44 -0400

QuARS is a tool for analyzing Natural Language Requirements - although it would be an exaggeration to call it "automatic". The tool performs a morphological and syntactical analysis on plain text requirements and attempts to measure vagueness, subjectivity, weakness, and a few more.

Natural Language Requirements (NLRs) won't go away any time soon - that's why this kind of research makes a lot of sense. But it's unbelievable tricky to work with NLRs in an automated way. There are three main approaches to deal with the richness of natural languge:

Restrictive: constrain the form of the NLRs, e.g. using templates. Very convenient for the Requiremens Engineer, but not that nice for the stakeholder.

Inductive: This is mainly theory about writing styles, without going into detail on how to do things better.

Analytic: In this approach, we accept the NLRs, but provide feedback for fixing them. These have the hightest chance of adaption, because they are the least invasive. This is also the route of QuARS: Analyze the requirements and provide some feedback on how to improve them.

The biggest catch (in my opinion) is that many analyses require well-maintained dictionaries to be effective. I wanted to try the tool out, but they didn't provide a download link (or information about a commercial version, for that matter). I wrote them an email, if I get an answer, I'll update here.

Fluents: Events or Ticks?

micky@alum.mit.edu (Michael Jastram) — Tue, 09 Jun 2009 17:10:04 -0400

Imagine you have a system that can have a number of states, and "events" for state transitions. Fluents are then the constructs that help to reason about state transitions.

Here is an example inspired by [Queins et. al. 2000] that got picked up by [Letier 2005]: Assume that you have the task of building a light controller. By pushing a button, light is turned out and will switch off after some time. pushing the button when the light is on will reset the timer.

In this example, we may have the state variables light ∈ {on, off} and timer ∈ {0..n}. For now, the timer simply counts ticks. To set these state variables, we may have the events "pushButton", "switchOn", "switchOff", and "tick".

A Fluent is a proposition defined by a pair of sets of events. Events from the first set the fluent to true, the second to false, e.g.:

fluent LightOn = <switchOn, switchOff>

We can use the Fluent in temporal logic (e.g. LTL):

◻ (pushButton X LightOn)

The box means "always", and X means "next". So the above means "When pushing the button, next the fluent LightOn must be true".

Quite a bit is fishy here. For instance, what exactly does "next" mean? This is where Letier's contribution comes from: it could be the next event (which he calls asynchronous) or the next tick (which he calls synchronous). Also check out how restrictive the statement is in the asqnchronous case: It is not allowed to insert any events after pushButton, which would make refinement through stuttering impossible.

Aspects in Requirements Engineering

micky@alum.mit.edu (Michael Jastram) — Mon, 11 May 2009 22:34:00 -0400

After Aspect Oriented Programming (AOP) became popular, people started to think about Aspect Oriented Requirements Engineering (AORE). Kaindl published a neat article trying to figure out what exactly was meant by that. Amongst other things, he points out that there is confusion about whether "Aspect" is meant as a synonym for crosscutting concern or a solution to it (in his opinion, the first doesn't make much sense, and I agree; even the secion he doesn't like to much, but the term is established, and we're stuck with it now).

So Aspects solve cross-cutting concerns; in Software Development, typicall cross-cutting concerns are authorization, authentication, transaction management and more. Aspects provide a means to modularize these concerns.

Kaindl points out that almost always there is the hidden assumption that crosscutting concerns in software are the same as crosscutting concerns in requirements - but there is no foundation for that assumption! In fact, I would consider this a dangerous assumption.

So where does that leave us? Kaindl's point is that we should avoid falling into the trap that cross-cutting concerns in requirements are not necessarily the same as in software. But what are the cross-cutting concerns in requirements? That's a question that needs more research, but I am sure that it depends on the representation of the requirements, amongst other things. In a plain text specification, every entity (noun) or every action (verb) could be considered a cross-cutting concern. Consider a specification for a simple traffic light. Many requirements may refer to the same, traffic light in the specification. In the specification, the traffic light is a crosscutting concern. But not in the implementation - there, the traffic light may be one neatly capsuled object. Other representations don't have this problem. KAOS, for instance, explicitly models objects.

Food for thought.

The Hunt for Gollum

micky@alum.mit.edu (Michael Jastram) — Tue, 05 May 2009 23:08:31 -0400

This weekend an amazing film got released: The Hunt for Gollum, a side plot from the Lord of the Rings. Watch it for free online. This movie shows how the whole can be so much more than the sum of the parts, and that the Internet is an amazing enabler. Enjoy.

Falschdarstellung zu Spring im JavaMagazin?

micky@alum.mit.edu (Michael Jastram) — Sun, 23 Nov 2008 22:50:58 -0500

Laut Eberhard Wolff hat das aktuelle Editorial eine Anzahl sachlicher Fehler. Ich habe das ganze nicht geprüft, habe aber leider selbst feststellen müssen, dass Informationen im JavaMagazin nicht immer gut recherchiert sind.

Naval Architects

micky@alum.mit.edu (Michael Jastram) — Wed, 30 Jul 2008 10:11:45 -0400

Here is an interesting blog entry by Shane Paterson that explains why a Naval Architect is called Architect. I don't quite agree with his suggestion to change Solution Architect to Solution Engineer, but that is another question.

Requirements in Cocktail Recipes

micky@alum.mit.edu (Michael Jastram) — Fri, 25 Jul 2008 18:30:00 -0400

I have a friend who is a chemist. She once said that everybody can cook, but that chemists are the best cooks. Why? Because chemists can follow recipes really well - after all, that's what they do all day long. They mix precise amounts of chemicals in well-defined manner and perform processes on them by the book, to ensure repeatable results. Now, what does that have to do with requirements engineering?

Continue reading "Requirements in Cocktail Recipes"

10 ways to improve your code

micky@alum.mit.edu (Michael Jastram) — Mon, 10 Mar 2008 11:16:51 -0400

Nothing really new here, but Neil Ford created a list of 10 ways for writing better code. All of them have been mentioned before, but it never harms to remind ourselves of good practices.

New business models in a new world

micky@alum.mit.edu (Michael Jastram) — Thu, 21 Feb 2008 17:22:34 -0500

A very interesting read by Kevin Kelly regarding what's better than free. In my opinion, this is required reading by every tech start-up. Value must come from somewhere, and this article outlines eight value propositions that work in a world where everything can be copied for next to nothing.

Chandler closes down

micky@alum.mit.edu (Michael Jastram) — Sun, 27 Jan 2008 21:29:09 -0500

Mich Karpor, creator of Lotus 1-2-3 and founder of OSAF finally pulled out the Chandler project, an open source development of a new Personal Information Manager, after six years. The project made some headlines when it started and recently again after the publishing of the book Dreaming in Code.

I saw Kapor once at MIT, where he gave a guest lecture, and I value his enthusiasm. It's a shame the project folded.