Nakonec se okamžik prohlédnutí dostavil a v zásadě je to jednoduché. Představme si server pro prohlížení fotografií:
Use case Prohlížení fotografií zahrnuje (include)/používá (use) zobrazení jednotlivé fotografie. Všimněte si, že Prohlížení fotografie vyžaduje use case Zobrazení fotografie, nelze prohlížet fotografie bez jejich zobrazení. Zobrazení je část funkčnosti.
Naproti tomu Hodnocení rozšiřuje funkčnost Prohlížení, zjevně lze prohlížet fotografie bez jejich hodnocení.
Všimněme si, že Uživatel má vazbu jen na prohlížení fotografií, nikoli přímo na hodnocení. V opačném případě by také mohlo jít o situaci, kdy Hodnocení zahrnuje (include) Prohlížení. Tady už záleží na tom, jaké chování mají jednotlivé use case přesně vyjadřovat.
Další vztah mezi use case je ještě zobecnění (generalizace). Ta klasicky vyjadřuje variantnost, např. use case Přihlášení může mít varianty:
- přihlášení jménem a heslem,
- přihlášení účtem Googlu,
- přihlášení účtem Facebooku,
- přihlášení pomocí OpenID.
Pěkná tabulka porvnání jednotlivých typů mezi use case se dá najít na uml-diagrams.org, na konci stránky v sekci Use Case Relationships Compared. Mimochodem, já si myslím, že autor těch stránek nemá pravdu, když tvrdí, že při vkládání (include) je ta základí (závislá) use case, v našem příkladu Prohlížení fotografií, vždy z principu abstraktní. To že je sama o sobě nekompletní přece nevadí, pořád dává smysl mít její výskyty (instance), koneckonců se vztah vkládání přirovnává k volání podprogramu. A metoda také přece není není abstraktní proto, že volá jinou! Porovnejte to s příkladem Přihlášení.
