The Unified Modeling Language (UML) supports the entire process of modeling software. Modeling is the designing of software applications before coding. Its aim is to support the process from the requirements issued by users and other stakeholders until the actual coding of the application.

UML is a standardized way of notating different aspects of the process (hence the L for Language). UML helps you specify, visualize, and document models of software systems, including their structure and design, in a way that meets all of these requirements.

Because it is a language, UML is methodology-independent. A methodology defines the process that you use to gather requirements, analyze them, and design an application that meets them in every way. UML supports them all.

What does the language look like?

UML defines twelve types of diagrams, divided into three categories: four diagram types represent static application structure; five represent different aspects of dynamic behavior; and three represent ways you can organize and manage your application modules.

Structural Diagrams

Class diagram: a class definition as used within Object Oriented Design / Programming.

Object diagram: describes the relations between objects (instances of classes), it can be used if class diagrams are found to be too abstract (e.g. classes "student" and "course" will appear in the object diagram as "Sarah enrolls Project Management Course").

Component diagram: describes the software architecture, mapping of software components

Deployment diagram: shows the hardware for your system, the software that is installed on that hardware, and the middle ware used to connect the disparate machines to one another.

Behavior Diagrams

Use case diagram: a way to structure user interaction with the system (great for notating user requiremenst)

Sequence diagram: describes the flow of logic within your system in a visual manner

Activity diagram: used for business process modeling, for modeling the logic captured by a single use case or usage scenario. In each box an activity is represented and arrows from one to the next indicating next steps or alternatives.

Communication diagram: shows the message flow between objects in an OO application and also imply the basic associations (relationships) between classes.

Statechart diagram: document the various states that an object may be in and the transitions between those states.

Model Management Diagrams

Include Packages, Subsystems, and Models. These are UML constructs that help you organize all other diagrams.

At the end of the 1980s and the beginning of the 1990s the software engineering community had high hopes for CASE tools. „If we can automate everything, why not software creation itself?" Enter Computer Aided Software Engineering (CASE). James Martin even put the use of a CASE tool as a pillar in his Rapid Application Development method.

However, how it often goes with silver bullets, the tools didn't bring the much needed rise in productivity and quality. In mainstream software engineering it went silent on the CASE tools. But not for long…

The intoduction of UML (Unified Modeling Language) brought a couple of your ago new life into the CASE tools. Computer Aided Software Engineering covers the entire process from requirements determination to the actual coding, and all intermediate steps. CASE tools offer many benefits for programmers coding. As user requirements continue to drive system complexity to new hights, the CASE tools enable us to abstract away from the entanglement of source code, to a level where architecture and design become more apparent and easier to understand and modify.

The use of UML in the tools have made it possible to exchange between different tools, and have created a proper foundation for CASE in general. The popularity of enviroments like Rational Rose indicate that this time the tools may deliver what they promise.

Related links

Comprehensive CASE tool index

Use cases are a way to structure the information about requirements for a new information system. The term itself has a high level of appeal, "cases about how to use the system". The technique is semi-formal, it offers a framework for structure, but one can use plain language to describe the requirements.

It is this loose nature and the focus users of a system that makes this technique popular withing agile software development approaches like extreme programming.

What is a use case?

This technique is focussed around the communication between an information system and its users. A use case is a collection of interactions between a user and the system. The user has a specific goal to reach; so he or she is performing the interactions to achieve something. In use case language the user is called an actor. Actually the actor can also be another computer system that communicates with the system you want to build.

Every actor has one or more responsibilities. "Making sure the money rolls in by invoicing on time" e.g. To carry out this responsibility the actor sets some goals, that it tries to achieve by using the new system.

What is an interaction?

The new system printing on your screen "Hello world" is a form of interaction. Spitting out the DNA code for the cure of some dissease is also an interaction. You can use the term interaction for one interaction or a sequence of multiple interactions. So, "press a button" is an interaction, but so is "press a button, write on the screen".

The thing to notice is that a sequence of interactions is just that, a sequence, so no conditions, no if-this-then-that, just one single flow. This is also called a scenario. So, "scenario" and "sequence of interactions" can be considered the same.

During one high level interaction there can be a need to have several possible scenario's available, for certain situations a specific scenario. "When a customer calls for his invoice, I use scenario A, and when he calls for a new order I use scenario B". A collection of scenario's for a certain interaction is called a use case. In a sense a use case describes the "how to" instructions to reach a goal.

The difference between use case and scenario?

The use case takes place on a higher level of abstraction than the scenario's. The use cases can make use of one or more actors (user and/or systems) and a scenario discusses the interaction of one actor. So, to summarize…

