UML Tools

Why UML?

Many people appear to think that modelling is only for academic textbooks and school. Several months ago I worked on a project that failed, for numerous reasons, but some of the reasons were mine. So I set out to figure what it was that I didn't know, that would have allowed me to build this system I had been asked to.

After reading Patterns of Enterprise Application Architecture, Domain-Driven Design: Tackling Complexity in the Heart of Software, and Design Patterns: Elements of Reusable Object-Oriented Software and realizing that all of the great books used UML. I realized that UML is a great visualization tool, and that it helped me understand the concepts they were talking about. This didn't have to be entirely academic, and perhaps I could use these tools to communicate my idea's. So I've set out to learn UML, and picked up copies of UML Distilled: A Brief Guide to the Standard Object Modelling Language (3rd Edition) and although I find it to be a decent reference guide, I didn't think it was quite what I was looking for. So I then picked up Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition) , and am about halfway through it. What I really wanted was a book to explain the what, when, and why of UML, this book seems to do that and more. It covers a lot of subjects I've glanced over previously in a fair amount of depth, and puts them together.

So how does using UML relate to my original issue? I determined after reading these books that what we had done poorly in our "Agile" process was planning. Another common fallacy is that iterative development means don't plan. No what it means is keep your planning to a minimum, code, code, code, plan, code, code, code, etc. If you spend more than a week planning you're spending too much time, and your planning itself should be iterative, meaning go back and do more at the beginning of each iteration. I also learned that part of, pre-coding, planning is modelling. When you're dealing with a simple one or two objects modelling is likely overkill, but as your software complexity increases, the more indispensable modelling becomes.

Armed with new theories of Object Oriented Analysis and Design, and a visual modelling language to assist I set out to model the complex system. The initial tool I selected for modelling is fairly common, and I used it to build a few diagrams, but as time went on my diagrams changed more and more, and became more complex, and I became more and more frustrated with the tools ability to help me update the model. In spite of this as I worked through the model, and distilled it, I realized that the model itself was working. Now I simply needed a better tool to model with, and more time to build the system.

What am I looking for?

I work entirely in a Linux Environment and do not have WINE set up because I abandoned Windows about 5 years ago now, so whatever tool I choose has to work in Linux, and I will only do so through WINE if no adequate non wine solutions present themselves.

I really need reasonable pricing because I'm still hemorrhaging money on student loan. Free is obviously ideal, but I need to be reasonable, this thing should not cost more than my cell phone.

I don't really use IDE's such as Eclipse or Netbeans, so integration or as a plugin is not required, in fact I don't want to run those to run this.

The first tool I used, I ultimately realized that it was making me do vector graphic artist level tweaks to make it look good. So I require that it require as little human intervention as possible to look good.

One of my colleagues is blind, and I'd like to be able to share my diagrams with him, so I require the diagram be able to be output to a simple text format. Ideally a format generated from the diagram, and not the diagram generated from the format, because while diagramming I am thinking visually.

Full UML 1.4 support is required for me to get off the ground, but I'd personally prefer UML 2.X support as it has a few nice features such as sequence diagram conditionals.

The tool should be as intuitive (to me) as possible. I've found many of the tools require my brain to context switch, or I simply have trouble finding out how to do the feature I'm looking for.

Once I discovered that some tools were capable of determining that some elements were related across diagrams I decided that I should have this feature and it should do as much for me as it can.

The tool and it's UML should be aesthetically pleasing, this seems novel, but if I hate looking at the tool I'm not going to use it.

How am I testing?

Well in addition to simply checking the general requirements I have, as you can probably tell a lot of what I'm looking for is subjective. So basically I spent some time modelling a simple blog. If I encounter any serious frustrations creating diagrams the tool is discounted and I move on. Basically this is, largely, a usability and intuitiveness test, if I have to think about the tool very much then it's getting in my way

FLOSS

Dia

