General Development

OK, we are now ready to start exploring UML. The one point worth repeating is UML is not a method or process (such as RUP). It is a modeling language and defines a set of notations and associated rules for designing systems.

Note, UML is most often used for designing software but it is not tied to this industry. UML can be used for modeling any system, such as an airplane or car.

UML defined twelve types of diagrams. These are divided into three categories which are structure, behavior and model management.

Ø Structural Diagrams – class diagrams, object diagrams, component diagrams and deployment diagrams

Ø Behavior Diagrams – use case diagrams, sequence diagrams, activity diagrams, collaboration diagrams and state chart diagrams.

Ø Model Management Diagrams – packages, subsystems and models

Diagrams in the Development Process

Where are the diagrams used in the development process? This is often one question asked by people learning UML.

Ø Requirements Gathering – use case diagrams. Often a “Vision Document” is also created to document business drivers, influences and overall goals of the system. As was mentioned before, use cases are done in the language of the problem domain, which is the language of the users. For instance, terminology is used that accountants understand in describing a book keeping system.

Ø Analysis – high-level class, sequence and state chart diagrams. Use cases are revised from the language of the problem domain to the language of the solution domain.

Ø Design – package diagram to describe the structure of the system. Class, sequence and state chart diagrams are revised. Component diagrams are used to describe system architecture and how pieces of the system will work together. Collaboration, object, sequence and activity diagrams may be used. Finally, deployment diagrams are used to show how the system will look when installed.

Ø Build – actually none of the diagrams are specifically used in this phase, though use case diagrams should have considerable input to testing.

A lot of designers champion the idea of not drawing a diagram for the sake of saying it has been used. As a minimum use cases are usually done to understand the requirements and class diagrams for design of the system.

So, with this introduction behind us, we will start looking at the different diagram types.

Use Cases

Working through a process is not new in software development. This is what we call scenarios and the benefit of this was realized very soon by software developers. However, they were not often documented or at a minimum and in a manner that was difficult for users to understand.

When working with use cases in the initial stages, Requirement Gathering, the language should be the language of the users and one should attempt not to think of solutions. This is important for gaining an understanding of the current system without outside influences (This is easier said than done).

The roots of Use Cases came from Ivar Jacobsen and his Objectory method. He was the one who started calling them use cases instead of scenarios. When he joined Rational they became a core element of UML.


A Use Case is used to describe an interaction within a system. This may be a user or another computer system. Uses cases have the following properties:

Ø Captures some user visible function

Ø May be small or large. There is no specified size.

Ø It achieves a discrete goal for the user


Use cases are described by talking to different users and discussing (in their language) the various ways they may want to use the system. This is of course built on their experience with the current system or manual processes.


Often the best way is to give this a name and write up a paragraph on each interaction. These should be reviewed by you to see similarities and to make sure you are using a common language and naming conventions (that are the same used by the users).

Also, the granularity (the size or detail), of a use case is not specified. Again, this depends on the person gathering requirements and the type of system being studied. Some experts suggest that a project should not contain more than 30 use cases. If there are more, it possibly should be broken into sub-projects.

Two main components make up a use case. They are Actors and Use Cases. Below a very simple use case is shown.

Simple Use Case

Simple Use Case

This shows 4 actors and 3 use cases. Notice how actors have interaction with multiple use cases and that an actor does not have to be a person (though shown as a stick person).


Actor is a role that a person or system plays with respect to the system. An actor is not a person, a physical person may play multiple roles with a system and multiple people may carry out a role.

One hint often given when doing use case diagrams is not to start with use cases but instead start with a list of actors. Then it is easier to determine the use cases, which is the ultimate goal. Actors are important to see who uses which part of the system and determine conflicts as well as configuring the system for different users.

Use Case

A use case is a name of a process, interaction or scenario (take your pick!) in a system. In our example above we had three, Maintain ATM, Use ATM and Audit. The use cases are interactions with the system and you know that the resulting system will need to implement this requirement. How many use cases are specified is one point of argument. It is usually specified as many as are needed to understand the system to the level you want. The beauty of iterative development is that you don’t dig into the details until you need to. Also, as in the case above if you can take a use case such as Audit and understand this function and which actors are involved, you don’t need to do go any further (for the moment).


