What became very clear for me in a short time that there is not much interest in a professional organization. So after struggling for a few month last year, I turned my attention to other things, mostly to work, and starting my business.
This year however I had a lot of free time again – see my previous post -, and picked up the thread.
It is definitely a difficult endeavour. Most of the local business analysts I contacted last year has expressed no interest at all in the initiative, but this time I had more results.
I am not sure how successful this will be, I have hopes, and have gathered some support, but I am well aware of the possibility of failing spectacularly.
But no matter what, I will keep on trying so I can say in the end: I did what I could.

Why form a local chapter?

IIBA has the stated goal of advancing the profession of business analysis by providing standards, best practices, and a supportive environment including meetings, conferences, webinars, and finally, a certification for those interested.

The local chapter would do the same on a local level, promoting the necessity of the BA profession, hosting conferences, meetings and providing a venue for local? professionals to exchange knowledge and ideas.
In my experience a much needed thing.

If you happen to be a business analyst or an IT person working in Hungary, and you would be interested in helping us, please contact me.

So how does UML models asynchronous messages, and how can you tell from a sequence diagram if a message is asynchronous? During the talk there were four signs mention that shows that a call is asynchronous:

1. There are dashed arrows showing the return calls.
2. The activity boxes are not continuous on the main lifeline
3. The arrowhead is not filled for the asynchronous message
4. The asynchronous message is not horizontal but diagonal.

My favourite one is the diagonal message, and I first I intended to write only about that, but then I thought better and decided to write bout all four statements above.

I will show you which ones are false statements, and why the last one – which was called simply nonsense – is actually true.

1) There are dashed arrows showing the return calls.

Well, asynchronous messages definitely have return calls. But so does synchronous messages. The UML specification does not restrict the use of return call to either of them. So having return calls on your diagram is not an indicator of whether the call is asynchronous or synchronous .

UML Superstructure Specification, v2.1.2 page 472 Figure 14.11

2) The activity is not continuous on the lifeline of the called or the calling object

That can be true. Or not. It actually does not show with 100% certainity if it’s a synchronous or asynchronous flow.
The activity can go on and off for a couple of reasons.

a) On the called object’s lifeline it goes off after a return call (whether shown or not)

b) When you do a callback from an asynchronous call

c) When you do a callback from a synchronous call with an explicit End Source Activation on the original synchronous call

NOTE: Ok, this is a red herring. It only seems to be a synchronous message, and the only reason you can do this is because the CASE tool allows you to do stupid things. This is an asynchronous call despite the misleading arrowhead. Now, can you tell me if the guy who drew this diagram was doing it deliberately to mess with the reader, or wanted to create an asynchronous message and did not bother with the correct arrow heads, or tried to be clever, and this is a synchronous message and wants to get a point through in an awkward way, or simply does not understand the whole synchronous/asynchronous business? No? Thought so.

So this one you can discard, bad use of the modeling tool / notation is simply that.

d) On the calling object’s lifeline the activity rectangle gets disrupted when you start a new message group

You have to take into consideration that although it is not a good practice – at least in my opinion – nothing on Earth prevents or forbids you from displaying more than one flow on one diagram, and that can mess up the activity rectangles even more.

On the activity rectangle

This activity rectangle thing, where we state that the object is “active” or “inactive” based on the presence of the rectangle, is not well handled. For one thing in the UML specification they are called: ExecutionOccurences (that name is telling a bit more about the meaning of it). The other thing is, if you think about the rectangle as an indicator of whether an object is active or not, then why does a callback from an asynchronous call disrupts the activeness of the object? The object does not become less active when he receives a call back.

Notation

