Za účelem demonstrace základních principů jazyka GCCS uvažme variaci příkladu systému modelujícího komunikaci uživatele s prodejním automatem známého z []. Návrh systému budeme provádět metodou shora-dolů tak, že postupně budeme dekomponovat systém na elementy popisující chování určitých částí systému - tzv. procesy.
Na nejvyšší úrovni abstrakce rozlišíme dva procesy user a machine. Postupně budeme specifikovat chování každého z procesů, které spočívá ve vykonávání akcí. Procesy mohou vzájemně komunikovat prostřednictvím svých akcí přes tzv. porty. Porty zpřístupňují určité akce procesu ostatním procesům v systému.
Proces user specifikuje chování uživatele prodejního automatu. Pro interakci s prodejním automatem a okolím systému bude proces user potřebovat porty uvedené v tabulce 
.
Table: Popis procesu user na nejvyšší úrovni abstrakce
Proces machine specifikuje chování prodejního automatu. Pro komunikaci s uživatelem a interakci s okolím potřebuje porty definované v tabulce .
Table: Popis procesu machine na nejvyšší úrovni abstrakce
Figure: Sít znázorňující komunikaci uživatele s prodejním automatem
Všimněme si, že oba procesy mají shodné porty (kromě portů drink a beep). Charakter akcí příslušných k určitému portu je však mezi oběma procesy různý. Např. port 1p procesu user zpřístupňuje akci vhození mince, která má výstupní charakter na rozdíl od akce vstupního charakteru přijetí mince, jež je zpřístupňována portem 1p na rozhraní procesu machine.
Nyní přistoupíme ke specifikaci komunikačních vztahů mezi procesy user a machine. To provedeme tak, že porty odpovídajících komunikačních akcí propojíme pomocí tzv. vnitřních sběrnic do sítě. Výsledná síť je na obrázku . Propojením portů pomocí vnitřních sběrnic definujeme synchronizaci. Význam jednotlivých propojení v našem případě vysvětluje tabulka .
Komunikační akce probíhající přes propojené porty jsou neviditelné zvenčí celého systému (hovoříme o tzv. vnitřních akcích). Akce drink a beep jsou naopak pozorovatelné vně celého systému, jelikož jejich porty nejsou propojeny s porty prodejního automatu přes vnitřní sběrnici. Prostřednictvím těchto akcí může systém specifikovaný sítí na obrázku interagovat s okolím.
Table: Význam propojení procesů user a machine
Tím máme hotovu abstraktní specifikaci systému. Dále budeme dekomponovat procesy machine a user na buď přímo popis jejich chování nebo na další podprocesy zjemňující jejich abstraktní specifikaci.
První z možností aplikujeme na proces user.
Chování procesu user popíšeme pomocí stavového diagramu na obrázku . Akce výstupního charakteru jsou odlišeny od vstupních akcí pomocí znaku '.
Figure: Popis procesu user na nejnižší úrovni
Stavový diagram znázorňuje požadované chování uživatele, který nejprve (v počátečním stavu) nedeterministicky rozhodne jakou minci vloží. Pokud vloží 1p, bude moci vybrat čaj (akce 'tea) nebo malou kávu (akce 'little). Vloží-li 2p, bude moci vybrat dvě malé (dvě akce 'little po sobě) nebo jednu velkou kávu (akce 'big), příp. dva čaje (dvě akce 'tea po sobě). V obou případech požadovaný artikl odebere (akce collect), čímž se přes akci 'drink vrátí do počátečního stavu.
Nyní se budeme zabývat specifikací prodejního automatu, tedy dekompozicí (zjemněním) podsystému machine. Představme si, že prodejní automat sestává ze dvou modulů:
Figure: Síť prodejního automatu sestávajícího ze dvou modulů
Systém machine z obrázku rozdělíme na dva podsystémy (viz obrázek ), z nichž každý popisuje jeden z modulů automatu. Na jejich rozhraní umístíme všechny porty systému machine tak, že porty reprezentující akce výběru nápoje umístíme na rozhraní příslušného modulu (big a little na , tea na ). Akce vstup mincí (1p, 2p), odebrání nápoje ('collect) a zvukový signál ('beep) jsou specifické pro oba moduly. Proto porty zpřístupňující tyto akce rozmístíme na rozhraní obou modulů.
Pro vizuální odlišení oindexujeme porty akcí collect a beep dle modulu, kterému náleží. Toto syntaktické rozlišení není nutné, jak je vidět u portů 1p a 2p, u nichž za účelem demonstrace ponecháme stejná jména u obou modulů. Abychom zachovali požadovaný význam akcí collect a beep, musíme uvést vztah s jejich oindexovanými verzemi. To učiníme napojením portů oindexovaných akcí na sběrnici pojmenovanou jejich společným jménem (bez indexu), se kterým pracujeme na vyšší úrovni abstrakce (v našem případě jménem příslušného portu systému machine). Jelikož dvojice akcí příslušných portům , a , nejsou komunikačními páry (příslušné akce mají u obou modulů vždy vstupní charakter), toto propojení nedefinuje komunikační vztah mezi moduly. V případě akcí , tím umožňujeme komunikaci přímo mezi uživatelem (procesem user) a příslušným modulem automatu. Na portu beep nedochází ke komunikaci (na žádné vrstvě abstrakce modelovaného systému). Akce a jsou přesměrovány na volný port beep procesu machine (na vyšší úrovni abstrakce).
Popis chování jednotlivých modulů provedeme podobně jako při definici procesu user pomocí stavového diagramu s návěštími akcí-přechodů (viz obrázky a ).
Uvedli jsme příklad specifikace jednoduchého systému metodou shora-dolů. Alternativně lze postupovat opačným směrem (zdola-nahoru), tj. nejprve začít definicí stavových diagramů procesů a pak pokračovat jejich kompozicí (propojením do sítí). Při tomto postupu bude typické právě tzv. přejmenování portů, které jsme aplikovali na akce (a tedy jejich porty) , a , .
V praxi se typicky provádí specifikace a návrh systému vhodnou kombinací obou zmíněných metod.