Skip to content

Latest commit

 

History

History

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 
 
 
 
 
 
 

< Zpět

Dokumentace architektury č. 2

Struktura dokumentace

Souvislosti mezi kapitolami

  • 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).

System overview

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 č. 2 je EDA.


Functionality

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.

UseCase diagram

Vysvětlivka diagramu

  • Use case (případ užití) - Jde o funkci systému.

Use case

  • Actor (Aktor) - Jde o člověka nebo systém, který komunikuje se systémem.

Actor

  • Ohraničení systému - Jde o grafické vymezení modelovaného systému.

System boundary

Kód diagramu

Kód diagramu je pro tvorbu diagramu přes PlantUML.

Odkaz na textový soubor s kódem: odkaz.


Quality Attribute Requirements

Quality attribute scénáře jsou uvedeny níže, přičemž jsou od sebe odděleny atributem kvality.

Výkon

  • 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.

Elasticita

  • 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).