This document is an introduction to the Unified Modeling Language (UML). After reading this and some practice you should be able to use UML in your analysis and design of software systems.

UML has established itself as the defacto standard in software and system design and therefore anybody who works in this industry should understand UML and its role in the development process.

UML is a modeling language, not a process or a method. Most methods (or methodologies) contain a modeling language (usually graphical notation) and a process. The process is a “how-to” on how to use the modeling language and the steps to take in designing. For a high-level description of the process see the section in the Appendix on the Rational Unified Process (RUP).

What Is Covered

Because this is such a larger subject, it is important to set the boundaries of what will be covered. This introduction is meant to be a focused coverage of the subject and allow people to begin to use UML in their development. There will be areas that are breezed over or skipped completely.

We will cover what UML is, the history and some of the important types of diagrams. Some hints on how to use them and when they are used will also be given.

What Is Not Covered

We will not cover object-oriented concepts such as what is a class or what is an interface. Also, this will discuss the process used for analysis and design and some hints or tips will be made on how to use it, but the overall design and development process will not be covered in-depth.

What Should You Know

The reader should definitely understand Object Oriented Concepts such as:

Classes and objects
Inheritance
Overloading (Polymorphism)
Abstraction

Also, beneficial would be some experience in the development process (see the section on the Rational Unified Process)

2Brief History of UML

How did we get to where we are at today? Understanding the drivers and history behind a subject can help one to get a get a complete understanding of a principle or concept. This is certainly true in this case.

Why was UML even invented? It was mainly the wisdom and intuition of a few people in understanding that a standard and organized way for people to communicate when designing systems can only be beneficial.

In the 1980’s and early 90’s there were a myriad of design methodologies. These came about because of the sudden popularity of object-oriented programming languages (C++. ADA, Smalltalk, etc.). Naturally there were design methods before this time, even object-oriented ones but the popularity of C++ created the need for a new approach. Most design methodologies before this were data driven and/or functional in nature. When programming in an object-oriented language they were found to be not adequate.

Some of the methodologies that became popular were Rumbaugh OMT, Booch, Coad-Yourdan, OOSE from Jacobsen and Shlaer-Mellon to name a few. All were quite good in certain areas, but seem to not cover the whole design process. In other words, one had as a strongpoint the requirements gathering where another concentrated on the sequence of events in a system. Also, each methodology had its own type of notation, often similar but different enough to make it hard for someone knowledgeable in one methodology to have trouble understanding another designer’s work and the associated notation.

At this time developers adapted their favorite method and even adapted these into their own hybrid design methodology, splintering the industry even more. We then had the so-called “Method Wars” where people argued endlessly the pros and cons of their adapted methodology. If anyone has ever heard a developer discuss his pet programming language, you will know this group can be quite religious about their beliefs. On top of this, consultants had bookshelves of books and needed to learn different methodologies dependent on their client’s needs and preferred method of design.

Finally, around 1994-1995 three design creators, Jim Rumbaugh, Grady Booch and Ivar Jacobsen joined forces at a company specializing in design tools called Rational (the distributor of the Rational Rose design tool and now part of IBM). They became known as the famous “three amigos”. They declared the “Method Wars” over and soon came out with a first release of the Unified Modeling Language. While there was still some disagreement, this was overcome when the standards body, Object Management Group (OMG), decided to adapt UML as a standard design modeling language. Note, the OMG is the same group that came out with many other standards, including CORBA.

Within a short period this became the standard for Object Oriented Design and Analysis (OOD&A) and almost all major players in the industry proclaimed their support for UML. This has probably single-handedly brought the software development industry further than any other single accomplishment. Currently the UML Standard being completed is version 2.0.

3High-level uml

Before we can start getting into what UML is and describing UML notation we need to cover a few introductory topics.

Introduction to Modeling

Modeling is the design of systems and specifically in our area of interest software applications. The model can be compared to a plan when building a ship or a floorplan when building a house. They are used to assure themselves that business functionality is complete and correct, needs are met and the design supports the system requirements (i.e. scalability).

We all have read the statistics on success of software projects and the probability of success. Therefore, modeling should be a key player in increasing the odds for a successful completion of a project.

UML is used to specify, visualize and document models of software systems. It is not a methodology, it is the notation or common language used to specify a system. How you use it is not specified, or specifically the methodology. Go to