ExecutionOccurences are represented as thin rectangles (grey or white) on the lifeline (see “Lifeline (from BasicInteractions, Fragments)” on page 490).
We may also represent an ExecutionSpecification by a wider labeled rectangle, where the label usually identifies the action that was executed. An example of this can be seen in Figure 14.13 on page 475.
For ExecutionSpecifications that refer to atomic actions such as reading attributes of a Signal (conveyed by the Message), the Action symbol may be associated with the reception OccurrenceSpecification with a line in order to emphasize that the whole Action is associated with only one OccurrenceSpecification (and start and finish associations refer to the very same OccurrenceSpecification).

Overlapping execution occurrences on the same lifeline are represented by overlapping rectangles as shown in Figure 14.15

UML Superstructure Specification, v2.1.2 page 479

If you think about it as an Execution Occurence, and not whether the Object is active or not, it will make more sense.

3) The arrowhead is not filled

Actually that’s the only way to show an asynchronous message according to the UML Superstructure specification.

Notation
A message is shown as a line from the sender message end to the receiver message end. The line must be such that every line fragment is either horizontal or downwards when traversed from send event to receive event. The send and receive events may both be on the same lifeline. The form of the line or arrowhead reflects properties of the message:

• Asynchronous Messages have an open arrow head.
• Synchronous Messages typically represent operation calls and are shown with a filled arrow head.
• The reply message from a method has a dashed line.

UML Superstructure Specification, v2.1.2 page 493

A quick note: some books and CASE tools use the half-stick arrowhead to differentiate the asynchronous messages – an open arrowhead with the bottom half missing -, because for a time that was the UML specification. But even then, the asynchronous message is shown by a different arrowhead than the synchronous message.

Sadly, on big diagrams printed on small papers that’s not too easy to read – Martin Fowler proposes the us of the half-stick arrowhead, stating that the filled/open distinction is too subtle. I am not sure that the half-stick arrowhead will solve this, but definitely was a bigger difference than the current one.

4) The message is not horizontal but diagonal.

It seems weird, doesn’t it? An asynchronous message “does not cause the invoking operation to halt execution while it awaits the return of control.” That means it can take it’s own sweet time to execute and that means it is not neccessarily an instantaneous call. So, we can define how long it can take to execute and return a result for example – i.e. timeout.

As the lifeline of an object in a sequence diagram represents time, the simple fact that an asynchronous message have 5 seconds to start, or 5 seconds to execute, can be shown by a diagonal message line – plus we write the Duration and Timing constraints – as it happens that’s the way you show it in UML.

Of course most of the time we don’t apply timing constraints on a message. But it is good to know that there is a possibility to do that. So you can say, that for simplicity’s sake an asynchronous message is diagonal except when the set of timing constraints is empty. Then it’s a diagonal with an angle of 0 degrees.

{ Don’t do that. It’s pointless and just shows you always wanted to be a theoretical mathematician, and failed for a good reason ;) }

And if we are talking about time, there are a few other possibilities according to the UML specifications.

Figure 14.26 – Sequence Diagram with time and timing concepts

The Sequence Diagram in Figure 14.26 shows how time and timing notation may be applied to describe time observation and timing constraints. The :User sends a message Code and its duration is measured. The :ACSystem will send two messages back to the :User. CardOut is constrained to last between 0 and 13 time units. Furthermore the interval between the sending of Code and the reception of OK is constrained to last between d and 3*d where d is the measured duration of the Code signal. We also notice the observation of the time point t at the sending of OK and how this is used to constrain the time point of the reception of CardOut.

UML Superstructure Specification, v2.1.2 page 513

We can define the timing interval for the message, and we can define Observation timing and duration for the message – useful in the case of time sensitive systems, and contrary to what some people maintaint, that there is no possibility to define time related behaviour in the UML, there is a few ways to show that.

That was it. All my first thoughts on the sequence diagramme and the asynchronous message notations. I had an inclination to cut it into two separate posts, but in the end, I think it’s complete this way.

As always, any criticism, comment, question or idea on what I have left out, or what should I delve into a bit more, or mistakes I made are welcome.

Related articles by Zemanta

