Open Source UML

There are a variety of open source modeling tools in existence today. Some of these tools are more popular than others for various reasons. One reason for the variation in popularity is the support of the UML specification or lack thereof. Another reason is the overall user experience while building models with these tools. Proprietary UML tools are much more advanced than their open source counterparts in several dimensions. This is why they are the preferred choice by most developers who use the language. They are usually the right tool for the job. If an open source UML modeling tool does not implement part of the UML specification that is important to the developer, this is a show-stopper. Software developers want to use the right tool for the job. Anything that involves less modification and less duplication is always a bonus. However, open source UML modeling tools do exist and are in wide use today so there must be a reason for this. There are some advantages and disadvantages to choosing an open source modeling tool. Two questions to ask before choosing a UML modeling tool are as follows. If a tool doesn't support some part of the UML specification, how will that affect me? How many non-modeling features does the tool have that I will probably never use? I'd now like to explore these questions a little further.

One question to ask yourself that should probably precede the two above is what am I using the UML for? This will obviously influence your choice of modeling tool because different features serve different needs. I'm not going to dig too deeply into what the various uses of the UML are and why they matter. Instead, I'd only like to consider two broad categories; UML as a sketch and UML as a specification. The former category is the more widely used of the two as it requires less of an investment. The latter has much more of an impact on the success of the project because the model has to be formally correct. Otherwise, the cascading modeling errors have a major disruption. What you want to use the UML for is irrelevant here. What is important is the style of modeling you want to use; sketch or specification.

Lets take a look at the UML specification itself. Some of it is essential for tool vendors to implement such as classes and relationships. Others aren't as important such as profiles and timing diagrams. This level of importance is relative to any given project domain. For instance, if we were modeling the specification of a real-time system, these sections of the UML specification are suddenly much more important than if we were simply sketching ideas using UML notation.

Proprietary modeling tools have better support for the UML specification itself. In the rare case that you require a modeling tool to support the full UML language specification, the choice is easy. You need to invest in a proprietary tool. This is the exception rather than the rule. The majority of UML users do not need support of the full specification. Open source UML tools have good support for essential modeling elements such as classes, packages, relationships, use cases, interactions, and state machines. Some are better than others for modeling certain elements and they are all different from one another in terms of user experience.

What if you want to build UML models as a software system specification? Can you still do this if you only require a subset of the UML specification be implemented? Indeed, you can. If you like a given tool, whatever the reason may be, you can't select it for use and hope that it will support the full specification in the future because that may never happen. Open source modeling tools are perfectly acceptable for using UML as a specification. Lets do a quick run-through of which UML elements can be used as a specification with open source modeling tools. Classes, packages and relationships? Check. These elements are ranked the highest because it would be next to impossible to model an object-oriented system without them. Actions, activities, control-flow, and data-flow? Check. We need these elements of the language when it comes time to build smaller, atomic computations of the system. Use cases. Check. These are a must for visualizing simple requirements. This only touches on the very fundamental elements of the language. Support for the UML specification in open source software goes much beyond our purposes here.

Open source tools have these areas pretty well covered without much deviation from the UML specification itself. Open source UML tool support in other areas of the UML specification, like interactions and state machines, are still lacking or are inconsistent. Again, how important are these areas of the language to you? Even with incomplete or missing implementations, using UML as a sketch is possible with open source UML modeling tools. As an example, consider nesting modeling elements. With some open source tools, dragging one element into another to show a parent-child relationship has no effect in the semantic model. That is, internally, from the tool's perspective the two elements are at the same level. From the end user's perspective, these elements are at the same level so the sketch still serves it's purpose.

Up to this point, we've only touched upon modeling elements that exist within the UML specification and the tools that implement them. This is, after all, the primary goal of a UML modeling tool. There are, however, some features that fall outside the scope of the specification itself. The value of these additional features are something to consider when choosing a modeling tool. Many of these features are probably not needed.

Code generation is a must have for any enterprise-grade UML modeling tool. Is this actually a must have? Or is it a feature just for the sake of having a feature? Generating code is also supported by open source UML tools. The claimed benefit of generating code from a model is that the skeleton of the classes and their relationships can be built automatically. This saves us some tedious typing but it also introduces a level of coupling between the model and the code that may not be desired. This is because at the code level, there are going to be small hand-made changes that aren't reflected by the model. If you are building models as sketches, this is definitely not a feature you'd be willing to pay for.

XMI support enables the exchange of modeling meta-data. In theory this is a must-have feature for any modeling tool, open source or proprietary. It is a must-have because it is the standard format used to store and transfer semantic model data. If you are sketching UML diagrams, the underlying semantic model isn't as valuable to you. Therefore, the need for XMI importing and exporting isn't that great. Organizations tend to standardize on a modeling tool once one has been chosen. Even if you are modeling rigid, software system specifications, your need for XMI support may not be that great. In the spectrum of open source UML tools, support for XMI isn't quite there. Different tools support the interchange standard at different levels. It is comparable to the support for various web standards among various browser vendors. The little differences create more problems than the standard solves.

The overall user experience is a criterion that is sometimes overlooked in regard to UML software. Aside from what features are supported, what is needed, and what we can do without, usability has an impact on the quality of the models we produce. Usability isn't necessarily isolated from the feature set of the software. If any given UML modeling tool has too many features that are edging away from the UML specification, we're distracted. I would go so far as to say that this makes the software intimidating when it doesn't have to be. The number of steps required to construct a basic diagram should be small. If that number is too high, think about using something simpler. Building models is no different than writing code in that it is never going to be right the first time around. Modeling is an inherently iterative process. If your chosen modeling software can lead to building models in a more timely manor due to a clean, simple user interface, give that software high marks.

