Checkpoint 1

Odevzdává se SRS systému (viz. šablona http://www.csc.villanova.edu/~tway/courses/csc4181/s2010/srs_template-1.doc). Není nutné vyplňovat všechny sekce, ovšem přečtení vám pomůže uvědomit si potenciální problémy, které při návrhu systému mohou nastat. Výsledné SRS však musí nutně obsahovat

• pro jaké uživatele (druhy uživatelů) bude systém určen (je nutné mít alespoň 2 funkčně různe uživatele),
• jaké bude plnit funkce (k čemu bude jednotlivým druhům uživatelů sloužit)
• jaká bude mít systém omezení (k čemu sloužit nebude, ačkoliv by to mohlo být očekáváno)
• doménový model (diagram)
  • navrhujte s ohledem na očekávané funkce systému, autentizaci do systému a další omezení
  • obsahuje minimálně 5 relací (DB tabulek) - několik vazeb 1:N a minimálně jedna vazba M:N (M:N vazby se nepočítají do celkového počtu relací).
  • je ve 3NF
• systém navrhněte dostatečně komplexně - tedy tak, jak byste jej jako uživatelé chtěli používat.
• v rámci tohoto předmětu stačí implementovat jen část funkcionality. Zamyslete se nad tím (a v dokumentu zřetelně vyznačte), kterou funkcionalitu chcete implementovat vzhledem k požadavkům na odevzdávanou aplikaci.

Vyplnit relevantní sekce stačí stručně a výstižně (očekáváme cca 1-2 strany vlastního popisu).

Nabídka semestrálek

Pro představu, jak vypadaly typické specifikace v minulém semestru, se můžete podívat na následující dokumenty. Neřiďte se obsahem, mohou obsahovat chyby. Pozor, u těchto specifikací ještě nebyla vyžadována řádná struktura, jako je u šablony výše - prosím, použijte tuto šablonu pro strukturu Vašeho dokumentu.

tisy.pdf planovac.pdf isas.pdf isas-model.pdf

Dále se odevzdává a prezentuje fungující zárodek aplikace (Projekt kompilovatelný Mavenem) obsahující:

• JPA entity odpovídající doménovému modelu
  • dědičnost (vybrat vhodnou strategii) nebo alespoň @MappedSuperClass
  • použití alespoň tří z následujících technik/funkcí:
    • ordering (uspořádání kolekce podle atributu),
    • pojmenované dotazy,
    • kaskádní persist/update/merge/remove,
    • složené primární klíče
    • mapování výsledků JPQL/native dotazu
    • Criteria, případně i Metamodel API
• business logiku komunikující s těmito entitami a s jasně definovaným rozhraním k prezentační vrstvě, a implementací části tohoto rozhraní tak, aby bylo možné na této části ověřit správnou funkci, včetně výše vybraných JPA technik/funkci. Je tedy třeba mít navrženo:
  • jak bude business logika využívat navržené JPA entity ?
  • jak bude vypadat komunikace business logiky a prezentační vrstvy (např. DTO) ?
  • jaký bude transakční model aplikace ?
  • jaký bude scope jednotlivých částí business logiky ? Proč ?
  • … apod.
• testování business logiky a JPA vlastností (jednotkové testy).