The Use Case technique captures information about how a system or business currently works or how you want it to work. Although not a true object-oriented approach, the Use Case technique helps you build scenarios which model the processes of the system. It is an excellent way to lead into object-oriented analysis of systems.

A Use Case for Every Scenario: Typically, Use Case diagrams are modeled for every scenario in the system or business. Each Use Case can be defined with text describing the scenario. You can also define the scenario with the sequence of steps performed in it or with the conditions that exist before the scenario begins or after it completes.

Actors as External Agents: An actor is considered an external agent to a system: someone or something that requests a service from the system or acts as a catalyst for something in the system to occur. UML specifies that the actor is a class of objects, not an instance of a class (or object). The actor is represented as a class with a stereotype of actor.

This tutorial: Examine existing Use Cases, and build a Use Case diagram.

A Sequence or Collaboration diagram is modeled for every scenario in the system. Whereas the Use Case diagram models a business view of the scenario, the Sequence diagram contains implementation details of the scenario, including the objects and classes used to implement the scenario and the messages passed between the objects.

Typically one examines the description of the Use Case to determine what objects are necessary to implement the scenario. If you have modeled the description of the Use Case as a sequence of steps, then you can 'walk through' the steps to discover what objects are necessary for the steps to occur.

UML Sequence Diagram: The Sequence diagram uses vertical lines to represent objects and horizontal vectors to represent messages passed between the objects. At first, you can want to label the message lines in the Sequence diagram with the business name of the message, like the Use Case step. As your design progresses, you can want to label the message lines with the name of a method that one object is asking the other to invoke.

UML Collaboration Diagram: The Collaboration diagram represents an alternate view of the Sequence diagram. The Collaboration diagram shows how the objects in the scenario interrelate, giving the modeler the ability to show detail, such as visibility. Collaboration diagrams are good for understanding all of the effects on a given object and are good for procedural design.

This tutorial: Build a simple Sequence diagram and sister Collaboration diagram.

The class diagram is the main static analysis diagram for a system. It specifies the class structure of the system with relationships between classes and inheritance structures.

In a Use Case-driven approach to OO analysis, the class diagram is developed through information garnered from the Use Cases, the Sequence diagrams, and the Collaboration diagrams. The objects found during problem-driven analysis lead the user to model the classes they instantiate. The links among objects provide a map to modeling the relationships among their classes. Collaboration diagrams provide the most useful information, in that they show interactions among objects to solve a particular problem.

This tutorial: Build a simple class diagram.

Whereas Interaction and Collaboration diagrams model dynamic sequences of action among groups of objects in a system, the State diagram models the dynamic behavior of a particular object or class of objects.

A State diagram is modeled for all classes deemed to have significant dynamic behavior. This type of diagram models the sequence of states an object of a class goes through during its life. The State diagram captures the object's received stimuli, responses, and actions.

For example, the State diagram models an object's behavior in terms of what state it is in initially and what state it transitions to when a particular event is received. It also models what actions an object performs while in a certain state.

This tutorial: Build a simple state diagram in this tutorial.

Use the Component diagram to model the structure of the software, including dependencies among software components, binary code components, and executable components.

The Component diagram is drawn as a graph of components, sometimes grouped in a package, and the dependencies that exist between components (and packages of components).

This tutorial: This is not covered in this tutorial.

Use the Deployment diagram to model the configuration of runtime processing elements and the software components, processes, and objects that live on them.

In the Deployment diagram, you model the physical nodes and the communication associations that exist between them. Each node can contain runtime component instances, indicating that the component lives or runs on the node. You can also model the objects that are contained in the component.

This tutorial: This is not covered in this tutorial.