As you can see there are more attributes of a good UML modeling tool to consider than the number of features it has. Deciding on what you are using the UML for, sketching or specifying, changes the evaluation criteria when choosing software. Open source UML modeling tools are a good alternative to purchasing a proprietary tool in some cases, even though these tools still haven't reached maturity yet. When open source UML software doesn't fit your needs, consider how many unnecessary features you will be paying for when choosing your tool of choice.

Proprietary Threats

In a recent entry about the state of the Postgres project, the author explains that the project is still in good health. This explanation was brought about by the recent idea that Oracle could simply buy them out by head-hunting the core developers. This is a lot more difficult to do than it sounds. Especially for open source projects such as Postgres.

The fear seems to be that Postgres will go the way that MySQL did. But, as the entry points out, they are entirely different in terms of development culture. Postgres is different in that it doesn't have a single authority in which to make decisions.

Proprietary vendors can threaten open source projects in more ways than one. It can overcome open source projects by nothing more than intimidation. They have a lot of resources. These resources include buying power. Large corporations can typically purchase their way out of potential competition.

Open source developers really shouldn't concern themselves with this threat for two reasons. One, open source projects are largely distributed both geographically and in interests. New people join open source projects every day. Again, as the entry suggests, there are more than enough developers that will be willing to pick up the slack of those who leave any given project.

Another reason why the open source community shouldn't concern themselves with proprietary vendor threats is that competition can also be a good thing. It can be a good thing for both parties.

In a given domain, lets say databases, users have a choice between proprietary products and open source projects. Both sides can benefit from one anther because they provide a reference point in which to do comparisons. So the open source project can say "you can pay for feature X or you can get feature YZ for free" while the proprietary vendors can say "sure, feature YZ is stable, but you paying for stability in feature X".

The list goes on. There is never going to be an entirely open source or an entirely proprietary software world. Threats will be posed from both directions. If you are a developer, your best bet is to just use what is made available to you to make the best software possible. Better than the last version anyway.

Moving Away From Open Source

This entry over at IT world discusses some of the forces behind users that fully intend on using an open source application and make the jump over to the proprietary software world instead. It seems counter-intuitive that any user would will give up something that is free just to pay for it. But as the entry states, there are many reasons users do this. Open source applications tend to have a lack of support, lack of features, and lack of documentation. Oddly enough, there are some open source applications that share the same qualities as their proprietary counterparts. They both have a great feature set, documentation, etc. But like all software, the subtle differences can simply make one application better than the other.

The biggest stumbling block is installation and initial configuration of open source applications as far as I'm concerned. Proprietary installation and configuration procedures are generally a more enjoyable procedure. This is the first step to using any application and is important to get right because it gives the user an impression of what the rest of the application experience is going to be like was it actually gets installed if ever.

The Idea of Running Wine on Ubuntu For Windows Compatibility

Wine is software that acts as a compatibility layer to allow applications designed to run on the Windows platform to run on Linux platforms. An interesting entry has brought up several questions about the need to run Windows applications on Linux desktops. It is indeed a very involved question which has the potential to go unanswered indefinitely. Chances are, if you are running a Linux desktop in the first place, you didn't have a need for Windows applications. But what about when you do need them? It would be nice if all open source alternative did it all, but that simply isn't the reality of today.

Mark Shuttleworth, founder of the Ubuntu Linux distribution was asked how important the role of Wine and Windows + Linux compatibility in general, will be in the success of Ubuntu. The reply was straightforward, it is, and it isn't.

Wine is hugely innovative software that has no doubt contributed to the success of not only Ubuntu, but open source software in general. Not by allowing users to simply just run Windows applications on Ubuntu. If that were the reason, there would obviously be no point in running an open source operating system. Wine is a gateway application. By allowing people to use Windows applications on open source systems, there is no avoiding the exposure to lots of interesting stops along the way. But what about the native Linux user? Does Wine have any useful purpose for these users? Maybe not all of them but there will no doubt come a time where the open source alternative simply doesn't exist. In times such as these, Wine negates the need to install Windows natively or, even virtually for that matter.

When considering questions such as these, there is always lots of ego involved from both the open and proprietary sides of the table. Both sides have a cause and once joined, people tend to stick to them. On the open source side, the direction of any given project isn't dictated so much as collaborated. There really is no rank among contributing project members aside from what they are able to produce. This is what really counts, and this was made very apparent by Shuttleworth's response. I for one applaud it.

Open source too insecure for government use?

Well, according to an infoworld entry, security firms seem to think so. Rather than go through all the odds and ends of comparing the security differences between proprietary software, I propose a simple experiment. Set up two desktops. Install some variant of Linux on one and install some popular proprietary operating system on the other. Perform some simple everyday tasks and see which one gives you more security problems first.

Teachers and open source

An interesting entry about teachers and their ignorance toward open source software has made me happy. Not the teachers, the fact that people are willing to voice the problems caused by proprietary software in the education system.

The entry states that Canada is making larger steps than the US to improve open source adoption in schools. Unfortunately, I highly doubt that is true.

I think there should be a huge sense of urgency here. Instead, it seems some of the teachers that aren't completely oblivious think "OK, there is Linux, but there is nothing I can do about it".

Perhaps teachers should encourage students to use Linux and other open source projects outside of the classroom. Rather than merely "allowing" it. Let the students insist on bringing open source into the education. I would think this would be a much easier task with student support.