The first tool I used was Dia. It is basically a free Visio clone. It's very flexible and allows me to create almost any diagram I could want, though it only seems to support UML 1.4. I also found myself micromanaging the relation lines, which only seemed to have one style and wouldn't path together in the right places. Dia requires that you click a text edit palette button to change the name on something and it's finicky about it, which is just frustrating. There was also no auto arrange feature. Ultimately I've found the unlimited flexibility to take my mind off my task of modelling and put it more on drawing. I worked with this tool for a few weeks, but these were also weeks where I was less familiar with UML, so I hit the limits later.

UMLet

UMLet was the next UML tool I tried. I found it to be much simpler than Dia for the same purpose, and it allows you to modify the elements that you can add in a purely textual way, and the file format stores them this way, which would almost provide my textual format requirements. However I found it's support for sequence diagrams to be limited. Also Class, and other diagrams would not resize if the text was too big. Lastly, although I could drag main elements out of the sidebar to add, I found that I couldn't do so with relationship lines, which got frustrating. The Class to edit class text requires a mental context switch which I found to be unpleasant.

Umbrello

Next I tried KDE's Umbrello. The first thing I noticed is that it's hideous. KDE software is usually amongst the most attractive on Linux in my opinion, but Umbrello does not follow the stereotype. The default Class is red and yellow, this can be changed but unfortunately that's not really the only problem. I found the overall user interface to be a little odd, perhaps it was just from using other tools that have some better interface design decisions. This was the first tool that I found could do cross diagram associations, and it even has a seemingly nifty feature which makes a relationship not it's own entity, and therefore you can edit it while editing the class.

Violet

Violet is actually one of the nicer open source editors, ultimately it made my top 2 pics on the Open Source list. It appeared to be relatively easy to make nice diagrams in violet, without the interface getting in the way. Unfortunately it doesn't allow diagrams to be inter related, nor does it offer any kind of a text export. I am not sure whether I ultimately like the change mouse pointer create an element on every click until you reselect the normal pointer, this is like an art tool.

ArgoUML

Argo UML is the closest to the proprietary tools I've tried. Unfortunately like all of the open source tools it only support UML 1.4. It does support cross diagram relationships, and has an easy to use interface. It is actually the originating source of one proprietary product Poseidon. However it did not support the text export. I decided to keep looking into proprietary products to see if one had a significantly better interface than this. But if you must have an Open Source product this is the one I suggest.

Web / Cloud

yUML

yUML is a partial solution to UML diagrams via a web interface. It allows you to generate most UML diagrams via a simple text interface. I like this software, it doesn't give you much control over the arrangement of the diagrams, only the semantics, but personally I think that's ok. Unfortunately it doesn't support sequence diagrams, but the author has a reason for that.

Web Sequence Diagrams

Web Sequence Diagrams is complementary to yUML, in that it provides the missing sequence diagrams, and combined you should be able to make all the UML diagrams you really need.

Creately

Creately is a flash based visio clone. To some degree I found it even nicer than Dia, because the diagrams were prettier, and mostly easier to manage. I gave up on this tool when I realized it was missing some diagrams, had not text export, and especially because I found it incredibly difficult to add multiplicity to class diagrams.

Proprietary

Visual Paradigm

I tried Visual Paradigm for UML and by tried, I mean I couldn't get it installed. I've been using Linux for ~10 years now, and half of that was on Gentoo, I even managed to get Oracle 11G working on Arch Linux, a video card that no distro could detect working, and built my own Fork. It complained of not being able to access the X server, but considering I could run other X programs from that shell, I would say that whatever it was trying to do it was trying to do wrong. I tried both the installer and the "just a zip" version, and the latters binaries didn't spawn a window. Needless to say I didn't proceed further with their software, already having a full host of alternate solutions.

Magic Draw

I was able to get Magic Draw installed, the hardest part was figuring out that they had sent my evaluation license to my email, and my email had filed it as spam. After playing with it for a while, I found that certain pieces of the diagram (again multiplicity) were hard to figure out how to add. In this case It was about how they'd named it. I felt their interface was more complicated in general than necessary. The nicest thing about Magic draw is it has the best auto arrange I've evaluated, and it does not allow elements to be placed on top of each other. However, I eliminated it due to the other challenges of its use.

Poseidon