• PHX Session #5 : Architecture Without Big Design Up Front (Garibay) (slideshare.net)
• UML & SCRUM Workshop (slideshare.net)
• Usability of UML tools should beat the “pencil and paper” alternative (modeling-languages.com)
• OMG is trying to improve the interoperability of UML/MOF/XMI-based tools (modeling-languages.com)

“And what method do you use?”
The project manager looked at the lead developer then turned back to me and said “Well, we are a small company, so we don’t need a method”

I have run into similar situations a couple of time and I think it is one of the most annoying myths there is.? – “We are …. so we don’t need a method”.
Well, the good news is that no matter what the project manager says, the developers usually have a method, a software development process, or even a methodology. What these words mean?

method: 1: a procedure or process for attaining an object: as a (1): a systematic procedure, technique, or mode of inquiry employed by or proper to a particular discipline or art (2): a systematic plan followed in presenting material for instruction b (1): a way, technique, or process of or for doing something (2): a body of skills or techniques. (from Merriem-Webster)

method: a way of doing something, especially a systematic way; implies an orderly logical arrangement (usually in steps) (from Web definitiosn)

methodology: 1 : a body of methods, rules, and postulates employed by a discipline : a particular procedure or set of procedures 2 : the analysis of the principles or procedures of inquiry in a particular field (from Merriem-Webster)

software development process: a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. (from Wikipedia)

So what the “we don’t need..” means is that we develop software without any logical process, doing things as we please, no order, no logic, we just hack it together. Given that the company is still running, I suspect the developers know better and they use some method, process or something.

The lead developer cleared his throat “well, we use a waterfall like method. We certainly don’t want to go agile”

Yes, just as I thought, there is a process. A waterfall one, but if it works then that’s perfect. The developers need some process – even when they protest loudly against any process introduced by the management -, otherwise they will get lost. So they build a “homemade” one. It is a bit sad though if a project manager thinks they don’t need it, and doesn’t even recognize the existence of an already used process or method. Or simply does not know meaning of the word.

The method used is not a trivial or unneccessary thing, it has a big effect on how the development is done, and as a result it has an effect on a lot of other things. The way a company creates a product affects HR decisions, sales and marketing decisions, business decisions, use of resources, and so on.

But still, it seems to be a widespread belief that if a software company is small, or smart, or in a definite business or simply they feel like, then they don’t need a method, they can just work anyhow.

And by this I don’t say that you must choose RUP, or UP, or Scrum, or Agile, or any of the buzzwords. But you have to face the fact that you can’t work without a method – you don’t build a doghouse without one, even if it’s a simple one, so why do you imply that you can build a complicated software without one?

Usually this is one of my first questions on any interview or project startup meeting, and when I hear the “we don’t need…” answer that’s the end of the meeting on my side.

2. Use Cases

Use cases are an interesting part of the UML. They predate the UML by years and for me they are a bit “sticking out”. The actual UML notation while can give a nice diagram does not really provide much information, most of that info is in the textual description of the Use Case – which is the actual hard part of the Use Case business.

People like the “potatos” nonetheless, they look easy, a stick-man here, a potato there, connect them with arrows, and we have a new requirement, lets go code. Yes, I did it too when I started to use them. Unfortunately, while the resulting diagrams would have made nice posters if I only put them in a frame, the practical value was zero. So here is a few common mistakes I met in the last few years.

1. the potatoes and stick men are the focus of the Use Case model, and the textual part is almost completely ignored – a really useful and thorough book is Alistair Cockburn‘s Writing Effective Use Cases.

2. the Use Case model is used as a process flow, with one potato for every step in the process, and <<precedes>> and <<invokes>> associations, or simple associate arrows guiding you through the whole flow. This is evident, how much info does a bubble with a one line description of a 25 step long process give?

Real life example. Sorry.

3. the Use Case model is used for the wrong requirements.
4. the Use Case model is used in the wrong phase of the project.

The 1) and 2) are evident, I would talk about the last two points, 3) and 4).

