Zero Result

Nultý návrh podoby výsledného produktu (zero stupid)

prosím přečíst nejprve celé, než přistoupíte k poznámkám a detailům

Základní myšlenky

• Nainstalovaná Java, Virtuoso (DB instance, administrátorský přístupový účet, přístup přes JDBC) a případná dostupnost internetu budou softwarové požadavky, žádný instalátor pro tohle nebudem dělat, poskytneme jen know-how, případně přiložíme instalační soubory na CD. Přidáme kuchařku popisující typickou instalaci a konfiguraci (resp. odkážeme na stávající kuchařky).
  
  
  
• Vše ostatní bude v Javě (nebo z ní ovladatelné) v jednom adresáři aplikace na CD, uživatel si to nakopíruje na lokál
  
  
  
• Baťák pro Windows, script pro Linux spustí první aplikaci v Javě, jak je obvyklé (v zadání zatím žádné info o multiplatformitě)
  
  
  
• Tato první aplikace představuje kontrolní, monitorovací a spouštěcí proces, který bude ovládat vše ostatní, prvořadá je robustnost
  
  
  
• Tento supermonitor bude spouštět unifikované kontainery našich komponent, kontainery mají minimalizovanou vzájemnou komunikací od začátku designovanou jako meziprocesovou (jen pro diagnostiku stavu nebo progressu nějaké činnosti a základní signály (zprávy mezi procesy), naše komponenty budou primárně komunikovat přes permanentní úložiště DB, bez ní je náš SW k ničemu
  
  
  
• Kromě kontainerů lze kód ještě spouštět v rámci WS a WebServeru na našem aplikačním serveru
  
  
  
• Aplikační server běží opět v rámci našeho kontaineru
  
  
  
• Komponenty z našich diagramů mající mezi sebou interface v Javě, které je nutí komunikovat v Javě napřímo budou v jednom kontaineru, jinak komunikují přes permanentní úĺožiště a jednoduché signálování, tento design kontainerů ponechává možnost to spouštět ve více procesech(může se podařit to pustit i jen v jednom procesu), je k tomu jednotný háv
  
  
  
• cross-technologie typu logování použijeme robustním způsobem: využijí DB, pokud nepude, pak zapisují do souborů atd., jsou nám v opačném případě přínosem?

o žádném vhodném frameworku, který by to dělal nevím, všechno to je jednoduché, vděčné na UML apod., není nebezpečí, že se budeme trápit s externím frameworkem a takto investovaný čas nemusí být efektivní

Konkrétně

• Baťák pro Windows, script pro Linux spustí první aplikaci - supermonitor v Javě
  
  
  
• Ta pustí první komponentu, která zkontroluje sw podmínky, zda-li je nainstalováno, případně nainstaluje co je potřeba a co umí konfigurovat (DB, WS apod.)
  
  
  
• Pustí se pak kontainer s aplikačním serverem ve kterém je serverová část GUI a WS, vše maximálně předkonfigurováno (u WS bude možná nutno měnit cfg soubory před spuštěním konkrétní instalace)
  
  
  
• Pustí se náš čistící engine nebo bude supermonitor čistícím enginem sám (to není dobrý nápad)
  
  
  

Přídavky

• Možnost spouštět sw jako službu (NT Service u Windows, daemon v Linuxu)
  
  
  
• Pro vybrané platformy přidělat spouštěč jiný než bat a skript
  
  
  
• Umožnit instalaci na externí aplikační server? - ten náš supermonitor by byl pak war na aplikáči, příliš práce, když to uděláme předchozím způsobem to není, spíše jde o testování na konkrétních aplikáčích
  
  
  
• Instalátor, případně některé další komponenty, by mohli mít nějaké primitivní Java GUI těžkého klienta (pokud možno platformově nezávislé)

Otázky

• SILK engine lze spouštět v rámci nějakého kontaineru, předpřipravit mu konf. data z DB, u integrace GUI už je to horší, otázkou je též způsob jakým přistupuje k DB (SPARQL endpoint)
  
  
  
• Jak dalece půjde SPARQL endpoint Virtuosa konfigurovat z Javy? V případě že ne, tak tu máme onen kýžený pádný důvod proč na lowlevel dotazování dělat též WS. Pokud budem umět nakonfigurovat DB z Javy a konfigurace SPARQL endpointů bude též v naší režii, pak budem možná schopni udělat celou instalaci i s Virtuosem, každopádně nebudeme uživatele příliš nutit umět konfigurovat Virtuoso, stačí když si ho nainstaluje. Existuje pro SPARQL endpoint nějaký standard? (do zadání bych napsal, že bude umožněno data dotazovat dostupným standardem, z formulace by nemělo vyplývat jak to uděláme, jestli jen to nezablokujem Virtuosu nebo budem dělat WS)

Navrhovaný další postup

• Naše analýza již poskytuje asi dost podkladů, abychom z ní byli schopni navrhnout
  takovýto podobný základní model výsledné aplikace, hlavně celkový soupis možností, které použijem a které budem měnit již jen vyjímečně
  
  
  
• Do něj pak napasujem naše krabičky diagramy atd.
  
  
  
• Ověříme celkovou funkčnost a zbylá bílá místa - a tím bych prototyp považoval za vyřízený, víc stejně nestihnem
  
  
  
• S našimi znalostmi sw inženýrství, architektur atd. jistě takto vymyslíme kvalitní produkt, držel bych se u tohoto postupu zásad ze SCRUMU apod., že pokud něco nevymyslíme v určitém termínu (např. že jsme se utopili v detailech) tak to necháme jednodušší, i když to není dokonalý
  
  
  
• K tomu to chce celkový plán, navrhuju dotvořit to tímto způsobem, projít to od návrhu výsledku odzadu až k vizím a pak zpět (výsledek pak může být odlišný)

Poznámka

Pro předvádění sw komisi bych navrhoval toto

• použít VirtualBox s celými nainstalovanými systémy (dá se zazálohovat i kopírovat mezi PC)
  
  
  
• až se z nějaké zálohy podaří 10..x perfektní předvedení, tak ji použijem
  
  
  
• předvádění může být víc (více platforem, více možných předvádění - instalace, předvedení GUI, předvedení vyčištěné DB apod.)