Ok, I didn't end up trying Poseidon because by the time I got to it, I had idea's on what I was looking for. A quick look tells me that I'd have to pay more than my computer cost to get the auto arrange feature and the plugins. To try the community version I'd have to register, and it appears sign up my credit card and cancel within 30 days. I personally believe that it's shady if you're making me remember to cancel and it's not a service.

Enterprise Architect

Sparx Enterprise Architect runs in WINE I tried installing this on Wine 1.5.12, but either something went wrong with my following of the instructions, or they are not complete. Much like Visual Paradigm it isn't really worth my time to figure out why it didn't just work when I'm evaluating products. It not "just working" is a massive black mark.

Astah

Of course I save my recommendation for last. Astah Professional is very similar to ArgoUML in UI design. In addition to Argo's features it includes a working auto arrange for class diagrams, full UML 2.0 support, and a plugin to upload to yUML (untested, but should allow the textual representation). In fact during my work with it I found only a few things that I found limiting.

When using auto arrange on class diagrams any text on relation lines tends to get overlapped, but a little tweaking at that point hasn't seemed hard, and will be easier than rearrange the entire diagram. Also auto arrange doesn't seem to work for sequence diagrams. Hopefully both of these improve in future versions, but they're really minor, and I didn't find anything that was significantly better at this.

You can overlap elements, that probably shouldn't be able to overlap, such as classes and lifelines. This allows for a great deal of flexibility, but I also think that not allowing it would be a good idea, perhaps it could be a future toggle-able option. As an issue it's pretty trivial, though made a bit worse by auto arrange not working in sequence diagrams.

The only thing I don't like about it, is how, like Argo and many of the others, I have to "change my mouse pointer" to determine what new elements I'm creating, like selecting a palette. Existing model elements are drag and drop, but I wish new elements were also drag and drop as it more matches my mental model. Most of the tools I tried were this way though, only a couple being drag and drop.

Astah even appears to have a couple of reasonable pricing models, subscription, and perpetual (neither of which cost more than my phone), with cheaper for students and a free community edition. They even have a program for open source projects and community leaders called Friends of Astah.

Disclaimer: I applied for "friends" and was accepted. I was asked to write a blog on Astah. The truth is this post was already written with a winner decided before I even applied. I have refactored it a bit though to be a little more in depth on Astah.

UpdateRepublishing due to an issue with the first

Where's 5.16.1?

Per the 5.12 release announcement http://dev.perl.org/perl5/news/2010/perl-5.12.0.html

This release cycle marks a change to a time-based release process. Beginning with version 5.11.0, we make a new development release of Perl available on the 20th of each month. Each spring, we will release a new stable version of Perl. One month later, we will make a minor update to deal with any issues discovered after the initial ".0" release. Future releases in the stable series will follow quarterly. In contrast to releases of Perl, maintenance releases will contain fixes for issues discovered after the .0 release, but will not include new features or behavior.

5.16.0 was released on May 20, 2012, it is over 2 months later, was 5.16.0 so good that there are literally no bugs? or has something gone wrong with the time based release schedule? I also I note that there was never a 5.14.3. I'm just a concerned citizen of the Perl community, I don't want to see us go back to the days of pre 5.12, when releases happened whenever/never.

UPDATE: Per RJBS comment below, apparently there was an interesting bug in require which has just been fixed and will be getting backported.

Perl Core Syntax Wishlist: Role Support

I want to see Role's added, even PHP got Traits before Perl. It doesn't have to be a huge thing, in fact all I want is the composition aspect. Let me do this: I don't really want or need anything else right now, just that would be fine. We should have interfaces too, but they aren't really required just to support Role's. We should probably have some sugar like I did for class (e.g. role keyword. and some of the same modules/pragmas loaded for this too)

New Module: MooseX::RemoteHelper (RFC)

Background

I have spent much of the last year writing and refining Remote Facades. At this point I've worked with SOAP, REST/JSON, and RPC url-form-encoded API's. One of the hardest parts I've found is dealing with the serialization of a Data Transfer Object with a Perl interface into whatever the remote is expecting. When I started I didn't know of these patterns, or really anything about these patterns. I highly recommend reading Patterns of Enterprise Application Architecture) if you want to know more about these patterns or things like Active Record and MVC.