3. The Use Case model is used for the wrong requirements

So here we can tie the different requirement types with the Use Case model. If we look at either Wiegers’ or the BABOK requirement types, we can see that there are only a few kinds of requirements that can be modeled with Use Cases.
The first thing that is evident that Business Requirements cannot be modeled with Use Cases. Neither can Quality of Service Requirements, Assumptions and constraints and Implementation requirements be modeled with Use Cases – or, if you go with Wiegers’ grouping, no Business Rule, Quality Attribute, External Interface or Constraint can be modeled.
With a quick note that the existence of External Interfaces can be implied by Actors representing external systems.
The only requirements that can be modeled with Use Cases are the User requirements, and part of the Functional Requirements. A Use Case called “Recovering User Data within 2 seconds” is not exactly a Use Case.

4. the Use Case model is used in the wrong phase of the project.

As Business Requirements cannot be modeled with Use Cases, and Business Requirements are on the top of the chain – they are the very first requirements to discover – it is evident that the “start requirement gathering by drawing a Use Case model” approach is wrong.
And still, I have met it a few times – what is more worrying though is that it does not mean that Use Cases are used to model the Business Requirements. It simply means that Business Requirements are skipped.
As a result we don’t really know why we started the project apart from a hazy “we need a new system”, what is the exact goal to achieve, and how to measure if we are there.
What we will know is that there are a lot of functional requirements, an ever growing list, and we will finish the project if every single one of them is implemented.

It is not the fault of the Use Case, or the UML or such, but if the first requirement we see is a Use Case and it is called “Reserve Hotelroom” then we should suspect that maybe a few steps and requirements are already missing.

The first topic I want to get a go with is the use of Use Cases. But, before I start on the use cases I would like to clear up some basics about the requirements.
I’ve met a lot of people for who there is only one kind of requirement: business requirements, every single one conforms to the same theoretical and well defined structure and can be documented in the same template.
I personally think that it is an oversimplification of the whole thing, and I think it usually means that:

1. half of the requirements are missing
2. a lot of different things are not recognized as requirements

I think that there are different kinds of requirements, with different goals and as it happens with different documentation needs -
I usually go with the Business Requirement, Functional Requirement, Functional Requirement distinctions and for me it works pretty well -, and in the literature about requirements there are different groupings and types listed. I will just look at two sources now, but I think those two are enough to prove this statement.

In Karl E. Wiegers: Software Requirements, Second Edition the requirements are grouped as follow:

• Business Requirements: Business requirements describe why the organization is implementing the system – the objectives the organization hopes to achieve.
• User Requirements: describe the user goals or tasks that the users must be able to perform with the product.
• System Requirements: describes the top-level requirements for a product that contains multiple subsystems.
• Functional Requirements: specify the software functionality that the developer must build into the product to enable users to accomplish their tasks.
• Business Rules: include corporate policies, government regulations, industry standards, accounting practices and computational algorithms.
• Quality Attributes: desired characteristics like usability, portability, integrity,efficiency, and robustness.
• External Interfaces: describe external interfaces between the system and the outside world.
• Constraints: restrictions concerning the development, restricting the choices available to the developer for design and construction of the product.

The Business Analysis Body of Knowledge (BABOK) lists the following types of requirements:

• Business Requirements: are higher-level statements of the goals, objectives, or needs of the enterprise. They describe such things as the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success.
• User Requirements: are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. User Requirements serve as a bridge between Business Requirements and the various classes of solution requirements.
• Functional Requirements: describe the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations-a specific system action or response.
• Quality of Service Requirements: capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as non-functional or supplementary requirements.
• Assumptions and constraints: identify aspects of the problem domain that are not functional requirements of a solution, and will limit or impact the design of the solution.
• Implementation requirements: describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state, but that will not be needed once that transition is complete.

