En un diagrama de casos de uso presentamos en una caja el programa que estamos haciendo. Dentro de esa caja dibujamos unas elipses indicando qué cosas puede hacer alguien que use nuestro programa. Ese alguien puede ser una persona que use el programa, un aparato externo que se comunique con nuestro programa para recoger o enviar datos o incluso otro programa que no tenga nada que ver con nosotros. Estos agentes externos a nuestro programa y que "hablan" con él se llaman actores. También los dibujamos, como unos pequeños "monigotes", en nuestro diagrama de casos de uso, con unas líneas indicando qué cosas puede hacer cada uno.
En nuestro ejemplo de diseño de un programa de ajedrez, un diagrama de casos de uso puede ser el de la figura
Como todos los diagramas de UML, no hay un diagrama correcto o no. Simplemente hay un diagrama que expresa algo a alguien. El diagrama está bien si es lo suficientemente claro como para que se entienda. Con esto quiero decir que no es necesario poner un diagrama de casos de uso con TODOS los casos de uso. Es mejor un diagrama con unos pocos casos de uso importantes, de forma que se puedan leer bien. Si hay muchos casos de uso, es mejor partirlo en varios diagramas por temas, por cada actor, por cada tipo de cosa que se puede hacer.
Los actores no tienen por qué ser personas fisicamente distintas. Son simplemente "papeles" distintos que puede desempeñar una misma persona. Por ejemplo, si "Felipe Elipe" compra nuestro programa, unas veces hará de jugador y otras veces hará de maestro.
Cuando vamos entrando en el diseño más detallado, es posible que podamos extraer casos de uso secundarios, no tan importantes, pero que nos pueden ayudar a la hora de codificar u organizar las cosas. Por ejemplo, en el caso anterior podemos sacar un subcaso de uso "mover pieza". Tanto el maestro como el jugador tendrán que "mover pieza" cuando enseñan una apertura o cuando están jugando una partida. Los casos de uso "jugar partida" y "enseñar apertura" tendrán unas líneas que los unen con "mover pieza", indicando que para "jugar partida" hay que "mover pieza".