problem

The problems I've encountered are many, including the fact most remotes are buggy or have a cludgy interface. Though there's nothing you can do about a remote api that you don't control, you can make your local API much cleaner and more native. Doing this however comes with a few challenges. One is that you have to map a local attribute name to a remote attribute name, because Perl uses underscores, and Java uses camel case, e.g postal_code and postalCode. The second problem is that many times the value of the attribute in its perl native form is not what the remote wants, e.g. perl boolean "1" remote "Y", or a DateTime object to W3C formatting. This second is not quite the same as mapping, because mapping is one to one, this translation could be turning an array into a comma separated string. The third problem, I didn't run into until after I "solved" the first , is how should I deal with nested complex objects (one's that can't be just converted to just a string).

My first naive remote facade was very procedural and simply assembled top to bottom, in part because it was based on SOAP::Lite, and in part because I had yet to figure out a better way. This resulted in a giant unwieldy if/then chain. Obviously my translations were just inline too.

The next thing I tried was using triggers to construct a request hash to pass to XML::Compile::SOAP. This worked better as the hash constructing code was kept right next to the attribute, so if I needed to modify the local or remote attribute, I could just go look at the attribute and the trigger tied to it.

After that I tried to use a map to translate from the native attribute name to the remote attribute name. This may have been more successful had it worked more like the Assembler in the Remote Facade. But ult imately since we were developing a rapidly changing API it seemed to bog me down, this is because I was changing the attributes on both sides of the mapping and thus the mapping at the same time (so at least 3 places). Here I was just manually dealing with the translation from a W3C DateTime format to the object I needed.

a solution

When I got assigned to yet another API and found myself doing yet another mapping and translation I decided that I needed to solve the problem. Enter the first iteration of MooseX::RemoteHelper. The first tie I used it with the form-url-encoded API so it was only needed for a single level of key, value pairs. .

Once I determined how to create MX::RemoteHelper it was simply a matter of using Class::MOP::Class API's to iterate all the attributes. The source of CompositeSerialization will give you some idea of how I did this.

Then I went back to apply this to a previous module, because the technique appears to be cleaner. Unfortunately I ran into a problem, this other API was a complex data structure, and how best to provide nested hashrefs and arrayrefs. Though I was now armed with Patterns I didn't know of one that would solve the problem. Fortunately a quick flip through the Gang of Four brought me to the Composite Pattern. I used this to write the recursive CompositeSerialization so that if I had a sufficiently complex nested structure I could simply create another object to deal with that. Here's a full example:

use 5.014;
use warnings;
use Data::Dumper;

package MessagePart {
    use Moose;
    use MooseX::RemoteHelper;
    with 'MooseX::RemoteHelper::CompositeSerialization';

    has array => (
        remote_name => 'SomeColonDelimitedArray',
        isa      => 'ArrayRef',
        is        => 'ro',
        serializer => sub {
            my ( $attr, $instance ) = @_;
            return join( ':', @{ $attr->get_value( $instance ) } );
        },
    );

    __PACKAGE__->meta->make_immutable;
}
    
package Message {
    use Moose;
    use MooseX::RemoteHelper;

    with 'MooseX::RemoteHelper::CompositeSerialization';

    has bool => (
        remote_name => 'Boolean',
        isa      => 'Bool',
        is        => 'ro',
        serializer => sub {
            my ( $attr, $instance ) = @_;
            return $attr->get_value( $instance ) ? 'Y' : 'N';
        },

    );

    has foo_bar => (
        remote_name => 'FooBar',
        isa      => 'Str',
        is        => 'ro',
    );

    has part => (
        isa      => 'MessagePart',
        remote_name => 'MyMessagePart',
        is        => 'ro',
    );

    __PACKAGE__->meta->make_immutable;
}

my $message
= Message->new({
    bool    => 0,
    foo_bar => 'Baz',
    part    => MessagePart->new({ array => [ qw( 1 2 3 4 ) ] }),
});

say Dumper $message->serialize

Which should give you this data structure:

Request For Comment

I've recently released a Trial version of MooseX::RemoteHelper to CPAN. I'm currently refactoring Business::CyberSource to use it, and it appears to be solid. What I'd like to know what people think of the module names, method names and any other comments they might have. I haven't been entirely sure that I've been naming things correctly while writing this, or that the code couldn't be better in other ways. If there's functionality you wish it had but doesn't let me know.

Perl Core Syntax Wishlist: Class support

I would like to see the class keyword become part of Perl, but unlike some I don't want it simply because it's nicer syntax. I'd like it to behave differently from package. I'd basically like to see this I'm sure smarter people than I could think of a few more things that might be nice to have by default in all classes. I would like to note that method signatures is not that big of a deal to me, unless of course you want to give me named variables in the signature besides just auto shifting off self, e.g. method foo ( $bar ) { return $self->{foo} if $bar }

Better Exceptions with Exception::Base

So I've done some complaining and explaining about what I'd like to see in regards to Exceptions in Perl. I Mostly explained what I wanted for catching Exceptions, and a little on throwing Exception objects, but not really how those objects should behave. I've looked at and tried various exception modules, including croak, confess, and Throwable. I basically spent time one day reading the manuals of most of the exception objects on CPAN. Most of them didn't allow me to easily for the exceptions I needed (meaning they required more work than I thought I should do for one or two exceptions ). Among these modules I found Exception::Base, which appears to do everything I need (though I still wish for something like it in core, with shinier syntax). Of course wee need to be able to throw simple Exceptions, preferably ones that can stringify, and are easily matched in a switch or if statement. Exception::Base can do all of that, and it even boolifies to true. A really big thing I wanted was a class I could easily add attributes to without writing a whole new package/pm and subclassing it there. I wanted this because I really wanted to be able to have 2 kinds of messages, one for programmers, and one for users, but truthfully I only had one class where I needed this flexibility (at the time). It is also occasionally useful to have attributes that describe something, e.g. would be really useful in moose attribute exceptions, to be able to have an object where you could catch the exception and get the attribute name without parsing. Fortunately Exception::Base can do this too. You'll notice if you run this script that in the warn, both usermsg and logmsg are printed because they are both string_attributes. You'll also notice that attr isn't printed at all, but that we can look at it directly to make other decisions. Exception::Base has other features such as setting the verbosity so you can go from a croak level message to a full stacktrace. It also allows you to ignore_packages so that the exception does not appear to be thrown from that package. This is similar to @CARP_NOT.

Perl Core Syntax Wishlist: die should die

I hate die it is, in my humble opinion, one of the worst parts of perl. I really wish it would be deprecated, and removed, or at least replaced with something that would tell you were the code that was die-ing was being called. Replace its implementation with that of Carp's croak or confess and I'd be happy. Better yet, let's just get real exception support and deprecate die (even if that's never removed deprecation just make that real big on its pod). If you're using die please stop and use Carp, anyone using your module will thank (and by thank I mean not curse) you later.

Perl Core Syntax Wishlist: an Exception Stack

I have come to wish many things were part of Perl syntax that are not, and no using external modules is not enough for me. I think it's time Perl got the features as part of the language itself (and yes I suppose I could settle for feature.pm, and no I'm probably not going to write them myself, I'm not smart enough yet). The first of these is a proper exception stack. I want to be able to write: I think we need throw, try, catch, and finally keywords. And no I don't think it makes sense to have Object->throw. In fact I think this Original Perl 6 Syntax Proposal reads like just what we need in Perl 5. Unfortunately I think this is what we are getting in Perl 6, which IMO is not as nice.

Adventures with SOAP using Perl: Part 2 ( SOAP::Data::Builder )

Start by reading the first 2 parts :

1. Part 0 Prelude (setup server.pl)
2. Part 1 SOAP::Lite

SOAP::Data::Builder is simply a wrapper around SOAP::Data and SOAP::Serializer for SOAP::Lite. I used it because it made my life easier building nested complicated SOAP objects. However for Part 2 I will simply be showing how to use it to do the same code as Part 1. Unfortunately since Part 1 is so Simple this actually makes SOAP::Data::Builder more complex than SOAP::Lite would be for this. In a future installment I will attempt to show more complex examples, but I will explain them less. Now let's take a look at the code.

