\section{Základní popis systému}
\label{sec:zakladnipopis}

\secpreview{Tato kapitola popisuje základní pojmy systému
  (\ref{sec:vysvetleni}) a podává úvodní přehled návrhu systému --- přináší
  přehled jeho vrstev (vertikální členění, \ref{sec:vrstvy}), jež je dále
  rozebíráno v~navazujících kapitolách.}

Pro připomenutí základní funkcionality systému viz oddíl~\ref{sec:kratke},
prvotní technické vymezení systému viz oddíl~\ref{sec:zpusob}


\subsection{Vysvětlení pojmů}
\label{sec:vysvetleni}

Systém \tts{} je primárně určen pro řízení projektů.  Na
obrázku~\ref{fig:conception} je zobrazen \nientrya{pojmový model}, ze kterého
jsou nejlépe patrné hlavní pojmy a vazby mezi nimi.

\model{Pojmový model}{conception}

Základním pojmem \tts{}u je pochopitelně \nientrya{projekt} (\emph{Project}).
Tento pojem je nutné chápat velmi obecně --- projektem může být v~prvním
přiblížení cokoli, o co má potenciální zákazník (\emph{Contact})
zájem\footnote{(1) informační systém, (2) průzkum trhu, (3) \dots}.

Model má několik samostatnějších částí:

\begin{enumerate}

\item Obchodník (\emph{Salesman}) získává potenciální zákazníky
  (\emph{Contact}) a, pokud jde o vážného zájemce, vzniká projekt.
  
\item Projektový manažer řeší zadaný projekt a ten je v~konečném důsledku
  koupen zákazníkem.  Zákazník však nekupuje projekt, ale jeho jeden exemplář
  (\emph{Installation}).  Vztah mezi projektem a exemplářem je analogický
  vztahu \emph{titul} $\rightarrow$ \emph{konkrétní kniha}.
  
\item Kontakt se stává zákazníkem v~okamžiku, kdy vlastní jedinečný exemplář
  projektu, neboli tzv.~instalaci.  V~tomto exempláři se samozřejmě mohou
  vyskytovat různé chyby (\emph{Bugs}) a proto má klient možnost zpětné vazby.

\end{enumerate}

Pokud se nad tímto modelem zamyslíme, je patrné, že se ve skutečnosti jedná o
obecný model \emph{konzultantské firmy}\footnote{Což je podtrženo i hlavními
  rolemi zaměstnanců --- (1) obchodník, (2) projektový manažer a (3)
  help--desk.}!  Toto zjištění je velmi uspokojující, protože je z~něho
