The struggle of making an EPUB on the Mac

EPUB (Electronic PUBlication) is an e-book standard by the International Digital Publishing Forum (IDPF).  Most significantly, Apple and an increasing number of vendors have adopted it for their e-readers.

The latest version of the standard is 3.01, but be warned: it is not easy to understand.

In essence, an EPUB consists of web pages plus some files that tell the e-reader how the pages are organised:

• The file named mimetype contains the string application/epub+zip.
• The folder named META-INF contains the XML file container.inf with additional general info.
• XHTML (i.e., HTML conforming to the XML standard) documents contain all the text, with links to images and media objects.
• A file with extension opf (which stands for Open Packaging Format) defines how the various documents fit together.
• An XHTML document defines how the user can navigates through the e-book.

Once you have all your files in place, you zip them together, change the extension from zip to epub, and read them as an e-book on your iPad.  The IDPF provides a validator that lets you check your document.  If you have done everything right, you are rewarded with the following message:

My test.epub was a trivial e-book, but it literally took me hours before I could work out how to put it together on the Mac.

To zip a folder on the Mac is easy: all you need to do is select the folder and then click on the "Compress" entry of the "File menu".  But if you do so, the folder itself will be zipped and you don't want that.  You want a single zip file with the content of the folder, without the folder itself.  In my case, I had a folder called test containing the file mimetype, the folder META-INF, and the folder EPUB with the rest (you can name most of the files as you like).

The Mac OS is Unix-based.  As such, it includes the almost universally present zip command.  But it took me a while to make my test.zip (then renamed test.epub) that would pass IDPF's validator.  After attaching to the test folder where all the e-book files were, I typed the following commands:

Giulios-Mac:test giulio$ zip test -X -0 mimetype
  adding: mimetype (stored 0%)
This first command created the file test.zip containing mimetype and nothing else.  The -X option ensures that no attributes are added to the file and -0 that the file remains uncompressed.  In this way, you satisfy the EPUB standard that mimetype be the first file in the package, naked, and uncompressed.  If you zip everything at the same time or without the options, the validator will fail.

Giulios-Mac:test giulio$ zip -r test * -u -n zip
  adding: EPUB/ (stored 0%)
  adding: EPUB/.DS_Store (deflated 95%)
  adding: EPUB/main.html (deflated 79%)
  adding: EPUB/nav.html (deflated 39%)
  adding: EPUB/package.opf (deflated 51%)
  adding: EPUB/util/ (stored 0%)
  adding: EPUB/util/ebook.css (deflated 71%)
  adding: META-INF/ (stored 0%)
  adding: META-INF/container.xml (deflated 34%)
This second command adds to test.zip the rest of the e-book (identified by the asterisk).  The -u option specifies that it is an update, and -n zip excludes from the compression the files with extension zip (necessary because test.zip is inside test/).

As you can see, my e-book only included one XHTML document (main.html) and a style sheet (ebook.css), with no images.  I have named my XHTML files with the extension HTML because I found it easier to work with and extensions don't matter.  Also notice that the folder EPUB/ contains a file named .DS_Store.  Mac OS freely sprinkles these files all over the place to store folder properties.  They are a hidden nuisance that causes problems whenever you access Mac folders outside the Mac universe.  But you can remove them with the following command:

Giulios-Mac:test giulio$ find . -name ".DS_Store" -depth -exec zip test -d {} \;
deleting: EPUB/.DS_Store
It searches the current folder and all subfolders for files named .DS_Store.  Whenever it finds one, it passes its location on to the zip command that removes it from test.zip.

Finally, the following command showed that all .DS_Store files had been removed:

Giulios-Mac:test giulio$ zipinfo test.zip
Archive:  test.zip   3176 bytes   9 files
-rwxr-xr-x  3.0 unx       20 b- stor 30-Jul-14 11:29 mimetype
drwxr-xr-x  3.0 unx        0 bx stor 30-Jul-14 16:47 EPUB/
-rwxr-xr-x  3.0 unx     1694 tx defN 30-Jul-14 15:03 EPUB/main.html
-rwxr-xr-x  3.0 unx      461 tx defN 30-Jul-14 15:05 EPUB/nav.html
-rwxr-xr-x  3.0 unx      836 tx defN 30-Jul-14 16:03 EPUB/package.opf
drwxr-xr-x  3.0 unx        0 bx stor 30-Jul-14 14:02 EPUB/util/
-rwxr-xr-x  3.0 unx     1996 tx defN 30-Jul-14 15:57 EPUB/util/ebook.css
drwxr-xr-x  3.0 unx        0 bx stor 30-Jul-14 11:29 META-INF/
-rwxr-xr-x  3.0 unx      259 tx defN 30-Jul-14 14:54 META-INF/container.xml
9 files, 5266 bytes uncompressed, 1822 bytes compressed:  65.4%

I tried to remove the bloody .DS_Store files before zipping, but without success.  I resorted to removing them from the zip file out of desperation, but it works just fine.

Converting UTF-8 to Unicode

To be stored digitally, each character of a piece of text is encoded into a particular bit pattern.

For exampe, according to the ASCII (American Standard Code for Information Interchange) standard, which has been around for half a century, the letter 'A' is encoded with the 7 bits 1000001₂ or, in hexadecimal notation, 41₁₆, which I prefer to write with the Java/C syntax: 0x41.  With 7 bits, only 128 patterns can be encoded (i.e., 2⁷), just enough for plain Latin characters, numbers, and a few special symbols.

Over the past couple of decades, a different type of encoding called UTF-8, based on a variable number of bytes, has established itself as the most common encoding used in HTML pages.

Often, UTF-8 is confused with Unicode, but while UTF-8 is a way of encoding characters, Unicode is a character set.  That is, a list of characters.  This means that the same Unicode character can be encoded in UTF-8, UTF-16, ISO-8859, and other formats.  You will find that most people on the Internet refer to Unicode as an encoding.  Now you know that they are not completely correct, although, to be fair, the distinction is usually irrelevant.

The Wikipedia pages on Unicode and UTF-8 are very informative.  Therefore, I don't want to repeat them here.  But I would like to show you a couple of examples taken from the UTF-8 encoding table and Unicode characters.

The charcter 'A', which was encoded as 0x41 in ASCII, is character U+0041 in Unicode and is encoded as 0x41 in UTF-8.  "Wait a minute", you might say, "what's a point of all the fuss if the number 0x41 stays the same everywhere?"

The answer is simple: the ASCII and UTF-8 encodings for all Unicode characters from U+0000 to U+007F are identical.  This makes sense for back compatibility.  But while ASCII only encodes 128 characters, UTF can encode all many thousands of Unicode characters.  To see the differences, you have go beyond U+007F.

For example, U+00A2, the cent sign '¢', which doesn't exist in ASCII, is encoded as 0xC2A2 in UTF-8.  Note that U+C2A2 is a valid Unicode character, but it has nothing to do with the 0xC2A2 UTF-8.  Don't get confused!  U+C2A2 is the character '슢' (a syllable of the Korean alphabet that, according to Google Translate, is called Syup...).  This is the first hint at why we might need to convert UTF-8 to Unicode although Unicode is not an encoding!

The problem arises when you want to work in Java with text that you have 'grabbed' from a web page: the web page is encoded in UTF-8, while Java strings (i.e., objects of type java.lang.String) consist of Unicode characters.  If you grab from the Web a piece of text, store it into a Java string, and display it, only the "ASCII-like" characters are displayed correctly.

For example, the Wikipedia page about North Africa contains "Mizrāḥîm", but if you display it without any conversion, you get "MizrƒÅ·∏•√Æm".

In the rest of this article, I will explain how you can correctly store into a Java string text grabbed from the Web.  There will perhaps/probably be better ways to do it, but my way works.  If you find a better algorithm and would like to share it, I would welcome it.