#!/usr/bin/perl
use 5.010;
use strict;
use warnings;
use SOAP::Lite +trace => [ 'debug' ];
use SOAP::Data::Builder;

my $req = SOAP::Lite->new(
    readable   => 1,
    proxy      => 'http://localhost:8877',
    ns         => 'http://namesservice.thomas_bayer.com/',
);

my $sb = SOAP::Data::Builder->new;

$sb->add_elem(
    name  => 'name',
    value => 'Mark',
);

my $res = $req->getNameInfo( $sb->to_soap_data );

say '-' x 3;

unless ( defined $res->fault ) {
    say scalar $res->valueof('//country');
} else {
    say $res->fault->{faultstring};
    say $res->fault->{detail}{error};
}

As you can see this is much the same as the final code in Part 1, and if you run it, it does exactly the same thing. The first difference you'll notice is the self explanatory creation of the SOAP::Data::Builder object. After that comes the ->add_elem method call, which will simply create an element with a given element name and a value for that element.

Once you've finished adding elements to your $sb object, then you can call pass $sb->to_soap_data to the method that you're calling on SOAP::Lite, this generates the structure that SOAP::Lite needs to be able to make your request.

The only thing I didn't like about SOAP::Data::Builder is if you don't pass the right parameters to ->add_elem it will not croak or error in any way that will really tell you what went wrong. Simple patches to this can fix it.

Simple scripting CLI with Expect.pm

Expect is use primarily for sending Input to Command Line programs that Prompt and wait for input. For starters you'll need an executable script and I've pasted one that I got elsewhere for a demo.

#!/usr/bin/env perl
# slightly modified from http://www.tizag.com/perlT/perluserinput.php
use 5.014;;
use warnings;


print "How old are you?";
my $age = <>;

print "What is your favorite color?";
my $color = <>;

say "You are $age, and your favorite color is $color.";

It's trivial, you should probably run it just to see what it does. Now take a look at our Expect Script.

Although you can read the comments yourself, let's go over it anyways. ->spawn takes a list of arguments, with the first being a command, and the rest being any command line arguments, or options passed to said script. I could have easily just put the command in spawn, but I though I'd show a more dynamic example. After that you'll notice I've hard coded 2 sets of params that could possibly be fed into the program. I also have created some 1 at a time iterators, this simply makes it easier to iterate them in expect. Now onto the Expect object itself.

If you've read the documentation you'll notice there are 3 debug settings, with 3 being the most verbose, and some verbose settings. None of this appeared to be as verbose as I could get, however turning on ->exp_internal(1); printed everything I needed to understand expect and debug what I was doing wrong. The ->spawn method of course forks and execs our command, the output of which then gets iterated by ->expect.

The first argument to ->expect is the timeout, which is measured in seconds. The timeout is how long expect will wait for the output to match one of the regexes. You could set it to undef if you want to wait forever, or if it's just a program that has some startup time before it prompts set it to a few seconds. The timeout will (by default) be used again in between each prompt.

After timeout you can specify a list of array refs, each of which has 2 elements. The first is a regular expression that will allow you to tell expect how to recognize a prompt. The second is a coderef which allows you to tell expect what to do if it's corresponding match is hit. Both regexes will be run against every line, checking to see if they match.

Inside of our coderef we can use ->send to send input to the prompt. Remember send doesn't automatically press enter, so be sure to add your newlines. exp_continue means after match continue using this ->expect call to try to match the next line.

When running the script you'll notice the second regex never matches, but if reading the 'internal' output you'll see that it is attempting to.

The last line is a call to ->before which in this case, not very intuitively prints everything that was in the pty after the last match, or more appropriately, before the program exited. You'll also notice that it collects the thing that you sent to the last match.

That's the basics of what I've discovered, I'm not sure I fully understand how it all works yet (which means my explanations might not be 100% correct), but perhaps me writing this will help someone else get started with Expect. Happy Hacking!