minimálně patrné, že pro nasazení v~konzultantské společnosti je \tts{} vhodným
kandidátem, což odpovídá jeho zamýšlenému použití (viz~\ref{sec:kratke} a
\cite{ttsweb2})\footnote{Potvrzují to i instalace v~České republice,
  viz~\myhref{http://www.finapp.cz}}.

\tts{} samozřejmě podporuje řadu dalších agend (dokumenty, schůzky, odpracované
hodiny, \dots) a různé vazby mezi nimi, ale všechny tyto doplňky jsou v~rámci
systému chápány jako rozšíření funkcionality v~oblasti řízení projektů, ačkoli
mohou být využity i samostatně.


\subsection{Vrstvy systému a vazby mezi nimi}
\label{sec:vrstvy}

Nyní je vhodný okamžik podívat se blíže na jednotlivé \nientrya{vrstvy
  systému}.  Přehled přináší obrázek~\ref{fig:layersbrief}.  Záměrně došlo
k~opomenutí řady tříd (zejména z~oblasti aplikační vrstvy), avšak díky tomu
mohou vyniknout vzájemné důležité vazby.

\model{Vrstvy systému \tts{} a jejich vzájemné vazby}{layersbrief}


\subsubsection{Prezentační vrstva}
\label{sec:prezentacni}

\nientryb{prezentační vrstva}{Prezentační vrstva} je na první pohled prostá.
Existují dvě hlavní základové abstraktní třídy (podle konvence UML znázorněné
{\it kurzívou}): (1)~Třída vzhled (\cl{Theme}) a (2)~třída rozvržení
(\cl{Layout}).

Třída vzhledu \cl{Theme} příliš zajímavá není.  Jejím hlavním úkolem je
definovat grafické prvky (obrázky) a styly písma, což v~dnešní době CSS stylů
většinou znamená pouze postarat se o připojení vhodného souboru stylů, dále má
na starosti zavedení javascriptu a několik málo dalších drobností.

Třída rozvržení \cl{Layout} je mnohem důležitější.  Definuje základní
rozvržení na stránce --- řídí umístění nabídky, pracovní plochy a realizuje
její konkrétní obsah.  Pro jednu (běžnou) třídu aplikační logiky se většinou
definuje několik \cl{Layout} podtříd, které zajišťují:

\begin{enumerate}
\item Prosté zobrazení jednoho konkrétního objektu aplikační logiky.
\item Editaci atributů jednoho konkrétního objektu.  Většinou lze beze změn
  použít i pro vložení nového objektu.
\item Zobrazení seznamu objektů daného typu.
\item Vyhledávání objektů daného typu.
\end{enumerate}

Existují i výjimky, kdy třída typu \cl{Layout} není svázána s~žádným objektem
aplikační logiky a přistupuje přímo k~databázi, jak je ostatně patrno
z~modelu\footnote{Příkladem mohou být například různé administrativní stránky,
  reporty aj.}.


\subsubsection{Aplikační vrstva}
\label{sec:aplikacni}

Aplikace typu \ientrya{transakční manažer} bývají často realizovány tak, že
třídy \nientryb{aplikační vrstva}{aplikační vrstvy} jsou odvozeny od společné
základové třídy, jejímž úkolem je zajistit perzistenci objektům (viz~\cite{OMT}
a \cite{javaprof}).

\tts{} v~tomto není výjimkou.  Služby perzistence zajišťuje právě základová
\nientrya{třída \cl{Tutos\_Base}}.  Jako jediná spolupracuje s~třídami
databázové vrstvy a poskytuje virtuální metody, které řeší aktualizace a
dotazování do databáze, jež jsou vždy v~příslušné aplikační třídě přetíženy a
doplněny.

Každý perzistentní objekt má v~rámci systému unikátní identifikační číslo.  To
umožňuje složité provázání objektů, i s~menším počtem vazebních tabulek (viz
strana~\pageref{sloc} a oddíl~\ref{sec:asociace}).

Velmi zajímá je třída \cl{History}.  Její instance sledují u perzistentních
objektů změny v~datových atributech objektu po celou dobu jeho existence,
včetně informací o tom, kdo, kdy a samozřejmě jak objekt změnil.

Objekty třídy \cl{Acl} ke každému objektu drží systém oprávnění, neboli
\nientryc{ACL}{ACL}{ACL = Access Control List}, který jasně definuje kdo má
k~objektu přístup a jaké operace nad ním může vykonávat.  Existují 4 druhy
oprávnění:

\begin{enumerate}
\item Zobrazit --- právo prohlížet si objekt.
\item Použít --- právo použít objekt --- právo operovat nad vazbami objektu.
\item Upravit --- právo editovat datové atributy objektu.
\item Odstranit --- právo odstranit objekt z~databáze.
\end{enumerate}

\nientryb{třída \cl{Tutos\_Mo\-du\-le}}{Třída \cl{Tutos\_Module}} je základní
třídou pro tvorbu nových rozšíření \tts{}u --- každé rozšíření by ji mělo
zdědit a poskytnout tak jádru \tts{}u potřebné informace.  To, proč dědí od
třídy \cl{Tutos\_Base} zatím nechme stranou (podrobněji
viz~\ref{sec:dedicnost}).


\subsubsection{Databázová vrstva}
\label{sec:databazova}

Hlavním úkolem \nientryb{databázová vrstva}{databázové vrstvy} je dobře
odstínit zbytek aplikace od konkrétní použité databáze.  Podporovány jsou tyto
databáze: (1)~MySQL, (2)~PostgreSQL, (3)~Interbase, (4)~Oracle a (5)~MSSQL, ve
svých stabilních verzích.

Rozumnou snahou vývojářů \tts{}u je používat určitou podmnožinu ANSI SQL92,
takže by nemělo být složité přenést \tts{} i na jiné databáze.
Nejdiskutovanější může být z~tohoto hlediska podpora MySQL, která dlouhou dobu
přes své nesporné kvality v~jiných oblastech zaostávala a zaostává v~podpoře
užitečných funkcí (transakce, datové pohledy a generátory), ale protože jde o
velmi rozšířenou a populární databázi, byla podporována od samého začátku a
některé nedostatky (generátory) byly rozumným způsobem nahrazeny v~samotném
kódu aplikace.

Tři uvedené třídy (stále obrázek~\ref{fig:layersbrief}) jsou běžnými obdobami
modernějších databázových rozhraní, jak je známo například z~JDBC
(viz~\cite{javaprof}).

\nientryb{třída \cl{Tutos\_DB}}{Třída \cl{Tutos\_DB}} představuje spojení na
databázi a přes své metody zpřístupňuje třídy s~obecným rozhraním podle
konkrétní databáze \cl{Query} (určené ke konstrukci dotazů\footnote{Jak DML tak
  i DDL dotazů.}) a \cl{Result} (určené ke zpracování výsledků).  Řízení
transakcí je možné přímo přes metody třídy \cl{Tutos\_DB}.

Pokud bych měl připodobnit tyto třídy například ke třídám a rozhraním balíku
\inlinecode{java.sql.*}, viz například \cite{javaprof}, vypadalo by to
přibližně takto:

\begin{center}
  \begin{tabular}{l@{ : }l}
    Tutos\_DB & Driver, Connection, DatabaseMetaData, Statement \\
    Query & Statement, PreparedStatement \\
    Result & ResultSet, ResultSetMetaData
  \end{tabular}
\end{center}

Je vidět, že tyto 3 třídy přebírají řadu odpovědností a někde se i
překrývají, blíže k~tomuto problému viz dále.


\subsection{Shrnutí}
\label{sec:zakladnishrnuti}


Lze konstatovat, že na této úrovni abstrakce systém splňuje všechny obecné
požadavky (až na nevysvětlenou dědičnost \cl{Tutos\_Base} $\rightarrow$
\cl{Tutos\_Module}).

Vztahy mezi základními pojmy stejně jako pojmy samotné jsou v~pořádku.  Vazby
mezi jednotlivými vrstvami (prezentační, aplikační a databázovou) jsou také
v~pořádku.

Jak bude vidět dále, při dalším zpodrobnění vystoupí již do popředí některé
nedostatky, kterým bude věnován zbytek této práce.
