Toosl for the job: UML Artifacts, and other Techniques I Always Carry

To understand an existing system or a problem domain one needs to break it apart into smaller pieces. UML Artifacts have been my tool of choice for decomposing a system or understanding a business problem and designing a solution to address the issues that come up.

The UML Artifacts I commonly use in almost daily basis include:

When doing analysis:

The Use Case diagram is a very powerful tool for obtaining a very quick assertion of the context under which a system or a business process needs to reside. It is very easy to construct. It is also very easy to explain to a business user who has not necessarily been exposed to diagramming tools for analysis and design of systems. It communicates a lot of important information about behavior and who/what (actor) needs to interact with the behavior (use case).

Conceptual Models help take the main concepts depicted on a Use Case diagram and represent them in perspectives that relate them. Also, they are a great way for identifying possible candidates for behavior assignment later on in the development process.

The State Machine diagram is also a very useful tool for understanding the initial condition (state) of business domain entity and how it can be modified as actions are taken on it. This diagram has helped me identify business rules and conditions for taking or not taking actions that can make changes on the state of domain entity.

System Sequence diagrams are also very useful when clarifying, at a high level, steps and interactions between entities involved in a system.  

In my experience, these tools allow for almost instantaneous feedback about how well I am understanding the domain, the actors in it and the behaviors that the system needs to implement. It is not uncommon that after drawing one of these diagrams on a whiteboard, the people present in the room can

• resolve conflicts or differences of opinion
• highlight better designs or ideas for implementing a solution
• identify questions that require other resources that may not be present at the time
• get every one on, literary, the same page

When doing design:

The UML artifacts that are used more commonly in my daily work include:

• Refined Use Case diagram, with a refined Essential or Detailed Use Cases
• Activity diagrams or Class Collaboration Diagram (now a probably "old school" artifact) for more complex or difficult areas of a system
• Software Design Patterns - these are high caliber type of tools. These are "tried and true" type of solutions to apply for a specific type of problem. They come in many families:
• Creational Patterns
• Structural Patterns
• Behavioral Patterns
• Concurrency Patterns

A word on ERD's

One other artifact that is part of my "must know" tool set is the Entity Relationship diagram (my favorite is Martin's notation - Crows Feet). I use this mostly when discussing a system with IT-oriented audience. A lot of times we end up interacting with colleagues and discussing an existing system or new business domain and the conversation invariably turns to the data model that supports the system. It has become very useful for me to understand how to represent a data model in a diagram.

In more broader terms, the main point is to keep in your tool set a battery of techniques and strategies to help you acquire as much relevant information about a system or problem domain, with the highest degree of clarity, in the shortest amount of time. In my experience, this set of information gathering techniques has worked wonders.

What other tools of choice in your tool set have produced similar results?