http://www.cetus-links.org/oo_ooa_ood_methods.html for a very (almost exhausting) description of methodologies.

Analysis and Design

At this point it may be beneficial to make the distinction between analysis and design. Analysis is the specification of a system’s requirements as an object model. Basically analysis determines the technical and business drivers, specifications and boundaries to gain a thorough understanding of a system. This is highly important as the main determiner of a successful software development project is user satisfaction (or the covering user requirements). If you fail to analyze a system or existing process properly it will be very difficult to build software that users are satisfied to use.

Analysis overview: http://www.sei.cmu.edu/str/descriptions/ooanalysis.html

Design on the other hand is concerned with the development of an OO model of a system that will satisfy the requirements. Two main goals beyond the obvious implementation of the requirements is maintainability and reusability. Maintainability is accomplished through simplified designs due to a deeper understanding of the problem domain. Reusability is attainable through the same understanding and mapping to the features of a particular object-oriented programming language.

Design overview: http://www.sei.cmu.edu/str/descriptions/oodesign.html

Software Development Process

Earlier it was mentioned we would not cover the process for OOD&A or methodology. There are hundreds of books and many well-known methodologies to choose from. However, irregardless of the process, the following steps must be performed.

Requirements Capture – this is where the requirements of the system are understood. It is important to be able to do this in a language the users can understand or as it is called in the “problem domain”.
Analysis – this is where the requirements are taken and one starts to mold into a possible solution or in the “solution domain”. An abstract manner is used, in other words it is kept at a high level.
Design – the specification from the analysis phase is taken and a concrete solution is defined. This is done in full detail.
Build Phase – the design is used as a base to actually program in the chosen programming language. This is just not programming, it is also testing to ensure requirements are met, testing that it solves the customer problem and documenting the system.

There are two basic ways to develop software, one traditional and one modern (I believe all software development methodologies are derived from these two foundations).

3.1.1Waterfall Method

This is where each phase of the software development process is completed before the next phase is started. One downfall of this method is that it is often impossible to understand the requirements completely at the start of the project. Second, code does not become available until late in the project.

The waterfall method and the typical steps are depicted in the following diagram:

Figure 1 - Waterfall Method

As you see, like in a series of waterfalls, once you move down to the next level it is extremely hard to get back to an earlier step.

Another negative point is that each consecutive step in the process requires more effort and this is increased if a phase needs to be revisited. This is depicted below. A basic premise is modifications in a software development project are cheaper the earlier they can be made.

Figure 2 - Effort in the waterfall method

3.1.2Iterative Method

The iterative method has as its main idea getting some code produced as soon as possible and then highlight any problems early in the development.

One way to visualize this is by looking at the development process as a series of small waterfalls. The analysis, design and build phases are first performed for the most important requirements and then after user feedback they are repeated and more of the requirements are covered. This continues until all requirements have been satisfied.

One advantage is the work is done in manageable pieces of work and project managers can retain an overview of progress.

How this looks is shown below. Notice the same steps are covered as in the waterfall method, but in small portions and repeatedly.

Figure 3 - Iterative Method

For a complete description of the Rational Unified Process, look in the appendix at the end of this document. This is becoming the standard method for Iterative Development.

Also, extreme Programming has gained a lot of attention lately. This again heavily involves users in the entire development process and has some unique characteristics such as turning the requirements into test cases, among others. For more information go to http://www.extremeprogramming.org/.

UML Diagram Types

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 statechart 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 statechart 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 statechart 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.

4Use 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 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.

Figure 4 - 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).

Actors

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).

Association

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).

Extend

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.

Figure 5 - Extension of a Use Case

Include

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.

Figure 6 - 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.

5Class diagrams

One of the first diagram types beginner designers of object-oriented systems are faced with is a class diagram. This is usually because most books on object-oriented programming are filled with such diagrams.

Classes

A class diagram is a diagram that shows classes, interfaces and their relationships. The most basic element of a class diagram is a class. Classes are drawn as rectangles and divided into maximum of 3 compartments.

Figure 7 - Basic class

As you can see above, the top portion is for the class name. The middle portion contains the class’s variables (or attributes, these two are used interchangeably in this document). The bottom portion contains the class’s methods (or operations).

Not shown above, but usually used are symbols in front of the variables and methods. These will be as follows:

Visibility Indicator	Meaning
+	Public
#	Protected
-	Private