The groupings overlap in several places, and are the results of long years of experience – in the case of BABOK long years of many people’s experience – so I think that it can be accepted that there is a real need for separating the different kind of requirements. Especially if you ever want to take the CBAP Exam, because that uses the BABOK as the course material.

But if we accept that there are different kind of requirements, with different goals, levels and content, then we have to admit that they need different documentation, different way to model and present them, and that they can not really be put in the same template.

That’s enough about laying down the basic assumptions about requirements, that I will use in the rest of the post, and we can move to the use cases.

It did not take Yanic Inghelbrecht too much time to point out that his tool is better for sketching sequence diagrams, and asked if I would review his tool, Trace Modeler. Of course I said sure, and it was not because he offered me a personal licence – I just have to tell you that yes, he offered one, also as he wrote in his mail:

Please understand that I do not wish to influence you in any way by this. I’m pretty confident you’ll like it and of course I’m hoping for a favorable evaluation, but above all I hope you’ll give your honest opinion.

So there we go, all transparent and you all know the complete background.

So I just downloaded Trace Modeler, and started to poke around. I have to admit that at first sight I did not like it. The fact that there is no class diagram, so I just have to draw the sequence diagram “in the air” so to speak made me balk. I tried it anyway and after a while it dawned on me that this is a sketch tool, not a design tool, and for that there is no real need for a class diagram. Keeping that in mind I concentrated on how well it supports the sequence diagram sketching.

So after playing with it and poking at it I have a well formed opinion, and it boils down to a list of “Things I like” and a list of “Things I don’t like”. The latter is more like a wish-list and some suggestions. One more thing. I will not show you how to use it, what are the menus and will not tell you what a sequence diagram is – for that there are resources like the Trace Modeler User Manual and the UML Superstructure Specification.

So lets see the likes and dislikes.

Things I like

1. The handling.

   I like it. It is self evident and easy to understand most of the time – the exception see under Things I don’t like – and honestly one of the easiest I have met so far.

2. Diagram Style

   First place to go.Beside the possibility to set up the layout rules – distance between objects, message spacing, layout direction, etc. – you can set whether empty returns are shown or not – I usually hide them, make it less cluttered, but sometimes it’s good to see them – and you can display the Control Flow – with configurable colour, so you can make it bright red and see the control flow from a mile.

3. It’s small and no install

   Really, the whole thing takes up 4.2MB, no installation required, so you can carry it around on a USB stick.

Things I don’t like (suggestions + wishlist)

1. The message dragging

   It is handy and convenient, but there are a few problems:
   - Sometimes the drawing is oversensitive and you have to re-drag the line
   UPDATE: Ok, it was pointed out that you don’t have to drag the arrow, you simply place it over the target line and it will put it there.
   - there are “dead spaces”, which means that between two lifelines the red trace disappears (signaling that it won’t be a ‘self message’) and you have to drag the mouse further right for it to reappear (signaling it will be a message to the next lifeline). This dead zone is about half a centimeter on my screen.

   Solution: you don’t start from the originating object but place the arrow on the target object.
   However, if you do this, it will take a while to discover that you actually can send messages both direction.
   Update: Ok, see above, it is not the solution, it is how it was intended to work.

   I would like it better if there were no dead zone, and the source-target objects would be highlighted, but this deadzone is the result of testing and user feedback, so apparently works for the majority of users.
   

2. Can’t move the end of the arrows.

   One of the more interesting examples in the UML Superstructure specification under the Sequence diagram section is overtaking messages – actually an asynchronous message with a duration constraint, but calling it “overtaking message” sounds more car-race like.

   

   The message CardOut overtakes the message OK in the way that the receiving event occurrences are in the
   opposite order of the sending OccurrenceSpecifications. Such communication may occur when the messages are
   asynchronous.

   But as this is a sketch oriented tool it is not a big loss – just make a note somewhere. And there is a promise that multiple-flow of control, and more will be implemented this year.