An actor will have an association with a use case. This is shown with a straight line. Normally they are simple straight lines, though arrows may be used. When an arrow points to a use case this means the actor is active. Active means they initiate the interaction. When the arrow points to the actor, the actor is passive. This means the system initiates the interaction with the actor (often external systems).



Also, use cases may have an extend link between themselves. This is generally the used when there is two use cases that are similar and one does a bit more than the other. This is done not to “clutter” and existing use case. This is shown with a link between two use cases and the arrow pointing to the general use case and away from the more specific.

Extension Of A Use Case

Extension of a Use Case


An include link is used to decompose a use case into smaller interactions. This is done when an initial use case was at such a high level it became difficult to describe it or as you learn more it became bigger than at first sight. This is done as shown below. Notice the dashed arrows with the arrows pointing to the sub tasks. These in turn will probably become use cases in their own right.

Use Case Includes

Use Case Includes

To learn more about the Use Case technique and an excellent book on object oriented design in general see Object-Oriented Software Engineering, A Use Case Driven Approach by Ivar Jacobson et. Al.


I am in the middle of transferring everything I ABSOLUTELY need to Google Docs if my hard drive should crash. I knew Google Docs existed for ages, but this is the first time I have used it. It is amazing! I love the bulk add via email, the ability to save in different formats (e.g. doc to pdf), add tags and as you see below the ability to post to a blog.

Note for application designers/developers; it is the little things that matter once you get the application is working.  Details are everything. They don’t overload it with features, but the ones there are useful and they work.

Although the formatting is not great, I published my CV from Google Docs to this blog, as you see in the “post” below. Love it.  Here is a link to it Brian’s CV.  This link was also created within Google Docs.

What do you think of these tips?   They come from a code peer review we did and their origin is from various sources.

 1) Then anyone handling it does not need to handle null values, can just use the normal iterator for the array or collection.  Although people argue performance is a reason to return nulls, this is not worth worrying about.    If you are worried about it, create a constant zero length array in your program (so it is only created once) and always return this. 2) Only one return per method?3) Only one catch block per method (can be multiple exceptions chained) and not two different areas in a block.4) Declare variable where they are first used in a method? Not all at the top, though they will be used at the end.

5) Keep method names from being too long, but descriptive.

6) Be wary of deep class hierarchies.   This usually means something is wrong with the design. 

7) Declare constants in an interface.

I am not saying I agree with all of this 100%, but arguments can be made…. 

In a recent interview I was conducting with others I asked one of the questions I love to ask. What were the last two books related to SW development you read and in a sentence or two your opinion of it? After some hesitation and mumbling the candidate brought up Frederick P. Brooks, Mythical Man Month. OK, not a bad answer. Taking him on his word he had just read that. I didn’t test him, he gave a decent enought reason. His other answer was “a lot of BEA documentation”. Not very good….
However, this made me think of another piece from Brooks although I had read it a long time ago, No Silver Bullet: Essence and Accidents of Software Engineering. If you haven’t read this I would encourage you to do so. Joel Spolsky in his Joel On Software blog commented on it here.

By the way, looking for a job. If you have had enough B.S. from people calling from the normal job sites take a look here. It is the Job Site from his Website Joel On Software.

This is Part III in my lightweight overview of free project management tools. Part I covered some basic topics and Part II took a closer look at Basecamp, the first of the two tools I am covering. The third “installment” will look at a tool called Zoho Projects

First to the company, Zoho. In part two I spent less time talking about the makers of Basecamp 37Signals because most blog readers have heard of them either from their tools or as the creators of Ruby On Rails. Well, Zoho is quite an impressive company and although I had not heard of them until I ran across Zoho Projects, maybe some of the readers have. If you want an overview check out their website and read their blogs. They have an amazing set of tools available. Zoho Show which is an online presentation application, Zoho Writer (word processor), Zoho Sheet (spreadsheet), Zoho Virtual Office (collaboration tool), Zoho CRM, etc. I have looked at a few, seenonline presentation from Zoho Show and they are all incredible tools with free versions usually with limited users. All I can say is go to the site and have a look. It is amazing what is available.