Figure 8 - Attribute and Method Visibility

An initial value can be indicated for a variable by following the variable’s type with an equal (=) sign and the value. For instance

bShutDown:Boolean = false

If a variable or method is underlined means it is a static variable or method.

Return values from methods are shown by putting them after the method name separated by a colon. For instance the method below startPlayingVideo returns a Boolean.

+startPlayingVideo():boolean

Parameters are shown by enclosing them in parentheses after the method name, but before the return value. For instance the following value method takes two parameters and has not return value (void) since there is none shown.

+setPosition(x:int, y:int)

Constructors for a class are usually shown either at the tops in guillemets (the are the << symbols). Some tools show them after a <<constructor>> and then the class name. Others show the constructors after a <<create>> tag. When a word in UML is in guillemets they are known as stereotypes. Some of these you will see are <<create>> for constructors, <<destroy>> for destructors (for languages that have them) and <<misc>> for indicating all methods shown below this are regular methods.

One other element you may see is (…) or as it is called, an ellipsis. When this appears in the variable portion of the class or in the method portion it means the class has more variables or methods that are not shown. Depending on the view, many tools allow you to shut off or turn back on the showing of variables and methods and even size them so a portion of one or the other is shown.

Interfaces

Interfaces are drawn in a similar manner as classes. The only difference is the name in the top compartment is preceded by the <<interface>> stereotype. An interface is shown below with two methods declared:

Figure 9 - Basic Interface

Relationships

Classes and interfaces often have relationships with other classes or interfaces. One example is a sub and superclass relationship. For instance, below ConcreteEmployee is extended from GeneralEmployee. This is shown with straight lines with a closed arrowheads pointing to the superclass. Below in the figure the abstract class GeneralEmployee is the superclass of the ConcreteEmployee class. Notice it says abstract, we know this because the class name GeneralEmployee is italicized.

Figure 10 - Class & Interface Relationships

A similar relationship is used to shown when a class implements a class. It is represented with a dashed line with a closed arrowhead pointing to the interface that is being implemented.

Associations

Associations are special types of relationships that show a special type of relationship between classes. There are a number of items, most optional, that give information about an association. These are discussed below:

Association Name – somewhere around the middle of an association there may be an association name. The name should be capitalized. If there is a triangle at one end of the association it suggests the direction you should read the association. For instance in the diagram below the ConcreteEmployee has an association to the Product class and the name is Asks For Inventory.
Navigation Arrows – arrowheads at end of an association are called navigation arrows. These, as was stated below, indicate the direction the association is navigated.
Role Name – To help clarify the role each class plays in the association can appear at the end of each association. Typical examples of this are words such as requestor and creator.
Multiplicity Indicator – this indicates how many instances of each class participate in an association. This can be 0 or 1. A range is shown with the range separated by two dots such as 0..2 or 0..*. When ‘*’ is shown it means there is no set limit on the multiplicity.

Figure 11 - Association

Aggregation – Sometime multiplicity is not enough. Often it is desirable to show that a class will contain a collection of another type of class. A hollow diamond at the end of an association indicates aggregation.

Figure 12 - Aggregation

Package Names

A group of classes or interfaces can be associated with a package name by placing them inside of a package. This is shown below where the interface and classes above are shown to be enclosed in a package name:

Figure 13 - Package Definition

This has shown the basics of class diagrams. This should certainly help you to get started in using and understanding the notation when you use them. There are more fine details and specific attributes of class diagrams that have not been discussed.

6Sequence Diagrams

Sequence diagrams show a detailed flow for a specific use case or even just part of a specific use case. They are almost self-explanatory; they show the calls between the different objects in their sequence and can show, at a detailed level, different calls to different objects.

A sequence diagram has two dimensions: The vertical dimension shows the sequence of messages/calls in the time order that they occur; the horizontal dimension shows the object instances to which the messages are sent.

A sequence diagram is very simple to draw. Across the top of your diagram, identify the class instances (objects) by putting each class instance inside a box. In the box, put the class instance

name and class name separated by a space/colon/space " : "

(e.g., myReportGenerator : -reportGenerator). If a class instance sends a message to another class instance, draw a line with an open arrowhead pointing to the receiving class instance; place the name of the message/method above the line. Optionally, for important messages, you can draw a dotted line with an arrowhead pointing back to the originating class instance; label the return value above the dotted line. Personally, I always like to include the return value lines because I find the extra details make it easier to read.

