As an ArgoUML contributor I'm going to blog my activities here, so that they may draw interest by other developers or help other developers when doing tasks similar to what I've done. AND(!) the grand vision that makes an Argonaut what he is, TO THRIVE IN THE BIG DANGEROUS WORLD, TAKING THE Argo TO A GOOD SHORE ;-))

Monday, November 06, 2006

ArgoUML and OpenUsability

I found out about the OpenUsability initiative in one of the ThoughtWorks blogsJosh Evnin's– and immediately proposed it for ArgoUML. Linus finds this a good idea and I'm going to act now as a proxy between ArgoUML and OpenUsability.This is somewhat more work, but, due to one reason and another I'm getting much more sensitive to this whole usability issue and it is growing in importance in my internal priority queue.

One reason is due to my current work, where I'm working in the development of a planning tool for WDM networks. For historical reasons the usability wasn't a concern in the beginning and it continued to be so for a while (years) until the negative feedback from the users started hitting the development project. One of the issues is the lack of Undo\Redo capability, which is also a problem in ArgoUML.

Another reason is that I'm reaching a time in my professional life where I've been sufficiently exposed to good and nice to use user interfaces and bad ones to give this usability issue the importance it deserves. I now see and understand that usability isn't only about GUIs. Quite the contrary, usability may reveal itself in a command line interface, a library API and whatever is the interface to the users of some given software deliverable.

An example was shown to me just some minutes ago, when I tried to automate the build steps in the Windows shell. I have a batch file which fails to do what I ask and simply doesn't provide any help! That's a bad user interface and I just got hit... I tried to fix it by trial and error to quit and switch to the cygwin environment, where AFAIK these things work better.This is what usability is all about, helping our users to solve their problems in using our software.It is THAT important!

The root cause for some software to be bad to its users is lack of a user oriented attitude of the development project.I've found some of the signals of this to be:

  • The management doesn't use the software and its attitude is more oriented to fulfilling the contract and process than to actually help the users to fulfill their objectives.
  • The developers don't have a global concern for the usability of the application, being more preoccupied with their little small component than to the emerging consistency of the user interface of the application. [Frederick P. Brooks in his "The Mythical Man-Month" book, chapter 9, page 100 of the 20th anniversary edition, says Fostering a total-system, user-oriented attitude may well be the most important function of the programming manager.] You may check it by the way the application provides error information and the differences in behavior from one functional area to another.
  • The development process doesn't include steps where feedback is gathered from the users. They only get access to the software when the development project thinks it is finished or they get it sooner, but, with a whole list of disclaimers basically stating that if it gets out of the box and bites your head off bad luck for you. It doesn't include a polite message asking for feedback from users and how they can do it.
  • Direct contact between the development team and users of the software is discouraged, unless explicitly organized and carefully controlled by the management.
  • There is no access (or it is relatively hard to get it) to the bug and issues list. There are no users forums and no FAQ.

I think that one of the positive things of the agile manifesto is the focus on providing value to the users and fostering conversation and collaboration. I contrast this with the typical silo approach of the majority of the development projects in the industry, where there are a bunch of persons who are allowed to interact with the users. These screen out direct communication, not because it affects negatively the productivity of the persons developing the work, but, because it enables "better" control of the user/client interaction.

It isn't something that only the development side must work out, also it is common that the user side has the tendency to get inside info from informal communication channels and use it for finger pointing and contract revoking, so, this new old way of working requires maturity and good common sense from both sides.

Automating the svn update and build process of ArgoUML