To help you understand my code, before I show it to you, I would like you to observe that when you match Unicode code points (that's how the U+hexbytes codes are called) and UTF-8 codes, there are discontinuities.  For example, U+007F is encoded in UTF-8 as UTF-8 0x007F, but U+0080 (the following character) corresponds in UTF-8 to 0xC280.  Another example of discontinuity: while U+00BF corresponds to 0xC2BF, U+00C0 corresponds to 0xC380.

One last thing: all bytes of UTF-8, with the exception of the first 128 (used for the good old ASCII codes), have the most significant bit set.  For example, the cent sign is encoded as 0xC2A2, which in binary is 11000010₂ and 10100010₂.
Here is how you can read a web page into a Java string:

    final int     BUF_SIZE = 5000;
    URL           url = new URL("http://en.wikipedia.org/wiki/North_Africa");
    URLConnection con = url.openConnection();
    InputStream   resp = con.getInputStream();
    byte[]        b = new byte[BUF_SIZE];
    int n = 0;
    s = "";
    do {
      n = resp.read(b);
      if (n > 0) s += new String(b, 0, n);
      }
    resp.close();

Pretty straightforward.  But if you do so, when you display the string, all multi-byte UTF-8 characters will show up as rubbish.  Here is how I fixed it:



  final int     BUF_SIZE = 5000;
  URL           url = new URL("http://en.wikipedia.org/wiki/North_Africa");
  URLConnection con = url.openConnection();
  InputStream   resp = con.getInputStream();
  byte[]        b = new byte[BUF_SIZE];
  int n = 0;
  s = "";
  do {
    n = resp.read(b);
    if (n > 0) s += new String(b, 0, n);
    }
  resp.close();

Pretty straightforward.  But if you do so, when you display the string, all multi-byte UTF-8 characters will show up as rubbish.  Here is how I fixed it:

  final int     BUF_SIZE = 5000;
  URL           url = new URL("http://en.wikipedia.org/wiki/North_Africa");
  URLConnection con = url.openConnection();
  InputStream   resp = con.getInputStream();
  byte[]        b = new byte[BUF_SIZE];
  final int[]   uniBases = {-1, 0, 0x80, 0x800, 0x10000};

  int n = 0;
  int[] utf = new int[4];
  int nUtf = 0;
  int kUtf = 0;
  int kar = 0;
  s = "";
  do {
    n = resp.read(b);
    if (n > 0) {
      i1 = -1;
      for (int i = 0; i < n; i++) {
        if (b[i] < 0) {
          kar = b[i];
          kar &= 0xFF;
          kUtf++;
          if (kUtf == 1) {
            if (kar >= 0xF0) {
              nUtf = 4;
              utf[0] = kar - 0xF0;
              }
            else if (kar >= 0xE0) {
              nUtf = 3;
              utf[0] = kar - 0xE0;
              }
            else {
              nUtf = 2;
              utf[0] = kar - 0xC2;
              }
            i1++;
            if (i > 0) s += new String(b, i1, i - i1);
            }
          else {
            utf[kUtf - 1] = kar - 0x80;
            if (kUtf == nUtf) {
              kar = uniBases[nUtf] + utf[nUtf - 1] + (utf[nUtf - 2] << 6);
              if (nUtf == 3) {
                if (utf[0] > 0) kar += ((64 - 0x20) << 6) + ((utf[0] - 1) << 12);
                }
              else if (nUtf == 4) {
                kar += utf[1] << 12;
                if (utf[0] > 0) kar += ((64 - 0x10) << 12) + ((utf[0] - 1) << 18);
                }
              s += (char)kar;

              // Prepare for the next UTF multi-byte code
              kUtf = 0;
              nUtf = 0;
              i1 = i;
              }
            }
          } // if (b[i] ..
        } // for (int i..

      // Save the remaining characters if any
      if (kUtf == 0) {
        i1++;
        if (i1 < n) s += new String(b, i1, n - i1);
        }
      } // if (n > 0..
    } while (n > 0);
  resp.close();

Clearly, I only need to process the incoming bytes that have the most significant bit set (i.e., those for which b[i] < 0).  First of all, I store the byte into an integer, so that I can work more comfortably with it.  When I encounter the first of these "non-ASCII" bytes (i.e., when kUtf == 1), I check its value to determine how many bytes the UTF-8 code requires (four, three, or two).  This tells me how many bytes I still have to collect before I can determine the corresponding Unicode character.

I accumulate the bytes into the utf integer array.  While I do so, I also do some pre-processing to remove the discontinuities.  When I have all the necessary bytes, I just shift them appropriately into the variable kar to form the Unicode character, which I then store into the Java string.

Frequency of family names

In five previous articles I talked about power-law distributions. I don’t know why I am so fond of them, but I do. Perhaps because I find them intriguing.

But while in all previous occasions I used power-laws to fit distributions related to networks, in this case I use them in connection with the frequency of family names. I looked up the frequencies of the most common family names in Italy, USA, Germany, and France (I also wanted to find Australia, but I didn’t find anything suitable). Then, I binned the frequency in doubling intervals, so that they would appear uniform in a logarithmic scale, and plotted them with Excel. Here is what I got:

As you can see, France, with an index of 1.8383, shows the steepest slope, followed by Italy with 1.7241, USA with 1.3593, and Germany with 1.3166.

What does it mean? I don’t know. The slopes are quite close to each other, but those of countries with Latin-derived languages (France and Italy, 1.8 and 1.7) are steeper than those where Anglo-Saxon languages are spoken (USA and Germany, 1.4 and 1.3). Is this significant or is it only a coincidence?

I should do the same for Spanish, Portuguese, Rumanian (all Latin languages), and Dutch, Danish, and Swedish (all Anglo-Saxon).

And what about Slavonian languages like Russian, etc.?

Also, I had 4991 names for Italy, 2128 for Germany, 1818 for France, and 961 for USA. It would be interesting to see how sensitive the slopes are to the size of the samples.

These lists of names are probably derived from census data. It is inevitable that they will include foreign names in addition to the domestic ones. Has that a significant effect? In any case, America is a melting pot of immigrants from all over the world. How many American family names are actually of Anglo-Saxon origin?

In case you are curious, in my previous examples, the indices were 1.526 (Network of Feedbacks on eBay), 0.7262 (The small world of this blog), 1.1685 (More on visitors to this blog), and 1.2507 (A real small-world network #2).

I also had a further article on small-world networks but without power-law distributions (Small-world networks (or not?)).

Mac X error code -8084

Since when I tried out the very first Macintosh, in 1984, Apple has always impressed me with the quality and the cleverness of its products. But yesterday, while I was backing up to a new flash key my Firefox profile, I got the following error alert (the grey highlight is mine):

In itself, to get a cryptic error message was not a big deal. It only meant that a check had caught a very unusual error condition for which no explicit message had been created. I did what I always do when confronted with something unknown: I copied the error message into the clipboard and pasted it in Google’s search field.

It turns out the nowhere is error code -8084 to be found. Apple in 1998 published a list of errors, but it stops at -5553 and is pre-system X.

I discovered that the problem disappeared after quitting Firefox. The most logical explanation is that Firefox had opened a file with an exclusive lock, thereby preventing the system from reading it.

But it is a disappointment that Apple no longer publishes a detailed list of errors, even if it might be partially obsolete as soon as it is written.

JSP, JSF and Tomcat Web Development

Apress of Berkeley (CA) has released the second edition of my book Beginning JSP, JSF and Tomcat Java Web Development.

The first edition of this book was released in November 2007.

Some years later, Apress asked me whether I would have liked to write a second edition of the book.  My reply was that not enough had changed to warrant an update.

Then, in early 2012, they asked me again. In the meanwhile, JSF had added three new libraries of elements and Java 7 SE had been released.  Michael Sekler, who had contributed to the first edition, agreed that I would go alone with the second edition.

I said yes.

It took me five months to change the structure of the first edition, update and add functionality and examples, etc., but it was worthwhile.

You might be wondering why it took so long.  After all, most of the material for the second edition came from the first one, right?  Not really. The problem with writing computer books is that you cannot simply write your stuff and be done with it. You have to write examples for most of what you say, and this adds a whole new dimension to writing. You have to write the examples in the tightest possible way, because thousands of smart people will pore over them.  No slacking off in either format or content. Not even one superfluous or missing tab.

And then, once you have designed and written your examples, you have to test them in the most thorough way.  This also applies to the examples you have from a previous edition.  You see, in computing everything keeps changing. Therefore, one example that was working flawlessly a couple of years ago, even if it doesn't fail (thanks to back compatibility), it will generate a lot of warning
messages during compilation. And a professional developer doesn't want his/her code even to generate a single warning!

For web applications, you have to test your examples with all major web browsers (Internet Explorer, Google Chrome, Firefox, and Opera).  This often leads to changes that have to be retested again from scratch.

Once you are happy with your examples, you need to integrate them into the text of the book and explain them in enough detail for the reader to make full sense of them.  And sometimes the lines of code don't fit into the printed page...

And don't think that the work is done once you send the chapter off to the publisher, because technical and scientific books are different from novels and most non-fiction books: before going through copy-edit, they are technically reviewed.  And although if you have been exemplary with your coding, debugging, and documenting, the TR (Technical Reviewer) might come up with points you had not considered, or points you had considered and discarded without mentioning them in the chapter.  Even if you avoid having to rework the examples, you will have at the very least to explain your choices...

One of the readers of the first edition complained that it contained not enough material on JSF. In this second edition I did something about it: in the first edition, I had devoted to JSF a chapter plus a quick-reference appendix; in the new edition, I dropped the quick reference and added a second chapter to the main body of the book. By doing so, I added quite a bit of practical information on JSF, because much of the quick reference appendix consisted of a list of elements that you can already find explained in several web sites.

Another complaint about the first edition was that it included too many appendices and too much extraneous material. Well, there were as many appendices as chapters! I had done it for two main reasons: I wanted to keep the main body of the book uncluttered but I still wanted to provide information on everything needed to write a dynamic web page. The resulting table of contents was as follows:

CHAPTER 1	Introducing JavaServer Pages and Tomcat
CHAPTER 2	JSP Explained
CHAPTER 3	The Web Page
CHAPTER 4	Databases
CHAPTER 5	At Face Value (JSF Primer)
CHAPTER 6	Communicating with XML
CHAPTER 7	Tomcat 6
CHAPTER 8	Eshop
APPENDIX A	Installing Everything
APPENDIX B	HTML Characters
APPENDIX C	HTML Reference
APPENDIX D	JSP Reference
APPENDIX E	SQL Quick Reference
APPENDIX F	JSF Quick Reference
APPENDIX G	Eclipse
APPENDIX H	Abbreviations and Acronyms

And here is the new table of contents:

CHAPTER 1	Introducing JSP and Tomcat
CHAPTER 2	JSP Elements
CHAPTER 3	JSP Application Architectures
CHAPTER 4	JSP in Action
CHAPTER 5	XML and JSP
CHAPTER 6	JSP and Databases
CHAPTER 7	JSF 2.2
CHAPTER 8	JSF and eshop
CHAPTER 9	Tomcat 7
CHAPTER 10	Eshop
APPENDIX A	The Web Page
APPENDIX B	SQL
APPENDIX C	Abbreviations and Acronyms

I eliminated the appendices on JSP, JSF, and Eclipse by merging their contents into the main body of the book. Then, I made the appendix on package installation disappear by explaining how to install all necessary packages as they became necessary. Finally, I dropped the appendix on HTML characters and told everything I wanted to say about HTML and SQL in the two remaining appendices. The result is a much better book in which the chapters are clearly focussed and that you can read with less flipping forth and back.

What are you waiting for? Buy it!

My Book in Chinese

For a couple of years my attempts to obtain a copy of the Chinese version of my book "Beginning JSP,JSF, and Tomcat Web Development"  has been completely unsuccessful.

A few days ago, I decided I had to find a way. It took me some inventive "googling" to find the name of the publisher, but I finally found it: product.china-pub.com/195967.

I discovered that the Chinese edition only became available in September 2009, almost two years after the original.

Here is an image of the front cover:

It costs AUD 9.00, much less than the original. I expected that.

Thanks to Google Translate, I was able to send a message to the publisher via the contact page on their website. I quickly received a reply (in Chinese). They told me that I have to buy it through their website and that they only ship domestically.

I sent another email. I cannot give up so quickly, can I?

The book was translated by Shi Xiaohui and Yuan Yong Kay and I believe I have found them. I send them emails and asked them whether they can halp me in getting a copy of the book. But, to be on the safe side, I also send a message to three more people named Shi Xiaohui, two of whom are on FaceBook.

I know: it's desperate...

I just discovered that I can buy the book from Biblio. But it would cost me AUD84. MMmmm... Quite a markup from the AUD9 dollars the Chinese pay domestically...

Java - Formatting a Sudoku for the Web

I just wrote a small method in Java that somebody might find useful. It converts a Sudoku string into HTML.

Arrays of Functions in Java

A couple of months ago, shortly after publishing the book Sudoku Programming (also see the post in this blog), I asked myself whether I should have written the programs in Java instead of classic C.

I had chosen C because I thought it would be easier for non-programmers to deal with a procedural language rather than with Object Oriented programming, with its class inheritance and operator overloading. But, looking at the number of functions I needed for the C implementation, I began thinking that in Jva the implementation would probably have been simpler. I simply had to re-develop Solver and Generator in Java. I simply had to do it.

One of the first problems I encountered was how to implement in Java an array of function pointers.

Sudoku Programming

I have finally completed my book “Sudoku Programming”.

The purpose of this book is to teach you how to write computer programs to solve and generate Sudoku puzzles. If you love Sudoku and have some knowledge of computer programming, you will have no problem in understanding the code of my Sudoku Solver and Sudoku Generator.

GLUT in C with Eclipse on the Mac

For the past couple of months, for my book on Sudoku, I have been writing C programs with Eclipse running under Mac OS.

Sudoku - A Handsome Samurai

I have almost completed my book Sudoku Programming (if I have ever seen a plug...) about how to write C applications that can solve and generate Sudokus. As part of it, I have decided to explain how to generate Samurai Sudokus. I had noticed that they often have the shared boxes completely empty and wanted to do better than that. I am very happy with the result, and would like to share it with you. Here it is:

I can generate as many as I like and not necessarily fully symmetrical, even if I think that they are just beautiful. Each one of the five puzzles I used to ‘assemble’ the Samurai requires some non-trivial strategies like Y-wing, XY-chain, and X-wing. The presence of the intersections might/should reduce the overall difficulty of the puzzle, but I still expect it to be reasonably (whatever that means) difficult.

Obviously, I have got the solution, but you don’t expect me to give it to you, do you?

Fortran and Eclipse on the Mac - Addendum

This is about updating Eclipse, PTP, and the Fortran compiler to their latest versions. Beth Tibbitts of the Eclipse Parallel Tools Platform (http://eclipse.org/ptp) told me how to do it via the Photran Information mailing list (photran[a t]eclipse.org).

Fortran and Eclipse on the Mac

In this post, I describe how I installed a Fortran compiler within Eclipse on my 64-bit Macintosh running the Snow Leopard system (OS X 10.6.5).

A programmer's Taboo

This post is about GOTOs.

Sudoku - Programming the XY-chain strategy

XY-chain is a generalisation of Y-wing. Essentially, instead of looking for a chain of three pairs, you look for longer chains in which the intersection cell of the Y-wing is expanded to a chain. The chain can be surprisingly long (one day, I might try to find out how long...), as shown in the following examples (only the relevant cells are shown).

Sudoku - Programming the Y-wing strategy

On the web there are many explanations of the Y-wing strategy, but none seems to go to the core of the issue. The only clear statement I found was that Y-wing doesn’t solve cells, but only eliminates possible candidates.

Strategy

Look for cells that contain only two candidates each. Among those cells, look for three cells that satisfy the following two conditions:

1. The arrangement of candidates in the cells is AB, AC, and BC. That is, no two cells have the same pair of candidates.

2. The cells are in two intersecting groups. This is equivalent to say that the two wing cells cannot share any group and can only happen in two ways: row+column (one of the cells shares the row with one of the other two cells and the column with the third one) and line+square, where ‘line’ stands for either ‘column’ or ‘row’ (one of the cells shares the line (row or column) with one of the other two cells and the square with the third one).

Sudoku - Programming the rectangle strategy

Every now and then I like to solve a sudoku puzzle. There are three things that interest me in sudoku: how to measure the difficulty of puzzles, how to write a program to solve puzzles, and how to write a program to create puzzles.

A program able to create puzzles must first of all be able to solve them, and to grade puzzles it is necessary to have a large number of solved puzzles. Therefore, the first step is to write a sudoku solver. There are many around, but for me part of the fun is to write the program. Years ago, I already wrote at least two sudoku-solving programs in Java. They were OO programs, but I was never particularly happy with the implementation. For this latest attempt, I have decided to ditch OO and use plain old “C” as a programming language.

In this post, I will describe a strategy that I call ‘rectangle’. It is sometimes called ‘hollow rectangle’ (you will later understand why). I intend to describe the strategy and then provide some development notes. To display the examples, I shall use snapshots of the program “Sudoku Training Software 1.1”, which runs under Windows. You can freely download it by clicking here. This is the first program I found on the Web for generating the snapshots. I use it only for that and I have no idea whether its other functions are good or bad. If you would like to suggest some other application, perhaps for the Mac, please tell me.

SW processes

At the end of 1998 I became Software Engineering Process Group Leader of the Swiss branch of a large multinational group.  It was my responsibility to ensure that software was developed in accordance with the corporate standard processes.  Some of the developers had very little knowledge of Software Process Improvement (SPI).  To “break them in”, I developed “ab initio” presentations with some basic SPI concepts explained in very simple terms.  I just discovered some of the slides in an almost forgotten folder and, given the fact that:
1.    My presentations were never officially registered in the corporate archives;
2.    the business division I was attached to no longer exists;
3.    more than ten years have passed;
I believe I can share them with you without infringing any copyright.

OO - UML Behavior Diagrams

This is the last post on Object-Oriented Technology. I know, there is so much that remains unsaid... Perhaps one day I’ll write more about it. But don’t hold your breath!

Behavior Diagrams

There are six different types of behaviour diagrams. They are: activity diagrams, state machine diagrams, use case diagrams, communication diagrams, interaction overview diagrams, sequence diagrams, and UML timing diagrams. The last four are also collectively called interaction diagrams because they concentrate on control and data flow among the system components.

OO - UML Structure Diagrams

In the previous post, I described a basic method suitable for designing simple OO applications. Obviously, as the applications grow in complexity and the teams grow in size, making lists of properties and methods quickly becomes insufficient to support the development process.

A widely used (and very powerful) software development process is the Unified Process, of which IBM's RUP (Rational Unified Process) is currently the best example. But describing RUP would be too much.

What I can do is to introduce you to a formalised and standardised way of describing OO systems, suitable for applications of any complexity and with all possible development processes. This is the Unified Modeling⁽¹⁾ Language (UML).