Reading a sequence diagram is very simple. Start at the top left corner with the "driver" class instance that starts the sequence. Then follow each message down the diagram.

Figure 14 - Sequence Diagram

7Statechart Diagram

The statechart diagram models the different states that a class can be in and how that class transitions from state to state. It can be argued that every class has a state, but that every class shouldn't have a statechart diagram. Only classes with "interesting" states that is, classes with three or more potential states during system activity, are usually modeled.

As shown in the sample statechart below, the notation set of the statechart diagram has five basic elements: the initial starting point, which is drawn using a solid circle; a transition between states, which is drawn using a line with an open arrowhead; a state, which is drawn using a rectangle with rounded corners; a decision point, which is drawn as an open circle; and one or more termination points, which are drawn using a circle with a solid circle inside it. To draw a statechart diagram, begin with a starting point and a transition line pointing to the initial state of the class. Draw the states themselves anywhere on the diagram, and then simply connect them using the state transition lines.

Figure 15 - Statechart diagram showing a class’s states

8Activity Diagram

Activity diagrams show the procedural flow of control between two or more class objects while processing an activity. Activity diagrams can be used to model higher-level business process at the business unit level, or to model low-level internal class actions. In my experience, activity diagrams are best used to model higher-level processes, such as how the company is currently doing business, or how it would like to do business.

This is because activity diagrams are "less technical" in appearance, compared to sequence diagrams, and business-minded people tend to understand them more quickly. An activity diagram's notation set is similar to that used in a statechart diagram. Like a statechart diagram, the activity diagram starts with a solid circle connected to the initial activity. The activity is modeled by drawing a rectangle with rounded edges, enclosing the activity's name.

Activities can be connected to other activities through transition lines, or to decision points that connect to different activities guarded by conditions of the decision point. Activities that terminate the modeled process are connected to a termination point (just as in a statechart diagram). Optionally, the activities can be grouped into swimlanes, which are used to indicate the object that actually performs the activity, as shown below.

In the example activity diagram, we have two swimlanes because we have two objects that control separate activities: a band manager and a reporting tool. The process starts with the band manager electing to view the sales report for one of his bands. The reporting tool then retrieves and displays all the bands that person manages and asks him to choose one.

After the band manager selects a band, the reporting tool retrieves the sales information and displays the sales report. The activity diagram shows that displaying the report is the last step in the process.

Figure 16 – Activity Diagram

9Component Diagram

A component diagram provides a physical view of the system. Its purpose is to show the dependencies that the software has on the other software components (e.g., software libraries) in the system. The diagram can be shown at a very high level, with just the large-grain components, or it can be shown at the component package level.

Below is an example component diagram for a reporting tool. It shows the dependency on one external service and the Servlet and JSBC API’s.

Figure 17 - Component Diagram

10Deployment Diagram

The deployment diagram shows how a system will be physically deployed in the hardware environment. Its purpose is to show where the different components of the system will physically run and how they will communicate with each other. Since the diagram models the physical runtime, a system's production staff will make considerable use of this diagram.

The notation in a deployment diagram includes the notation elements used in a component diagram, with a couple of additions, including the concept of a node. A node represents either a physical machine or a virtual machine node (e.g., a mainframe node). To model a node, simply draw a three-dimensional cube with the name of the node at the top of the cube.

A sample deployment diagram is shown below. Notice Websphere is shown as a node.

Figure 18 - Deployment Diagram

11Appendix A – Rational Unified Process

Introduction

The three amigos that created UML didn’t rest. They had defined a strong modeling language in UML, but the process to use it was still not defined. They have come up with a method called the Rational Unified Process (RUP), which was also adapted by the OMG.

One attribute of RUP is to allow the flexibility to use techniques that are appropriate for a particular project. Factors are the type of software (information system, embedded, real time etc.) and scale (1 developer, small team, large team) etc.

RUP naturally works well together with UML but as was repeated many times in the beginning UML is not tied to a process and UML can be used with almost any type of development method.

Phases of RUP

RUP is iterative and incremental. Iterative in that phases are repeated over and over. Incremental in that small pieces are built in each of the iterations. The phases are as follows:

