\section{Závěr}
\label{sec:zaver}


Práce se zabývala návrhem a implementací systému \tts{}~\cite{ttsweb}.  Cíl
práce byl stanoven takto (převzato z~\ref{sec:cil}):

\begin{itemize}
\item Identifikace problémových částí \tts{}u, resp. jeho návrhu.
\item Konkrétní doporučení, jak danou část zlepšit.
\item Dokumentace, na které lze dále stavět.
\end{itemize}

První dva body je vhodné diskutovat najednou (\ref{sec:problemove}), poslednímu
je věnován oddíl~\ref{sec:dokumentace}.

\subsection{Problémové části a doporučení}
\label{sec:problemove}

\subsubsection{Shrnutí postupu analýzy}

V~kapitolách~\ref{sec:zakladnipopis} a \ref{sec:navrh} byl postupně
představován systém \tts{}.  Systém byl popisován s~ohledem na jednotlivé
vrstvy (prezentační, aplikační a databázovou).  Popis jednotlivých vrstev byl
postupně zpodrobňován.

Každá vrstva byla představena v~interakci se svým okolím a zároveň podrobněji
rozebrána v~samostatných částech práce (kapitoly~\ref{sec:zakladnipopis}
a~\ref{sec:navrh}).

Doporučující úpravy byly probrány pro každou vrstvu samostatně od jednodušších
úprav ke složitějším.  Jsou jim věnovány tyto kapitoly:
\ref{sec:upravydatabazove} (databázová vrstva),
\ref{sec:upravyaplikacni} (aplikační vrstva) a
\ref{sec:upravyprezentacni} (prezentační vrstva).  Každou z~těchto
kapitol uzavírá diskuze dopadu změn na systém a krátké shrnutí.

\subsubsection{Dosažené výsledky}

Z~celkového hlediska je systém navržen dobře (\ref{sec:vrstvy}).  V~rámci
jednotlivých vrstev se však objevují některé nedostatky.

\paragraph{Databázová vrstva}

V~databázové vrstvě (viz~\ref{sec:databazova2}) nejsou žádné zásadní problémy.
Je doporučeno využít jiných knihoven pro databázovou abstrakci, protože
v~současné době poskytují (1)~podporu pro více databází, (2)~trochu lepší
odstínění od databáze a (3)~podporu nových vlastností databázových strojů.
  
\tts{} byl nucen využívat vlastní knihovnu, protože v~době jeho vzniku nebyly
tak dobré databázové abstrakce ještě k~dispozici.  Dnes již ale je situace
jiná.  Využitím takové knihovny zároveň odpadne nutnost udržovat databázový
kód.
  
\paragraph{Aplikační vrstva}

Aplikační vrstva (\ref{sec:aplikacni2}) nebyla popsána v~celé své šíři.  Byl
vybrán úsek klíčových modulů systému (\ref{sec:asociace}) a v~něm byly odhaleny
drobnější nedostatky v~implementaci, viz~\ref{sec:dalsi}, a jeden v~návrhu při
smíchání odpovědností u tříd při špatně užité dědičnosti,
viz~\ref{sec:dedicnost}.

Bylo navrženo, jakým způsobem situaci napravit (odstranit dědičnost) a zároveň
byly diskutovány další drobné změny v~aplikační vrstvě s~cílem zpřehlednit
implementaci a jasně vymezit odpovědnosti u tříd (\ref{sec:dalsi}).

Především šlo o to odstranit z~aplikační vrstvy nevhodné odpovědnosti, jež by
bylo, s~ohledem na úpravy prezentační vrstvy, vhodné řešit jinde a jinak ---
týkalo se to (1)~kontroly vstupních dat, \ref{sec:zpracovani}, a~(2)~odstranění
XML metod z~bázové třídy \cl{Tutos\_Base}, \ref{sec:rozdeleni}.

\paragraph{Prezentační vrstva} 

Největších navrhovaných změn (a~i největší diskuze) se dočkala prezentační
vrstva.

Nutnost nové implementace prezentační vrstvy byla odůvodněna
v~částech~\ref{sec:problemy} a~\ref{sec:pozadavky}.  Bylo poukázáno na
nevhodnost současného návrhu s~ohledem na výstup do jiných výstupních formátů
(XML).

Nový návrh plně podporuje nové požadavky (\ref{sec:pozadavky}) a zároveň
ponechá tvorbu výstupních stránek téměř beze změn (\ref{sec:zamyslene}).

Vnitřní struktura tříd nově navržené prezentační vrstvy je složitější (byť
ucelenější) a tudíž implementačně náročnější.  Výměnou prezentační vrstvy se
bude muset upravit mnoho kódu.


\subsection{Dokumentace}
\label{sec:dokumentace}

\tts{} je projektem na \sfnet{}, \cite{ttssfweb}, a~je k~němu dostupný zdrojový
kód; avšak kromě toho téměř žádná dokumentace.  O modelech popisující fungování
systému z~trochu větší perspektivy si může nechat jen zdát.

