- Přehled systému
- Architektonická rozhodnutí
- Diagram komponent
- High level přehled modulů
- Diagram nasazení
- Hodnocení architektury
- Přehled systému popisuje o čem ten prodejní systém obecně je, tedy jaká je požadovaná funkcionalita, a jaké jsou požadované atributy kvality.
- Kapitola Architektonická rozhodnutí obsahuje všechny architektonické rozhodnutí spojené s prodejním systémem, přičemž se jedná o podklad pro následující pohledy na systém.
- Diagram komponent znázorňuje komponenty prodejního systému, včetně jejich vazeb, přičemž tento pohled slouží pro celkový přehled systému a jeho částí na konceptuální úrovni (nejde o přehled softwarového řešení).
- High level přehled modulů vychází z diagramu komponent, kdy tento pohled znázorňuje strukturu softwarového řešení prodejního systému (např. znázornění vrstev klientské aplikace).
- Diagram nasazení vychází také z diagramu komponent, kdy tento pohled je využit pro specifikaci fyzické architektury prodejního systému (znázornění softwarových a hardwarových komponent systému).
Popisovaná architektura se vztahuje na aplikaci pro místní obchodníky se stánky pro prodej párků v rohlíku, tedy se jedná o prodejní systém pro takové uživatele.
Zvolená architektura č. 1 je SOA.
Funkcionalita prodejního systému je popsána níže pomocí případů níže:
- UC1: Systém by měl umožnit obchodníkovi se stánky sledovat tržby podle času a místa. Dále by provozovatel stánku by měl vidět tržby za jeho stánek.
- UC2: Přes prodejní systém by mělo jít realizovat slevové kampaně, respektive lze v určitém časovém rozmezí zlevnit specifické produkty. Jelikož k této funkcionalitě má přístup provozovatel stánků, tak i obchodník se stánky, tak systém musí mězi nimi zprostředkovat dohodu o spuštění slevové kampaně.
- UC3: Systém by měl umožnit posílat aktualizace zásob mobilním pracovníkům pro správu zásob (jen ti, kteří jezdí na místo se zásobami).
- UC4: V systému by měla být funkcionalita, která umožní integraci se sociálními sítěmi, takže zákazníci mohou být informováni o tom, že je stánek s hot dogy poblíž.
- UC5: Ze systému by mělo jít exportovat informace ve formátu importovatelném účetními nástroji.
- Use case (případ užití) - Jde o funkci systému.
- Actor (Aktor) - Jde o člověka nebo systém, který komunikuje se systémem.
- Ohraničení systému - Jde o grafické vymezení modelovaného systému.
Kód diagramu je pro tvorbu diagramu přes PlantUML.
Odkaz na textový soubor s kódem: odkaz.
Quality attribute scénáře jsou uvedeny níže, přičemž jsou od sebe odděleny atributem kvality.
- Prodejní systém musí být jednoduchý a běžet na malých zařízeních
- QAS1: Notebook je příliš těžký na to, aby se dal efektivně používat při prodeji hot dogů na ulici.
- Prodejní systém musí zvládnout zátěž s vysokou variabilitou.
- QAS2: Zaznamenávání provedených transakcí (prodej párků) bude hlavně probíhat ve specifický čas během dne (tzn. nebudeme očkávat, že hlavní zátěž systému bude probíhat ráno nebo večer).