The use case contains:

1. One or more actors

2. Goal

3. Scenarios used

The scenario contains:

1. One actor

2. Goal

3. Conditions under which this scenario occurs

4. Scenario result

Related articles

Structuring Use Cases with Goals

There are several tools available that will make your life easier by automating the requirement management process. In the end, they can't do the job for you - as seen, the tasks are complex and require high level of abstraction and analytical thinking. But these tools can keep track of things where human memory fails, and can perform the steps that need to be repeated.

To begin with, a database which provides proper access to all members of the development team is by far a better solution that passing around post-its in the office. So, such a tool should facilitate communication, with the office colleagues as well as with overseas department. Also, it should keep things organized, and allow you to identify a certain requirement and trace it back to its origins, even after having worked on the project for five years. It should also store how many changes has one requirement suffered, who initiated the changes, who approved them, when did this happen, and who performed the analysis of the impact the change would have on the entire system.

Some tools are less sophisticated than others, but still considerably useful - such as the old checklists. You will find many templates available on the Internet, you can start by using any of them and refine and adapt them to your needs. You don't know if you can actually use them, until you try. You can also see how the requirements management is integrated in the project management software you are already using.

There are also several products designed specifically for requirement management, such as RTM Workshop and Caliber-RM. They include a database with custom-defined accessibility access, and can be easily integrated with other tools (such as importing a Word document, since you'll do a lot of text writing, or combining with a project management software). They are quite intuitive and easy to use, and have some powerful features, such as underlining "suspect" requirements and defining traceability options.

They can be helpful, but they won't do the job for you, particularly where highly conceptualized and abstract thinking is necessary.

Remember that we've said, right at the beginning, that requirements have to be measurable, otherwise they are useless. Also, they need to be traceable and testable. From one diagram to another, we've seen how you can trace your requirements so you don't forget why you need such a complex option, and you don't feel tempted to replace it with an easier one, which would not suit the client.

One of the most common problems is called "requirements creep" - requirements that "creep" in, nobody knows why or from where, and they stick around, suffocating the options. This is why you need to keep track, in writing, of all the modifications made to all documents. Some requirements are legitimate, and were brought in later on, some were modified for good reasons, so you need to know, at all times, how to differentiate these from the statements that just came out of nowhere.

Another common trap is the so-called gold platting - more options, which bring very little value to the product, but increase the cost considerably. Some clients may be thrilled to have these options, but they won't miss them very much if they're not there - so you need to be careful about them.

A common sense rule says that you should be able to trace a requirement from the beginning to the finite product, in every stage. It's not enough for it to be present in the first and last stage, and it needs to occur in all the rest, to make sure it stayed consistent.

The functional criteria are easier to test, since you can see if the application fulfills the respective function or not. It's a bit trickier with the non-functional requirements, which is why you need to insist on making the measurable for the beginning. Instead of saying "the operation should be performed in the shortest possible period of time", define a time frame, in seconds, or minutes or whatever applies. Instead of saying "user-friendly" say "85% of second-grade children should be able to use the application". If you phrase it correctly from the beginning, you will have no problems testing it whenever necessary. Also, be realistic - don't ask for 100% success rate, particularly when you know that the system will have to perform the operation thousands of times per day. On the other hand, if you're dealing with maintenance for army rockets or with huge transactions involving the social health insurance budget for a large population, then you may want to aim for a success rate of 99%, or you'll be in trouble. Install as many additional safety systems are necessary, without putting too much strain on the application.

The security criteria are usually the most difficult to test and prove - it's fair to assume that, no matter how tight your security system is, somebody, given enough time and the appropriate knowledge, will find a way to cheat it. Again, defined your requirements realistically and make sure they are testable. Alternatively, provide additional upgrades whenever somebody reports a security breach - many developers do that.

Organize tests as often as possible, for the entire development duration - if a problem occurs, you want to identify it as soon as possible. Keep your original use cases readily available - they can be easily turned into test-case diagrams whenever necessary, at any phase.

Sequence diagrams express interactions among classes in terms of messages exchanged for a period of time, and, as we've seen, they fall in the category of interaction diagrams.

When you're done with the robustness analysis, you have defined most of your objects, their static relations and some of the dynamic relations. Now it's time to refine the diagram again, and to bring it closer to how the actual code will look like. Sequence diagrams can also be used to validate use cases.

You have four types of elements in a sequence diagram: objects, methods, messages and text. You will take the objects from the robustness analysis, and you can include their class, if you need to. The methods are shown as rectangles, while messages are arrows (messages are what stimulates an object to perform a certain action). Finally, the text comes directly from the use case.

This is the moment when you're most likely to get stuck, particularly if you've made mistakes so far. Make sure you allotted enough time to this stage to go back, if necessary. You will definitely need for attributes - check them out carefully, particularly if you plan to skip the class diagram and to move directly to the code after this.

When you draw the diagram, leave the methods last. You will need to check them with the controllers from the robustness analysis, but remember that one controller may translate into more than one method. Also, this is where you may decide that you can use some patterns already available, or that you can create some new ones that would be helpful.

As long as the use case diagram corresponds to the robustness analysis and the analysis corresponds to the sequence diagram, you are following your requirement specifications and will obtain what the client wanted. Otherwise, go back and see what you've done wrong. You cannot be sure that you've covered everything until you've drawn sequence diagrams for each use case, and then check the diagram with the text from the original use case, just to make sure that you didn't get "lost in translation".

Check your message carefully, and make sure that, for each of them, you understand which object is in control (and why, for all that matters). This is where you make some crucial decisions for your code - try to estimate how long a method takes, and if there isn't a shorter option available. Also, check the potential blocks or bottlenecks where your application will choke, and correct them at this stage. The sequence of the diagram is no longer an abstract drawing - this is what your code will also look like. Make sure you apply correctly all the principles of object-oriented design - you can't enforce them later on.

When everything was checked one hundred times, you can move on to the class diagram - which describes the types of objects and the relationships among them. It used to be called "object model", because this is exactly what it does - it models the class structure and content. This is the actual model of the code. All classes have names, attributes and operations, and the relations among them are the typical ones, such as inheritance, association, aggregation and containment. For complex classes, you can use a statechart diagram.

The use case diagrams are, of course, commonly used in the requirement management process. The use case diagram describes the relations among actors and use cases - and these will be the two main elements of this diagram.

You should not confuse the actors with personas - a term first introduced by Alan Cooper in "The Inmates are Running the Asylum". A persona is an embodiment of an imaginary user, described quite in detail (his tasks, goals, knowledge level, skills, you can even name him, if you want).

It is safe to say that a persona is to an actor what is a usage scenario is to a usage case - an instance, or a "snapshot". If your marketing department has some statistics or demographic data, this is the place to use them. This may look like an office game, but correct use of personas can alter your perception of the application considerably. For instance, think that you have two users who have to perform the same action (two instances of the same actor), but one of them is computer illiterate, while other uses the computer regularly. And perhaps a third persona, who is a familiar with the previous version of your program, as well as with the software from your competition, because he has worked in this field all his life. They are the same "actor", but their interactions with the application will be completely different. This will give you a pretty good idea how the users react. If you use them, make sure you create the person before, and the use case later, based on the persona. You don't need to write all the possible scenarios - in fact that would be impossible - but make sure you include some of the most likely failure options.

The use case diagrams are quite simple and intuitive - they include the actors, the use cases and the boundaries of the application. Actors are always placed outside the boundaries, since they will always be external to the application. You can use lines or arrows to indicate the relations among them - in UML, indicating the flow is not mandatory. You can also compile an additional glossary of the terms used in the diagram, which may prove useful later on.

The key word in this phase is always "interaction". How the actor interacts with the application, what the application detects and what is its response.

When you are satisfied with the use case diagram, or everybody has had enough of the brainstorming for creating imaginary friends, you need to check the result using the robustness analysis. If everything works well, you can move on to the sequence diagram, if not, you can return and work on the use case diagram some more.

For the robustness analysis you need to identify the objects (which are still depicted in the form of literary text in the use cases) and to divide them into three main categories: boundary objects (that the actors use to interact with the system - interface, menus), entity objects (which belong to the domain model) and control objects or controllers (these aren't necessary objects, they connect the objects from the previous two categories; also, they are used to localize and store changes, sometimes, they disappear when the process comes to an end).

There are two main reasons for performing the robustness analysis: to check that you didn't let yourself carried away with the use cases and include actions that could not be performed by the respective objects, and to refine the model obtained, if it proves correct, to bring it closer to the design stage.

Now, in order for the robust analysis to validate your use case diagram, the relations must be in the correct sequence: the actors can interact directly only with boundary objects; boundary objects interact directly with actors and controllers, controllers can interact with boundary objects, entity objects and with other controllers, while entity objects can only interact with controllers.

Some quick hints before you get lost here: if you wrote the initial use case correctly, in the active voice, you probably find a lot of sentences that include the sequence Subject - Verb - Object, which, in the robustness analysis, corresponds with the sequence Boundary object - Controller - Entity object.

Usually, you need between three to five controllers per use case. If you have fewer, you probably didn't include all the options, if you have more, you need to break down the use case is smaller bits.

When you're done and everything falls into place, you can move to the sequence diagram.

We have mentioned UML a couple of times before, it's time to take a look and see what it is.

UML stands for Unified Modeling Language - a standard language for specifying, constructing and documenting all sorts of systems, software or other types. UML was initially developed by James Rumbaugh, Grady Booch and Ivar Jacobson in order to give all developers a standard communication language in which they could discuss the general architecture of the program and the best solutions available. As it proved a remarkable software design tool, UML became the official standard for software architecture in 1997, after receiving the support of the biggest names in the industry, such as Microsoft, Oracle and IBM.

UML is independent of any programming language, but it encourages the use of object-oriented tools. The notation is big, but very flexible - that's the idea when being "universal", of course. So, UML is a notation - not a methodology, not a process or anything else, and that's important to keep in mind. You will still need a modeling process, and how you approach it is entirely your choice. Basically, UML defines a number of diagrams and their meaning. It may not seem like much at first glance, but it means you've never had to work with large teams of developers - who, basically, speak different languages, making communication impossible. Each diagram was created with the purpose of allowing all the developers, as well as the clients, get a view of the system. How abstract is your representation is your decision alone.

There are twelve standard UML diagram types, which fall into three categories. The model management diagrams include Models, Packages and Subsystems. The structural diagrams include Class, Object, Component and Deployment. The behavior diagrams include Use Case, Sequence, Activity, Collaboration and Statechart.

These diagrams should not be scary or confusing, on the contrary, even if some of them may get really big. Keep things simple and organized with some very simple tricks. For instance, use colors to draw attention to one thing or another. Don't let your lines intersect, this is messy and confusing. If they must cross, use a "bridge" to show that they do not intersect, in a three dimensional view. Make a different diagram for the primary structure and behavior and then move on to present the details on a separate diagram.

No matter which method you use, it's generally a good idea to start with the dynamic models, such as the use cases, ad to move on from them to static models, such as class diagrams. In this way, you won't have to "guess", by looking at the static model, which class could be used for which operation. The use cases, which are driven from the real needs of the clients, will guide you through the process. Also, in this way you will make sure that everything can be easily traced back to its origin quickly.

The UML 2.0 specifications are even more focused on architecture and will allow even easier control and organization, with the introduction of Infrastructure, Superstructure, Object Constraint Language and UML Diagram Interchange.

If you've been around for a while, you've probably heard about patterns. As the name implies, patters help you cut time and costs by re-using the same solution, whenever the same problem occurs. So, a pattern identifies the problem and its context, and the best possible solution to it, in such terms that you can apply it again whenever necessary. In software design, patterns can be lines of actual code, but, more often, they are a textual description of the solution.

The pattern craze originates in 1977, in Christopher Alexander's "Pattern Language", and has continued since, with patterns used when they are necessary, and sometimes in excess, just to show off. A pattern language is the collection of the patterns used to address a bigger problem, such as, in our case, requirements management. All the stages necessary for solving a problem, as well as the actors, objects and tools necessary, are described in the respective process.

There are some tricky issues in using patterns. First of all, you have to identify them - which is done by analyzing the case model or the event response. When you have a pattern, you need to define it in such a way, as to allow instant recognition whenever you are faced with the same problem again. This is done by using several modeling methods, sometimes combined, in order to avoid the work of re-analyzing and re-defining a pattern, once you have already dealt with it.

Because they are not bits of code, but literary descriptions, the patterns are very flexible, and can be modified and adapted as the context of the problem requires. You should not think of a pattern as a solution to your problem, but rather as a step-by-step guide to solving the problem.

There are many good books out there that contain very useful, common patterns. You should start by reading some of them, until you are familiar with the concept, and able to identify at least some of the most common patterns. "Design Patterns: Elements of reusable Object-Oriented Software" by Erich Gamma, Addison-Wesley, 1994 and "Object-Oriented Software Engineering - A Use Case Driven Approach" by Ivar Jacobson, Addison-Wesley, 1992, are two very useful books for object-oriented developers. "Data Model Patterns - Conventions of Thought" by David Hay, Dorset House, 1995, provides a wider background, with solutions for different types of businesses.

Since the key to using patterns it to think abstractly, you'll need to do a bit of reading in order to familiarize yourself with the concept, and to understand how to make useful abstractions from a given problem. It will be a while before you can use patterns efficiently. In most cases, you will not be using the patterns created by other people, but your own, the ones you have been faced with before, because these are easier to remember and, probably, specific to your line of business. Usually, a pattern is considered as such when it has been used for at least three times to solve a similar problem. On the long run, patterns can save you a lot of time, but the main problem is that you are probably running a tight deadline and under a lot of pressure from the very beginning, and thus you don't have time to look which pattern should be used for which situation.

All patterns look a bit similar, even if they are literary texts. All of them have a name - if you are able to name them suggestively and consistently, you are more likely to find what you need quickly. They include a description of the problem, of the context, and of the intent (this is actually a sentence or two about what the pattern does). Then you have the so-called "forces" - which are a bit like guidelines for how to implement the solution. They help you keep everything in order and under control. Of course, you have the solution, since this is the whole point, and the resulting context, which describes the state of the system after the use of the pattern. You can also include examples and samples of where you've used the same pattern before, in order to make things clearer. Try to keep your document as short as possible - you don't want to read a short novel, when time is of the essence. A good method to identify when a pattern can be used is to match its name, or any other of the above elements, to patterns already created (assuming you've named them correctly and consistently) and to check if you apply it to the given situation.

In writing software requirements, patterns are useful precisely because you don't have a lot of time to complete this stage. We've seen how important it is to prioritize your requirements, but this is a time consuming process. Sometimes it's a good idea to use a pattern to do this for you, in the same way as emails are prioritized according to different criteria. Another pattern available for the requirements is called Presentation, and it allows the display of data, when it is necessary to communicate it to human users. The Presentation pattern was created in order to allow you to focus on what data must be displayed, and not the method how to display it.

As you get more experienced in the use of patterns, you are sure to create some of your own, custom made for your specific needs and easy to identify and use whenever necessary. It may be a while before you can use patterns for their full benefits, but then you'll see it was worth the patience.

We've seen before that you will need to take some vague specifications from the client, and turn them into complete, measurable, traceable and unambiguous requirement specifications. No need to panic; you can make your life easier at this point with a use case report.

A use case is used to define a series of interactions between external actors (the users or another system) and the system in question (your piece of software). The use case always focuses on a goal, and it ends when this goal is completed. Besides the main series of interactions, it can also include alternative versions (other series of interactions that will fulfill the goal) and versions that will cause failure. In the end, it will give you a very clear sequence, written in natural language, easy to understand. You can move on by taking a "snapshot" of a use case, called a scenario - which is one specific instance of the use case - one single path that takes you from the beginning to the end, selected from the various paths and combinations available to fulfill the goal.

Use cases are the basis for creating patterns, or you can organize them into diagrams - in many cases, a better alternative to long text in natural language, or use them in connection with UML - we'll cover all versions later. They are a good tool to help you keep track of each requirement and its current status.

Once you have a use case, you need to make sure that it is indeed important, not one of the useless conditions that crowd your project, even if nobody can remember where they originated. A very simple and effective method, called Quality Function Deployment (QFD) will help you identify which are the most important options for the client, and which can be eliminated. Give users (or user surrogates) a list of the use cases and a certain number of points (or a sum of cash, to make it even easier to understand) to assign to the use cases, in order of the importance. Make sure you include all the types of users (every group of actors involved), otherwise it's not relevant. In some cases, you may need to organize a hierarchy of the groups of actors - for instance, give more points (or cash) to the group that is likely to use the program more often than the rest. Balance the number of points obtained by each function against the costs of developing it. After that, the results are pretty obvious and easy to interpret.

Because the use cases are so focused on the client, they are often turned into help files later on. In fact, this is one of the key aspects of working with them - you actually write the help files and the user documentation before you even started work on the program. It may seem a bit backwards, but it is a great method of insuring the client's satisfaction, which is, after all, the whole point.

While you are having fun with points and evaluation, don't lose sight of a major issue: the use cases have to remain testable and traceable, otherwise they are useless.

Pay attention when you write the use cases, and don't make them too abstract. The client should be able to understand them at all time. If you find yourself using the passive voice, you made a mistake - you need to describe what the user does, and what the reaction of the system is. Do not write from the point of view of the system, but make sure to include its response.

Also, you need to know when to stop - you can't possibly model all the situations, and you don't need to, since you can include them, in a form or other, in a use case. So, make sure you don't have so many use cases that they waste you more time than they might save.

You can use a prototype whenever necessary. There are various opinions out there about how a prototype should be used. The most common approach is to use the client's specifications to quickly design the interface, then use this prototype for the use case report. From this point on you no longer need the client's input (hopefully) and you can turn the use cases into UML diagrams (we will cover these later on), such as the robustness diagram and the sequence diagram, both of which are dynamic. These turn into a class diagram, which is static and can be turned into code.