Na tomto poli tudíž není s~čím srovnávat.  Tato práce je prvním veřejným
autorovi známým zdrojem, jež se snaží popsat fungování systému pomocí názorných
modelů a doprovodných komentářů.

Nevýhodou jistě je to, že práce není psána anglicky.  Tento nedostatek a z~něho
povstávající oprávněná výtka byl způsoben nedostatkem času.  Alespoň diagramy
byly vypracovány důsledně v~anglickém jazyce a názvy tříd v~nich uvedené
odpovídají těm ze skutečného kódu v~\tts{}u.

Bylo představeno celkem 13 modelů.  Zachytit systém v~celé jeho šíři na jednom
modelu je nesmyslné.  Některé modely tudíž volí hrubší měřítko a popisují
základní stavební prvky systému.  Některé si naopak vybírají jednotlivé výseky
a ty podrobně zpracovávají.

Za významné mohou být považovány tyto modely:

\begin{center}
  \begin{tabular}{p{0.38\textwidth}|p{0.52\textwidth}}

    Pojmový model (obrázek~\ref{fig:conception}) &
    celkový náhled\\
    \hline
    Vrstvy systému (obrázek~\ref{fig:layersbrief}) &
    jednotlivé vrstvy systému\\ 
    \hline
    Asociace (obrázek~\ref{fig:modulesbrief}) &
    podrobnější pohled na aplikační logiku\\
    \hline
    Prezentační vrstva ---  model jednání
    (obrázek~\ref{fig:preslayerusecase}) &
    požadavky na prezentační vrstvu\\
    
  \end{tabular}
\end{center}

Z~hlediska přínosů práce pak i model na obrázku~\ref{fig:preslayerom} ---
podrobný objektový model nově navržené prezentační vrstvy.

Zkušenému vývojáři možná chybí datový model --- rozumný pohled na data systému
však může poskytnout vhodný nástroj pro práci s~databází, kterých je celá řada,
například~\cite{squirrel}.

S dokumentací souvisí i dokumentování zdrojového kódu --- bylo by žádoucí
doporučit (jednotně) nějaký systém pro dokumentování zdrojového kódu ---
například \cl{phpDoc}, \cite{phpdoc}.


\subsection{Diskuse nad přínosy práce}
\label{sec:diskuse}

Při zpětném pohledu na cíl, viz~\ref{sec:zaver}, lze konstatovat, že cíl a
smysl práce byl v~rozumných mezích splněn.

V~době vniku práce (konec roku 2004) se jedná o ojedinělý počin (s~ohledem na
komunitu uživatelů a vývojářů kolem \tts{}u), který se snaží zmapovat rozsáhlý
systém využitelný v~široké škále činností.  Motivací autora bylo přispět
hodnotným materiálem této komunitě.

Dokument předkládá řadu konkrétních doporučení a nevyhýbá se ani špatným
stránkám systému, jež se snaží na základě provedené analýzy napravit.

Metodika OMT, \cite{OMT}, jež byla v~práci využita, rozlišuje několik úrovní
abstrakce rozboru systému: (1)~rozbor zadání, (2)~analýzu, (3)~design a
(4)~implementaci.

Tento dokument osciluje mezi všemi těmito úrovněmi a pouze nepřesně vymezuje
jednotlivé úrovně abstrakce během prováděných analytických postupů.  To mu může
být vytýkáno.

Je však třeba si uvědomit:

\begin{itemize}
  
\item Byl popisován rozsáhlý systém, k~němuž neexistuje jiná dokumentace, než
  zdrojový kód.  To mohlo vést někdy k~přílišnému tíhnutí k~podrobným a
  implementačně zaměřeným částem (jako například \ref{sec:specialni}).
  
\item Protože jde o existující systém, některé části rozboru systému postrádají
  smysl (rozbor zadání) a postup zpracování by to měl náležitě respektovat a
  volit jen ty vhodné nástroje k~popisu (k~čemuž metodika OMT přímo vybízí).
  
\item Velikost systému.  Nebylo též záměrem popsat celý systém.  To by vzhledem
  ke komplexitě a rozsahu celého systému bylo spíše námětem disertační práce.
  Cílem bylo odhalit jednotlivé (nejpalčivější) nedostatky a pokusit se o
  jejich nápravu, ne popisovat ty části, kde buď (1)~je vše v~pořádku, anebo
  (2)~nejsou příliš významné (rozšíření bez většího významu).

\end{itemize}


\subsection{Další postup}
\label{sec:dalsipostup}

Je možné předpokládat, že změny navrhované v~databázové a aplikační vrstvě
nevyvolají příliš připomínek, protože se jedná o vcelku dobře uchopitelné
případy a doporučení jsou jasná a konkrétní.

