Model-based software development inevitably involves dealing with incomplete information. Yet, MDE methodologies rarely, if ever, address uncertainty in a systematic way. Drawing inspiration from the field of behavioural modeling, we propose to use partial models as first-class development artifacts to abstract, reason with, visualize and manipulate sets of possible alternative models. Aiming to set up a research agenda for a systematic and robust treatment of uncertainty in MDE, we discuss how uncertainty can be captured by partial models, and how these models can be validated and correctly refined.

Slides to follow, as soon as I prepare them.  :)

Before anything, check that you have Inkscape v0.48 or higher installed. Also, I’ve tried this using PDFLaTeX (not the dvi+ps LaTeX compilation path).

Whenever I’m working on a LaTeX project, I usually keep all my images in a separate images directory, so all the paths reflect that. Adjust to your needs.

The definitive guide is the InkscapePDFLaTeX.pdf document of the svg-inkscape CTAN page.

To keep things simple with when it comes to the size of figures with respect to the size of text, draw your SVG image using the same font size as your working LaTeX project. In my case, it was 10pt.

Save your image, eg as “~/images/myTestImage.svg”. In addition, in Inkscape go to the option File -> Save a Copy and chose PDF as your output format in the same folder as the SVG. In the PDF options popup that comes right after select the options:

• PDF+LaTeX: Omit text in PDF and create LaTeX file
• Export area is drawing

Save and go to your LaTeX document.

The preamble of your LaTeX  document should contain this command:

\newcommand{\includesvg}[1]{
\immediate\write18{inkscape -z -D –file=images/#1.svg
–export-pdf=images/#1.pdf –export-latex}
\input{images/#1.pdf_tex}
}

Also, make sure you add to the preamble the images path:
\graphicspath{{images/}}

Now go at the point in your document where you want your image to appear and add:
\begin{figure}
\centering
% \def\svgwidth{\columnwidth}
\includesvg{myTestImage}
\end{figure}
Note the commented out line. If you uncomment it, you can adjust the size of the shapes of your image. However, the size of the text remains the same. Without it, the image is imported with its own size and since you’ve used font size 10pt it should appear normal.

Finally, you need to enable the “write18″ feature of LaTeX, which enables it to run external programs (in our case, the headless inkscape). You do this by adding
-enable-write18
to the TeX command-line. You can either add it to your makefile or invoke it everytime. I prefer to use Kile as my LaTeX IDE and there you need to go to Settings -> Configure Kile -> Tools -> Build -> PDFLaTeX -> General -> Options and add it there. I found solace in adding it as the first of the arguments.

Compile and gaze at the awesomeness.

From now on, if you want to change your image, you do so in Inkscape, save the SVG normally (ctrl+S) and recompile the LaTeX document. That saves you the annoying extra step of exporting.

Note1: It so happens that as of April 12, 2011, the version of Inkscape on the CSLab servers is v0.47. So you’ll have to work on a local copy on your machine. In the case of my co-authoring team,  that’s no problem, because I’m in charge of the paper’s pictures! Moreover, the invocation of Inkscape whenever they try to compile the LaTeX document doesn’t cause them any problems, as Inkscape merely complains for the extra –export-latex command.

Note2: A more elegant solution would be to move the invocation of Inkscape to the makefile. I’ll do that sometime.

Here are some short hints on typesetting algorithms:

• Don’t overcomment your pseudo-code. If you feel that you need to comment too much, then you are probably doing something wrong: you should probably detail the inner workings of the algorithm in regular text rather than in the pseudo-code.
• Similarly, don’t regard pseudo-code as a low-level programming language: don’t pollute your algorithms with punctuation marks like semi- colons, which are necessary in C, C++ and Java, but not in pseudocode. Remember: your readers are not compilers.
• Always document what the algorithm receives as an input and what it returns as a solution. Don’t care to say in the \REQUIRE or in the \ENSURE commands how the algorithm does what it does. Put this in the regular text of your book/paper/lecture notes;
• If you feel that your pseudo-code is getting too big, just break it into sub- algorithms, perhaps abstracting some tasks. Your readers will probably thank you.

Of course, you should follow those hints with common sense. Well, anything should be done with common sense.

A very interesting Google Tech Talk. I kinda expected to see attributed graph grammars pop up when he started discussing the rule-based transformation approach.  I wander if a declarative approach could also work.

I found it at Jordi’s excellent modeling website.

PS. Slide 37 is like the best slide ever.