Začneme jedním modelovým příkladem: Představme si, že je třeba zákazníkovi dodat informační systém a vzhledem k výsledkům předcházejících projektů se zjišťuje, že dodaný systém by mohl využít stávajících naprogramovaných funkcionalit převzatých z předešlých projektů, tj. mohl by využít již hotových artefaktů z vnitrofiremní knihovny. Jako další fakt se zjišťuje, že řešený systém bude používat jiný externí systém dodávaný třetí stranou. Informační systém se tak skládá ze tří jasně oddělených částí:

• první část systému je již hotova a má se pouze opětovně použít
• druhá část se musí navrhnout a naprogramovat
• třetí část systému je dodávkou od třetí strany a pro náš systém se jedná o externí systém

Otázkou je, jak se obě tyto tři části systému promítnou do tvorby USE CASE modelu (model případů užití) daného informačního systému. Zde totiž nastává jeden zajímavý zřetelný rozpor spočívající v těchto skutečnostech:

• vývojáři, kteří mají tvořit nové části systému a opětovně použít již zhotovené části, soustřeďují svou pozornost na "nové" části systému a "staré" části jsou pro ně víceméně nezajímavé (tyto části nevyvíjejí a pouze je použijí)
• u externího systému je středem zájmu vývojářů způsob spolupráce tohoto systému (například interface apod.) s řešeným systémem a ostatní není až tak zajímavé (není předmětem řešení)
• zákazník chce vidět celkovou funkcionalitu systému, tj. chce vidět systém jako celek a to jak nové tak staré části "dohromady" včetně dodávky systému od třetí strany

• funkcionality řešeného systému jsou vyjádřeny pomocí nových případů užití
• funkcionality již vyřešené a hotové se importují z jiných balíčků (Package), které se přilinkují do daného řešení
• externí systémy se volí jako prvky Actor se stereotypem odpovídajícím jeho postavení - nejčastěji se stereotypem "externí systém"

V našem příkladu bychom mohli zavést dva "podtypy" typu elementu Actor, a to "živá obsluha" (implicitní typ) a druhý nový podtyp "externí systém" (tj. "neživé okolí" systému). Každý dobrý CASE nástroj pracující v UML nejenom že umožňuje tvůrcům modelů zavést stereotyp k danému typu prvků modelu, ale navíc umožňuje tyto prvky s jiným stereotypem odlišit i graficky. Při zavedení nového stereotypu tedy můžeme prvky spadající do tohoto stereotypu znázornit jinou grafickou ikonou.

Také Enterprise Architect umožňuje zavádět nové stereotypy a k nim i nové grafické vyjádření. Postup je následující: Ve menu položce Reference zvolte Stereotypes a vyplňte údaje pro nový stereotyp. Můžete také vybrat soubor typu EMF resp. WMF, který si vytvoříte například v nějakém "kreslítku". Získáte tak nový stereotyp i s jiným grafickým vyjádřením. V našem příkladu zvolme jako modelovou situaci, že se jedná o nějaký informační systém například soukromé právnické kanceláře, který používá i externí zdroj údajů. Následující obrázek jsme vytvořili pomocí exportu z EA do HTML:

V diagramu existují dva prvky Actor, jeden je "Obsluha" a druhý se stereotypem "externí systém" se nazývá "External System ARCHIV 1.0". Tomuto stereotypu byla zavedena jiná grafická podoba ve tvaru ikonky PC, stejnou ikonku můžeme přiřadit libovolnému jinému externímu systému s jiným názvem. Všimněte si, že případ užití "Zpracování textů" náleží do prvku Package "Text Engine", který byl do modelu (jakože) importován z nějakého již řešeného modelu. Navíc autor pro tento diagram zvolil i jinou barvu tohoto prvku (pouze v tomto modelu a pro tento prvek), aby zvýraznil jeho odlišnou pozici vzhledem k řešení. Pro modelování však není důležitá tato barva, ale příslušnost do opětovně použitého a již připraveného prvku Package "Text Engine".