Rozhodně to však nelze říci o prezentační vrstvě, která byla navržena zcela
nově při respektování současných omezení systému.  Právě té by měl být dán
největší prostor při dalším (navazujícím) rozboru.  Některé z~možných
připomínek se pokusí zodpovědět právě tento oddíl.

V~současné době se objevuje řada velmi zajímavých projektů, řešící programování
webových aplikací lehce jiným přístupem --- přes událostní model, který plně
umožňuje využít design pattern \ientrya{model\---view\---controller},
\cite{framework1}, \cite{framework2}

Současný model zpracování stránek ve webových aplikacích (a~zejména v~PHP) je
příliš ovlivněn modelem zpracování, kdy jednomu formuláři odpovídá jeden skript
obsluhující formulář.

Je to patrné i mém návrhu (\cl{Output\_Page} --- formulář, \cl{Input\_Page} ---
obsluha formuláře).  Sice se snažím o určité zobecnění (\cl{Data\_Model}), ale
není to zobecnění dokonalé.  Stále je zde nutnost odvozovat řadu stránek
z~\cl{Output\_Page} a z~\cl{Input\_Page}\footnote{Přičemž
  v~části~\ref{sec:prezentacnidopady} sám uvádím, že tvorba stránek
  \cl{Input\_Page} je mnohdy zbytečná.}, i když sama třída \cl{Data\_Model}
zastane práci jak při tvorbě formuláře (poskytuje data pro zobrazení), tak i
při jeho zpracování (kontrola vstupních dat).

Provázání stránek (formulář a obsluha formuláře) je příliš volné a příliš je
spjato s~implementací --- propojení se děje skrze jméno souboru, které je
uvedeno v~atributu \inlinecode{action} elementu \inlinecode{form}.
Přejmenování souboru najednou znamená nefungující aplikaci ve všech částech,
kde je jméno souboru uvedeno jako stránka zpracovávající
formulář\footnote{Pokud je kupříkladu generován odkaz na tento soubor v~nabídce
  musí se změnit i ta.  Samozřejmě je možné mít nějaké centrální repository
  souborů, kde by mohlo docházet k~přemapování, ale to pouze posouvá problém
  jinam}.


\subsubsection{\cl{php.MVC}}
\label{sec:phpmvc}

Problémy naznačené v~předchozím odstavci se snaží řešit například knihovna
\cl{php.MVC}.  Inspiraci jejího návrhu lze hledat u jiných jazyků a jejich
knihoven, například \cl{mod\_python}, viz~\cite{modpython}.

Cílem použití této knihovny je odstínit GUI webové aplikace (webové stránky) od
propojení na konkrétní zdrojové soubory zpracovávající tyto stránky.

Dosahuje se toho tím, že formuláře (webové stránky, view) se nepropojují
s~konkrétním zdrojovým souborem, ale s~akcí (model), která má být vykonána
(typicky volání nějaké funkce).  Všechny formuláře jsou následně odeslány
určité komponentě (controller), která na základě dostupných informací vyvolá
příslušející obslužnou akci.

Začlenění takové knihovny do aplikace však bude mít dalekosáhlé dopady na její
návrh a implementaci jak ve vrstvě prezentační, tak i aplikační.  Dojde ke
kompletní změně modelu tvorby nových stránek a bude třeba přijmout zcela nový
přístup k~implementaci aplikace.  (Předkládaný návrh se snaží zachovat současné
postupy.)

Při pokusu konkretizovat přínosy začlenění podobné knihovny lze dojít
k~následujícímu seznamu (při srovnání s~navrhovaným řešením
v~kapitole~\ref{sec:upravyprezentacni}):

\begin{enumerate}
  
\item Odpadne zcela tvorba stránek odvozených z~\cl{Input\_Page}.
  
\item Mapování objektů třídy \cl{Output\_Page} na obslužné stránky by nebylo
  závislé na jménu souboru, ale bylo by spjato přímo s~instancemi\\
  \cl{Data\_Model} a jejich metodami.

\item Přístup k~řadě užitečných funkcí (systémy šablon, zpracování XML,
  integrace s~databázovými knihovnami) --- například \cl{php.MVC} je schopna
  spolupráce s~knihovnami \cl{ADOdb}, \cite{phpADODB} či \cl{Smarty},
  \cite{smarty}, na něž lze nalézt odvolávky i v~této práci.

\end{enumerate}


\subsubsection{Shrnutí}

Databázová a aplikační vrstva jsou v~zásadě v~pořádku a ať již navrhované změny
budou zapracovány či ne, \tts{} stále bude funkčním a použitelným software.  Je
to prezentační vrstva, kde musí dojít k~zásadnímu rozhodnutí, jak dál.

Proti předloženému návrhu nové prezentační vrstvy stojí nové slibné projekty,
které staví vývoj aplikací v~PHP na zcela jinou úroveň.  Zvážit všechny
důsledky začlenění tak rozsáhlé knihovny, jež je popisována v~\ref{sec:phpmvc},
do kódu \tts{} by jistě stálo za úvahu.