OK, now to Zoho Project the actual subject for this blog. (As I mentioned in Part I this is a Beta version as of now, but you would never know).

Zoho Projects provides many of the features such as Time tracking for team members that are in paid versions of Basecamp. Zoho allows a more traditional view of your project with tasks having date assignments, due dates and able to track percentage of completion.

The reports in Zoho allow a task calendar view as well as a milestone delivery date. Zoho, being very Web 2.0 provides visual feedback at the mouse cursor almost every where you go. Putting the mouse over the calendar on the right side where a mile stone will cause a small bubble window to appear with Milestone information. Also, in the Calendar view you can simply put the mouse over a particular date and three icons appear for create a task, milestone or meeting.

When you go to the website you sign up by providing a email address which is for th administrator, base name for the URL like in Basecamp and password. Your project URL will then be <basename> When you name your project, you are ready to start defining it. Currently one project is allowed per admin email address.

You can add users that will either be employees, managers or contractors. Below is an empty dashboard view of the project.
Empty Zoho Project
Some really cool features are the Latest Activity section in the Dashboard so you can see what exactly was done to the Project Plan you are making, including deletions.

As in Basecamp you can enter tasks but as I mentioned there is more information that can be entered. I think the biggest difference (didn’t I say I would not compare them, oh well) is Basecamp is the minimalistic view (this is actual a theme of the company 37Signals, only do what is needed and nothing more) and Zoho gives you more choice to add more information. I like this approach too, you don’t have to do it, but if you want the opportunity is there.
Here is a view of the tasks and milestone page with a couple of tasks and milestones defined.

Task and Milestone View in Zoho
Milestones are similar to tasks only have the same start and end date. When milestones are created you can also add tasks under them that need to be completed for the milestone to be completed. This is shown below:
Milestone with two associated tasks

Another nifty feature is the ability to track time working on a task. If you enter the Timesheet Calendar view you can select a date and log time for that day to specific tasks. This is also a feature in Basecamp, but again in the paid versions.

I hope this quick overview of Zoho Projects may have wet your appetite for trying out the extensive feature set. Zoho is really impressive and I am sure it will be getting a lot of press in the coming weeks/months.

I am looking forward to presenting Zoho as well as Basecamp to my students as I believe they both provide an excellent method to manage your projects.

In part I of this series I explained the background of what I am writing about, reasoning for looking at project management planning software over MS Project and introduced the two products, Basecamp and Zoho Projects that I am going to cover. In part II we will look at Basecamp.

Many of you will have heard of Basecamp and even maybe have used it. Basecamp, according to its website has over 500,000 users and you can read loads of accolades. It is no doubt a great product and I am not going to crritique, just run through a highlight of its features.

Basecamp comes in different pricing models, I have only used the free version. You get a lot of functionality in the free version but there are limitations such as you can only manage one project at a time and advanced features such as Chat and Time Tracking are not present. Note the chat is provided by integration of one of their other products called Campfire, which you can also sign up for separately for free. The drawback is it is not integrated with your project.

Here is an overview of the different pricing models and their features (as of 16 Sept, 2006).

Basecamp Pricing

Basecamp Feature and Pricing
As you can see, you can get a version with all the features and the ability to manage 35 projects for $49/Month.

What you will notice when you work with Basecamp is its incredible user interface and broad spectrum of possibilities when working with the product. It is really amazing for a web application what they make possible.

When you sign up for a Basecamp account you need to enter some basic information, including a base url for your project. This becomes part of the URL to your project. Once this is done you can upload a logo for your company, change the coloring scheme and grant access to other team members (users). Finally, you select the link to Create your first project. After giving this a name such as “Project Management Class” you will be ready to start defining the different components of your project.

Messages are the first component we look at. These are where you provide basic project information for your project for other team members, important links to web pages and documents. You have formatting possibilities such as bold and italics easily built in with formatting characters. You can also select from a list of provided categories or create your own, attach a file to the message and finally select project members to send an email to. This is your basic communication method in Basecamp. Below is a simple example of a message:

Basecamp Example Message
To Do Lists provide organization of tasks. They work by allowing you to organize, prioritize and assign items in the to do list to team members. Note that to do lists do not have dates assigned to them. Tasks with assigned completion dates are milestones, which we will look at later. I like this idea, the general idea is we need to get these done at some point, but no exact date. Also, along the lines of the project management pronciple of more than one person can work on an item but only one is responsible you can either assign to Anyone or to a single team member.

Milestones are assigned items with a specific due date. You name the milestone and provide a date. Users of MS Project will recognize this concept with a task of 0 days length and a diamond in the Gantt Chart.

You can also assign the milestone to the team or a specific team member. Also nice is that in the Dashboard view you can see a calendar view with easy overview of when milestones are coming due. Milestones can be view milestones in Apple iCal and Mozilla Calendar. By checking a milestone you mark it as complete. Below is a view of milestones, notice the reminder of an overdue reminder.

Milestone View in Basecamp

Also available in the free version are whiteboards and chat sessions through 37Signal’s other products.

Does this seem simplistic? It does and that is the beauty in the approach. Once you spend a day setting up a project in Basecamp you will come to appreciate the simple and effective way it allows communication, tracking tasks and deadlines. You can share documents, work on versions and even chat with other members. Email reminders simple screens make sure confusion and updating is an easy task.

In summary, Basecamp insures you spend your time working on what is important and provides non-obtrusive support for your project planning needs.

When teaching Project Management, I often have the feeling I am struggling to make the class interesting and relevant.   Since my audience consists of senior undergraduate level students and it is a required course I face two hurdles:  1) Many would not choose this course if they did not have to take it; 2) Most (99%) have no experience in Project Management, even as someone who had worked under a project manager.   I do have an occasional adult student who has some experience.   So enough whining, what is my point anyway…

I do stick pretty close to the book with my lectures, the very good book from Kathy Schwalbe, I am always giving a lot of thought to what I can do as a value-add and make the course more interesting.   Most of these students have not started their careers yet, not even sure where they want to go with their careers and certainly are not looking for a PMP certification.  One thing I do is assign a group exercise where they are required to research and present an assigned topic such as eXtreme Programming, RUP, Scrum, MSF (Microsoft Solutions Framework, etc.   This gives them an insight into the software developmnent lifecycle and differing methodologies.

Since the book mainly uses MS Project as a software project planning software example, I have decided this semester to show some other examples.   I am not knocking MS Project, I also decided to go over some lightweight methods of organizing projects verse the heavier method MS Project provides.

So, I have chosen two examples.   These are:

1) Basecamp – a blurb taken from their website states: Basecamp turns project management and collaboration on its head. Instead of Gantt charts, fancy graphs, and stats-heavy spreadsheets, Basecamp offers message boards, to-do lists, simple scheduling, collaborative writing, live chat, and file sharing.

2) Zoho Projects – again from thee product website a short description of their goal.  Zoho Projects help teams organize their work & track progress. Most of the project management software takes longer time to setup & it becomes a overhead in a project. Zoho Projects is designed to make sure Planning & Management takes lesser time than the actual work.
Basecamp is from the same company that brought the world the Ruby On Rails phenomenon.  They have several other collaboration products available such as Campfire, Backpack, Writeboard and Ta-Da List.

A couple of notes/disclaimer.  First, you may ask what problems these are products trying to solve?   Microsoft Project works fine, it has all the functionality I need from a project planning software tool.  Again I repeat, I am not slamming MS Project it is a great tool for many projects.  This is only a different perspective.  You are right, that is the point.  It can have too much functionality.   These products are trying to be effective by being simple.   A software planning tool should assist the development team in delivering software, not become a project in themselves.  Often maintaining the project plan becomes a horrendous task taking up way too much time.  I have experienced this myself, all the charts, reports and task lists (Work Breakdown Structure) become tedious to maintain.  These products are providing a lightweight manner to maintain tasks, resource assignments and the communication.  These products would work great with a development methodology such as Scrum which is meant to be lightweight.
The disclaimer is that I have used the free versions of 37Signals products for my own use and am a big fan of them.  Basecamp is a very capable product that has been available for some time, Zoho Projects is in beta.  I am not going to compare the two (though will be inevitable it may happen) but attempt to explain my view of how each works.

In installment two I will start looking deeper into these two lightweight project management products.

Next Page »