So after all the above, and taking into consideration that we are talking about a sketching application, not a full blown CASE tool, I think Trace Modeler is up to that task. It won’t replace any big, integrated CASE tools, but it is perfect when you have to do a quick sketch and paper is not an option.

For a sequence diagram sketchpad it is good. What would be even better if there was an export option to some of the usual CASE formats – Rational Rose, EA, etc. – so after I made the sketch I could import it into my usual case tool and use it – Yanic’s response to this wish was

Unfortunately there is no easy way to do this. XMI was supposed to be a standard way of exchanging UML diagrams and models, but every CASE tool has its own little quirks and inconsistencies so interchanging data is not straightforward.

The sad truth is that he is totally right and I am well aware that the standard is not a standard at all. But I still wish. Wouldn’t it be nice if standards were treated like standards?

So Tracemodeler is definitly on my list of “on-site tools”. And in the end, a 30sec demo from the

Since then I tried to educate myself, keeping up with the new stuff – which means buying a lot of books from amazon, and reading the interweb s. Hungarian publishers are not – or at least were not – too mad about this technology stuff, except when it comes to programming languages. The Gang of Four Design Pattern book took 9 years to publish here in Hungarian. But I digress.

I try to stay up to date, and try to make people improve where ever I go – especially with the “before coding” phases of the project, requirement gathering, design, etc. And then I like tools too. That’s why when Yanic asked if I would do a review of his Trace Modeler application I instantly said yes. And will publish the review the next week. But in the meantime I had a sudden idea – if I have this blog, why not write about UML an it’s use as I see it? I am reviewing a modeling tool that uses UML notations, so I could go a bit into the notation parts too. At the least, there will be some content on the blog. At the most some people get ideas.

It’s my blog, I work with UML, so noone can prevent me doing that. In the next couple of weeks – or, considering my writing speed, months – I will run a series of posts about UML and related stuff.

Business Analyst Times

Within the past year, BA Times has quickly become the ultimate destination for the ever-growing Business Analyst community.

Our team keeps the site consistently updated with the latest news and in-depth articles within the industry, ensuring that BA Times is at the forefront of relevant content surrounding all developments regarding business/systems analysis, CBAP Certification, industry events and cutting-edge BA insights.

Most importantly, BA Times is committed to the advancement and recognition of the Business Analyst Community.

If you are involved in Business Analysis, or just want to see what BAs on your team are concerned with, check out this site. There are a lot of useful and interesting stuff.

Project Times

Business Analysts and Project Managers go in pairs – tightknit couples you could say as BAs act as PMs a lot of times.
So here is the site for the Project Managers, same platform, same style as the BA Times.

Modern Analyst

Modern Analyst is another great community with loads of articles, posts, discussions and whatnot.
If you are working as a system or business analyst, and has a website, you can get it on their Resource Directory for free as a member.

Requirements Network

Yet another site for BAs, or anyone interested in requirements, with blogs, forums, podcasts and whitepapers.

Catalyze

Catalyze is a community for professionals who define and design software applications and websites.

Yes, blogs, forums, resources and events. And community.

They all are good and useful, with lots of great discussions and posts and articles. Check them out, and see if you like.

Whatever you have to design there are a lot of choices, different ones, aimed at different targets by company preference, ease of use, price, whatever.

And as it is, we usually end up with more than one tool to deliver our goal. By the time I publish this post I have used Darkroom, Windows Live Writer, GIMP, iMindMap and my web browser. When I work, I use Darkroom (thanks to Dosh Dosh), Enterprise Architect, iMindMap, Requisite Pro, MS Word, Excel, MS Project, or anything else that the current job – and the company – requires me to use.

And of course, I use the best design tool ever.

The best design tool has to support the design of different things from software to database to web layouts, pictures, web posts, novels, weekend programmes, in fact, it has to be good for the design of almost everything.

In addition the best design tool has the following important technical features:

1. It has to be easy to use.
2. Has to have a short learning curve.
3. Must support different notations – and in the same design
4. Must have a clean and simple user interface
5. It has to be distraction free
6. And a lot more…