As for the majority of persons working in open source projects I get to work only some 2 or 3 hours in ArgoUML at a time. When I start working I like to get up-to-date with the current trunk of ArgoUML and its projects. This is a process that takes normally about 20 minutes and includes:

  1. svn update of all checked out projects of ArgoUML
  2. build and run the tests of all relevant (for me) projects
  3. check the results and fix problems (this isn't needed normally :-))

The first and second steps are easy to automate, just create shell scripts that contains the individual updates and build commands.

<dir_for_co>\svnupdt.bat:

svn update argoeclipse
svn update argouml
svn update argouml-andromda
svn update argouml-classfile
svn update argouml-cpp
svn update argouml-csharp
svn update argouml-gen
svn update argouml-idl
svn update argouml-python

<dir_for_co>\build.bat [Note that this isn't working yet, help would be appreciated!]:

cd argouml\src_new
build package alltests
cd ..\..\argouml-cpp [fails here, this step isn't executed]
build tests
cd ..

Thursday, November 02, 2006

2006-11-02

I've finally been able to restart working in ArgoUML! The module is in the new Subversion repository, and I tried to follow the instructions to checkout with eclipse. It was after several failures that I got back to the good old command line and in 1:30 hours it was checkout (argouml and argouml-cpp) with my tigris user, built and unit tested.Here follows the steps:

<dir_for_co>>svn co --username USER --password PASS http://argouml.tigris.org/svn/argouml/trunk argouml
<dir_for_co>>svn co --username USER --password PASS http://argouml-cpp.tigris.org/svn/argouml-cpp/trunk argouml-cpp
<dir_for_co>>cd argouml\src_new
<dir_for_co>argouml\src_new>build package
<dir_for_co>argouml\src_new>cd ..\..\argouml-cpp
<dir_for_co>argouml-cpp\>ant tests

Then point your browser to file:///<dir_for_co>/argouml-cpp/build/tests/reports/html/index.html and check if all is well. Note that I had to use Ant directly, because there is something wrong for me in the way the BAT files are working.

Friday, October 06, 2006

On Algorithms

Almost after 4 months of silence its time to get back at taking notes about ArgoUML and my adventures in software development. I'll do a retrospective on what I've been doing another time. Currently I want to document one very interesting thing that is common knowledge, but, that have reveal to me again today. Don't optimize without having measurements before. Or stated in its full glory: Premature optimization is the root of all evil.

I was working in solving one of the Google Code Jam 2006 excercises. –If you are curious I was very unsuccessful in my attempt to solve this in the one hour they give you to solve. – It is the SquareCounting problem and I tried to solve it in Java, in a Test Driven Development way. After my failure to provide anything near a solution to the problem, I kept trying to solve it and I think that now I have a solution and I was making some simple efficiency measures to check what was the performance of my solution according to the Big O notation.

After having this setup and with 10 different measures, I started making a very simple change that I thought would bring immediate improvements. Alas, it made it worst by a factor of 3 for some cases! I'm very happy to have started measuring before any changes. So, now have a personal experience backing the idea that premature optimization is evil.

My solution doesn't use any linear algebra ideas, but, I think it should. The thing is, now I have the possibility to decide on the best based on actual measurements and detailed test cases. This kind of problem solving is proving to be fun.

Oh, forgot to show you the measurements. N is the number of elements in the square. Sol is the number of squares and the time in miliseconds for executing the tests 100.000 times. The results before the change:

NSolTime (ms)
44391
96593
62360
91422
10013843
90125672
16161297
25251766
36303156
42353625

And after the "improvements":

NSolTime (ms)
44265
96438
62281
91297
10012656
90127047
16161610
25253859
36306594
42358625

Tuesday, June 13, 2006

Design of htmled and improvement opportunities

So, how complicated do you think htmled might be? This simple 1000 liner program does very simple content extraction and transformation (see htmled, the handbook editor blog and publisher and htmled revisited – Handbook entries to blog posts automated). It doesn't leave the HTML format, no concurrency, no database and no distribution. So, if you're a Python developer you might simply look at the code.

But, as an ArgoUML developer and user, prior to start doing TDD on htmled, I made some simple diagrams which I kept up-to-date for documentation purposes. The following UML class diagram shows the basic data structure, with correspoding classes existing in htmled.py. The HbFile represents a Handbook file, using HbFileParser to parse the file into HbDailyEntries which by thenselves are composed of HbSubjectEntries. I normally load htmled in the Python shell, create HbFile(s) and then use a PostExtractor to extract Posts from the handbook files.

htmled classes

Picture 4 – htmled main classes diagram.

The complexity lies a bit in the PostExtractor and very much in the HbFileParser and its associated classes. Specifically, for parsing a handbook file I used the HTMLParser module contained in the Python standard library and the State design pattern I read about in Robert C. Martin's Agile Software Development book. For this you may check the UML state diagram I draw when trying to model the Finite State Machine for handbook file parsing – check the HbFileParsing class in htmled.

htmled Handbook File Parsing Finite State Machine

Picture 5 – htmled Handbook File Parsing Finite State Machine.

The use of the state pattern and HTMLParser for parsing the handbook files is definitelly better than a "reinvent the wheel" approach, but, I think it isn't the most appropriate way of solving this problem. I think that I should have tried to use ANTLR for parsing, creating an AST and then extracting the required info from there, e.g., DailyEntries. If I revisit this project again due to ambitions related to imroving its functionalities I might very well do just this as a warm-up!

Wednesday, May 03, 2006

Postmorten of htmled

I measured the recent work on htmled with Process Dashboard's PSP0. Since I want to continue evolving the project, I think I'll have a good opportunity to try to improve the effort estimations and the planning.

So, lets resume the results:

Time


PlanActualActual %
  Planning24
93
9.35%
  High-level Design0
0
0%
  High-level Design Review0
0
0%
  Detailed Design120
46
4.62%
  Detailed Design Review0
0
0%
  Code240
546
54.9%
  Code Review0
0
0%
  Compile24
8
0.8%
  Test48
275
27.6%
  Postmortem24
27
2.71%
    Total660
995
-------

Defects Injected


PlanActualActual %
  Planning0
1
5%
  High-level Design0
0
0%
  High-level Design Review0
0
0%
  Detailed Design0
5
25%
  Detailed Design Review0
0
0%
  Code0
9
45%
  Code Review0
0
0%
  Compile0
0
0%
  Test0
5
25%
  Postmortem0
0
0%
    Total0
20
-------

Defects Removed


PlanActualActual %
  Planning0
0
0%
  High-level Design0
0
0%
  High-level Design Review0
0
0%
  Detailed Design0
1
5.26%
  Detailed Design Review0
0
0%
  Code0
7
36.8%
  Code Review0
0
0%
  Compile0
1
5.26%
  Test0
10
52.6%
  Postmortem0
0
0%
    Total0
19
-------

More time and defects than I would expect and I knew the code basis and the requirements very well. I think that it is OK if I take into account the fact that I'm not very experienced with Python and that I had plenty of interruptions.

Tuesday, May 02, 2006

htmled ready for production use!

After a while working on this I think I will be able to make my blog update based on the current status of htmled. It processes correctly this Handbook file, being that I even found and corrected some errors in the HTML with it. As stated previously I'm using Test Driven Development (TDD) and using the Process Dashboard to track time and defects. It was fun, mainly because I used Python, TDD and knew very well the requirements ;-).

Mainly I hope it improves dramatically the readability of my blogging. I'm not following full commercial blogging rules, but, heck, I don't intend to earn money with this, just publicize properly my playground.

Monday, April 10, 2006

htmled – the work done up until now

In my very limited free time I've been working in htmled. It is a Python program that is being developed using test driven development (TDD), which currently is capable of parsing my Handbook files and fill HbDailyEntry and HbSubjectEntry objects. I have created also a PostExtractor which creates blogger posts out of a list of HbDailyEntries. It still doesn't convert the links correctly, but, that is the last step missing for it to be working.

To manage versions of htmled I'm using Subversion, which seams very versatile and simple to use. I'm also using the Process Dashboard scripts, to try to get a feeling on what this tool can make for me besides helping me track the time I use for my hobbies and work.

Monday, February 06, 2006

htmled revisited – Handbook entries to blog posts automated

I'm again revisiting my idea of developing automation for transforming content developed in my handbook into Argonaut's-life blog posts. The way I blog until now is seriously flawed, in that it does not follow the feeling that these entries are actualy made in the moment. This is the truth, with the catch that I will only put them in the blog when I'm online and in a batch way. It gives the wrong feeling to persons reading it and I must change this.

But, alas, to change it I must automate a bit and it is here that the problem begins. The high level requirements are identified here, although I'm now less ambitious and just want to automate the transformation of the content of my programmer's handbook entries into Argonaut's life posts.

Details of my handbook entries:

  • I write in a daily oriented way, always starting with H2 tag and with standard european date format – yyyy-mm-dd.
  • As stated previously the entries are written in a last in goes to the end manner.
  • The handbook is made of several HTML files, all in the same directory.
  • I also include several pictures that are stored in the handbook directory.

I would be happy if in a first step, the converter simply creates single posts out of the handbook entries. The end result could be a group of posts, structured around a directory tree of dates/posts. I may put the content by hand in the blog and the pictures in my website. One problem is the post title. Here I would choose to use H3 level tags. These are the normal heading level within the daily entries.

The automation makes also some formating that satisfies blogger requirements, such as one HTML post must be all within one line. It must fix my handbook intra-links into links that work in the blog, etc.

Friday, February 03, 2006

Executable List of Limitations

Another idea I had today is to put the List of Limitations of a program into the program. This would warn the user about some specific limitation only when he uses functionality that contains a limitation. I have done this with the C++ module reverse engineering part.

C++ module List of Limitations

I did this because it was a module I wanted to integrate, but, it has so many limitations that providing this possibility with warning users of the limitations would be too frustating for anyone than myself. But, it is a rather interesting way of explicitly warning users about something that could annoy them. Today I had the idea of inserting this for all limitations! It is something for the user like TODO and FIXME markups are for developer. With the advantage that he may turn off the LoL warnings after seeing them for the first time. This could be easy with the new technologies such as Aspect Oriented Programming and Attribute Oriented Programming (e.g., Java 5 Annotations).

The kind of user warning depends on the type of program, e.g., ArgoUML would present a warning message while a server application adds a warning sentence in the log. This is also a much better way to manage limitations than using LoL list within the change management tool or a document sent to the user / customer.

2006-02-03

I helped finding and fixing [Issue 3917] unit tests failing - default model not initialized. It is very good that ArgoUML has unit tests. Without them I think that release problems would increase a lot. Near release almost everyone who cares will be a bit stressed and the possibility for errors will increase. For this we have the automated unit tests, acting as a safety net.

I should state that ArgoUML developers don't do as much as they should test driven development and test driven bug fixing. This is a practice that isn't enforced by the leader and by the commit rules. But, given time it might be...

Now, imagine that it was. Imagine that commiting a change in the production code should be done with a companion test or at least should be covered by tests. How difficult it would be to verify and automate this? We would need to mark commits to repository as atomic, make a complete build with unit tests executed with coverage and check that the commit is according to the coverage criteria. The commit is rolled back if it is sub-standard, being the commiter warned about this by email.

This requires atomic commits, something CVS does not have, but, Subversion does. It requires integration between the tools used in this scenario: version control system and build tool; build tool and coverage tool; build tool and coverage tool results details related to a set of specific changes; build tool and email system; mapping between version control system user IDs and users details (i.e. email).

Looking into the above requirements, I think that almost everything is possible with open source tools. It would require heavy build knowledge and a dedicated server with rollback rights, but, it is certainly possible.

One problem is the dependencies between one commit and the following. One much more important problem is the total lack of human review in all this!

No, in the end I think this is a bad idea. We should educate persons to follow good practices and then measure. Not put a machine enforcing this!

Wednesday, February 01, 2006

Am I a Software Engineer?

About two years ago I decided to change my job title to Software Engineer. I did this because I think that what is missing in the Software Development field is the application of Engineering practices.

Now I found out this paper about Software Engineering Myths. The author certainly has a point and I am indeed one person that according to him is abusing of the Software Engineer title. But, you can only say this if you agree with his central point that you only are doing Software Engineering if your work is derived from some formal basis. This is a rather biased view! What I've seen in other Engineering fields is that what more establishes their common ground is the set of practices they follow. I would even say that they aren't close to science, but they use recipes derived from this formal basis. Them they mix and match according to experience to do their work.

What are the practices that we are using today that would conceed a person the Software Engineering title? I think these are things like

  • requirements management
  • modeling
  • testing
  • simulations
  • metrics
  • use of a software development process

Some of these have indeed a formal and theoretical basis. Some don't. But, they are accepted practices by the whole field. They categorize the Software Engineer.

So, although I agree with some of the observations of Sahil Thaker, I will continue to use this title, since I belive what I do is Engineering and not plain development.

ArgoUML next release

ArgoUML is arriving the next stable release. Its a very interesting time since this is the first version that we have support of UML 1.4 and XMI 1.2 with the MDR library. The active core developers base has grown now with Ludo and Tom (kudos to them), which makes a big difference. We have development in installers and the new ArgoUML AndroMDA module.

I wouldn't say that our sail is fully inflated by a good steady wind, but, we're certainly going in that direction :-))

Monday, January 23, 2006

The C++ UML profile

The problem above was included in issue #3829 and I already provided patches and tests for this to Tom Morris (the developer to whom the issue is assigned). – Well, there is an exception which is Parameter model elements, that I'll try to fix in the context of 3829. I also think that we have other problems related to namespace, ownership and undocumented behavior of my proposed solution...

With this in place I am already capable of using tag definitions owned by stereotypes in the C++ UML profile in the model elements to which the stereotypes are applied. This should satisfy issue #3771 and the planned objective for C++ reveng, but, it falls short in the context to my previous ambitions: 2005-08-16 andModel C++ in UML according to guidelines accepted in common by the community. I also think that we are buying lots of manual synchronization work to be done in the near future, which should be avoided!!! Currently we have the readme file in the C++ module source, the ArgoUML manual and the source code. With issue #3771 I'm adding the UML profile for C++ which is an additional place where these things go into. So, this means that whenever something changes I have to update four places – to be more correct its more than four since the source code for generator and reveng should be counted as two at least.

Another thing that worries me is the fact that we could be moving into a island and a not invented here syndrome. The UML profile for C++ should be something developed outside of the ArgoUML umbrella, so that it is shared with other communities, creating more reuse opportunities and improving reviews. After finding that there is no effort in the world going into this direction, I will not start with this before having other things like 1446 ready, but, it is indeed important for the overall vision realization... A possible way to start with this is to make it a kickoff step in adding support to C++ to one of the existing open source MDA tools.

TODOs

  • I must update the C++ reveng code to use the profile. The C++ reveng plan also needs an update.
  • The C++ module documentation must be updated to include this notion of using the UML profile for C++.
  • Make a review of non-working tags in the C++ generator, create an issue to handle this and coordinate things with Daniele.

Monday, January 09, 2006

2006-01-09

I'm working on issue #3771: Add tag definitions for tags used by the cpp generator. The way to go for solving this is by defining a C++ profile that could be imported automatically by projects for which C++ code generation is intended. This C++ UML profile will be stored within the module jar and support for importing it will be added to the C++ module preferences dialog.

Now, there are some problems with ArgoUML support of tag definitions (TDs). It is not possible define the tagType of a tag definition. This is relevant for the C++ UML profile, where I want to restrict to Boolean the range of values accepted by some tag definitions.

Another problem I'm having is that if I define tag definitions associated with a stereotype (their owner), these don't show as options to be applied to model elements that have the stereotype. Lets say cppClass stereotype has TDs constructor, header_incl and source_incl. When I create a class and apply the cppClass stereotype to it, the tagged values defined in cppClass aren't available to be applied to the class. Well, this takes the value out of associating the TDs to stereotypes, but, this is also an obvious bug that I may easily fix...

To enable users not to polute their models with stereotypes, the C++ UML Profile will have TDs both nicely associated with stereotypes and at top level. This might cause problems when I fix the error I identified above, but, we should try to please the users. It is no problem if the stereotypes aren't applied to model elements, since this way only the tag definitions defined at top level are available. When the user applies the stereotypes he will get one defined at model level and the ones that come from the stereotype. We could define here some type of rule, so that ArgoUML filters the top level values...

Reader Shared items

Followers