Inception - you establish the business rationale for the system and decide on the scope. Main goal is to get commitment from the project sponsor to continue.
Elaboration – you collect more detailed requirements and do high-level analysis and design to set baseline architecture. You also create the plan for construction.
Construction – this consists of many iterations where in each iteration production quality software is built, tested and integrated that satisfies some portion of the requirements. The delivery may external or only internal. Each iteration consists of the normal phases analysis, design, implementation and testing.
Deployment – this is the work at the end such as beta testing, performance tuning and training. Note this is often called the transition phase.

Experts often suggest iteration should be around 6 – 10 weeks. This of course is very dependent on the nature of the development.

A graphical view of the RUP process is shown below.

Figure 19 - RUP Diagram

One way to look at the iterations in the construction phase is as a series of mini-projects. Each iteration should be treated like a project with an analysis, design, build and test phases. Deliverables should be defined and then integrated as part of the iteration. An iteration is finished when demonstrated to or tested by the user to ensure the iteration accomplished the goal. Again, you are implementing the system for someone to use so his or her satisfaction is the ultimate test of your work.

By doing mini-projects you are accomplishing one goal, reducing risk. Risk often happens because certain issues cannot be done until the end of the development (specifically when using a waterfall method of development). For instance, historically testing was done at the end of development when different sub-systems were integrated. This was always a risk endeavor as the integration and testing work could shine light on some serious issues that could (should) have been caught earlier. Doing smaller iterations of development and doing the integration and testing in each cycle will catch them earlier when it is easier to do something about it.

The overall theme is change should be caught early when its cost is low. Changes late in the development lifecycle are very costly in time and effort. The diagram below is compliments of Rational Software and shows the costs of change in a software system throughout development. Notice how expensive change becomes during the final transition phases. You want to catch any changes early!

Figure 20 - Cost of change in a SW Project

Also, it is encouraged to keep test code and reuse in each iteration. The main portion of work is in developing test code, once it is developed it can be easily reused. See www.junit.org for a good site about using test code, specifically in Java.

Two concepts that definitely one should understand to be a successful developer are Refactoring http://www.refactoring.com/ and Design Patterns. Patterns have numerous sources on the Internet. However, the bible for design patters is the book Design Patterns: Elements of Reusable Object-Oriented Software or otherwise known as the GoF Book (GoF is Gang of Four as there were 4 authors). Some Java specific patterns can be found at http://java.sun.com/blueprints/patterns/.

12Appendix B – CRC Cards

One very useful technique that is recommended by many design experts and that is not part of UML is Class-Responsibility-Collaboration (CRC) cards. This was mainly developed by Rebecca Wirfs-Brock and is part of her Responsibility Driven Design Method

(http://www.wirfs-brock.com/).

It describes a method where you take your basic index card (known as a 4 inch x 5 inch) and separate the face into 3 main areas. At the top you write the name of each class. Below the name you can write the name of the superclasses and subclasses below it. The rest of the face of the card is divided in half. On the left side you write Responsibilites on the right side you write Collaborations. You separate them with a straight line. Finally on the back you write a brief description (if the description does not fit on a back of a card, your class is handling too much).

While admittedly low tech, they allow a very valuable function to occur during the design phase, role playing. During use case development you fill in the ones you know about and do not fill in the collaborations. You then distribute the known cards to several team members. First you start with a known use case and go through that particular scenario. As you talk your way through each member identifies when he has a particular object of a type class that is used. This identifies a collaboration and if no one can identify the class, you may need to fill out a new class. As you work your way through use cases, slowly the classes will be identified and responsibilities filled out and collaborations between classes identified.

The CRC cards are then an excellent input into first developing high level class diagrams and later details class diagrams. Most importantly the CRC cards help the team understand the relationships between classes.

Below is an example of 3 CRC cards that show the classic model, view, controller (MVC) model.

Figure 21 - CRC Card depicting Model-View-Controller

13Appendix C - Argouml

ArgoUML is a free open source development tool for using UML in your development. It is by far the most complete UML tool available free of charge.

It can be downloaded under http://argouml.tigris.org/. You can either install by downloading the binary distribution or selecting the Java Webstart option. You will need the JDK or JRE for version 1.3 (ArgoUML is written 100% in Java). You run ArgoUML by using the following command, 'java -jar argouml.jar'. This is best put into a .bat file and added as a shortcut on your desktop.

The following screen print with description explains the different areas in ArgoUML.

Figure 22 - ArgoUML Screenshot