Looking at this list, I realized that the best design tool is the paper+pencil combination. It’s pretty easy to use, it certainly has a clean and simple user interface, and at the same time you can design pretty much anything with it. You don’t have to upgrade it regularly, you don’t have to worry that it will get slow, you can use whatever notation and style you want, and on the same piece of paper.

You can fill half the paper with UML standard notations, the other half with screen design, then on the other side of the paper you can scribble formatted texts – using any kind of bulletin points, skulls or flowers if you want – and draw a mind map , and on top add an SSADM style entity life history, no limits. And you can mix it even, and put an association link between a UML class and a mind map. And of course you can decorate it easily.

There are a few problems with it of course: you need place to store the the results, and there is no copy paste function implemented – although, thinking about the amount of problem copy+paste generates it can be a benefit.

Best of all, the paper has no distracting features. Have you ever noticed that you sit down in front of your favourite – or company issued – designer programme, and after placing a few boxes and linking them you suddenly realize that in the last 10 minutes all you did was aligning them properly, and straightening the lines? And of course, colouring the boxes.

Then, in the middle of your thinking Skype beeps, and starts to blink in the task bar, and Outlook notifies you of an incoming e-mail which you start to read and next thing you know you are googling the answer to some question your boss asked you. Or your spouse. Or whatever. No such things with paper. No menus, icons, blinking and beeping.

And then there is creativity – when you drag a box on the screen, that’s all, you drag a box. When you draw it with your hand your brain starts to move and pick up the speed – at least, that’s what the smart ones say ¹ – and you have to concentrate more, pay attention more when you draw the shape than when you just drag it up.

My main problem with the paper is that people are prone to think you did nothing if there are no new files in the repository or the old ones are not updated. But that can be managed – most of the time. Of course there are people who claim that if it’s not in the machine it does not exist. Fortunately they are rare.

So I say you stick with the paper when you design. It’s convenient, easy to carry around, and when you have something that won’t make you cringe when you take a second look, you can sit down in front of your machine and copy it from the paper into your chosen programme. Sure, it takes time, but you already saved a lot of time by working with a more active and more creative mind, and not getting distracted by the “Check it out!! It’s hilarious” mails you got from your friends.

This post wouldn’t have been written if I weren’t asked so many times: What’s the best design tool for….

I think the Case Tool’s strenght is not the ability to draw nice diagrams and such, but the resulting documents – among many others. I just stress documentation now for a given reason.

On this project as it happened, there were several people gathering requirements, writing specifications, producing written documents and diagrams, sheets and sheets of data. The only problem was that these documents were not uniform. The style of numbering was different, the layout of the tables were not the same, and all the small things. Diagrams were created in Visio, and as noone set up a mandatory stencil for the project, the diagrams had some small differences in appearance.

What advantage a Case tool would provide to the project? Well, first of all, in a case tool everyone uses the same set of elements for the diagram. The information is entered into well defined places. And the resulting documents are generated by the tool, thus every single one would result in the same layout, font types, headings, ordering of the data, text and graphical thingies, following the same numbering conventions.

All in all, a case tool would have provided the project with a set of uniform documents, without the project members hunting for small errors, like using a ‘-’ instead of a ‘.’ and so on.

And then, we did not even go into the wonders of tracing between different parts of the documents and deliverables throughout the project lifecycle.

So, does it worth to invest into a case tool? If you just use it as a glorified diagram drawing application, then no way. But if you spend 5 minutes to look at what other values it has, then certainly. And you don’t have to get the most costly one. Sparxsystem’s Enterprise Architect is more than adequate if you are just start to learn it. And you can get one from 135USD, which is definitely cheap.

NOTE: I know, that with some tweaking and adding Data fields to shapes, you can set up some elaborate documentation even with Visio. I just think it is too much hassle. Visio has it’s uses, but can not – and is not intended to – replace case tools.