<ahref="https://yuml.me/mkay2100/edit/Troggle-1"><imgalt="Troggle UML Class Diagram"src="../i/trogclass-1.jpg"></a>
<br><figcaption>Class Diagram - Essential Level (draft - to be corrected)</figcaption>
</figure>
</div>
<p>This shows the major "things" in troggle and how they relate to each other.
<p>So <strong>a survex (SVX) file</strong> is dated to a particular day during the expedition and usually has between 1 and 3 people associated with it.
<p>A <strong>Logbook entry</strong> has several people involved and may relate to a cave. It will be dated to a day during the expedition.
<p>Although the volume of data in troggle is small, the complexity is significantly intricate that "modern" (i.e. from the mid 1990s) system design tools are compact and useful.
li {padding-left: 0;margin-left: 0;line-height:160%;}
ul, ol {padding-inline-start: 1em;}
</style>
<ol>
<li>The '<strong>essential</strong>' or 'real-world' level.
<li>The '<strong>specification</strong>' level.
<li>The '<strong>implementation</strong>' level.
</ol>
<p>As anyone reading this has probably been on expo and you might think that we can skip the <strong>real-world level</strong>. Not so: the multiplicities (the number of participants in the association) of the relationships between the different cave survey artefacts can be surprising.
<p>The <strong>specification level</strong> is where the action is.
This is where we decide which aspects of the real world <em>we will ignore</em> and what <em>extra concepts</em> we need to make things work.
<p>So <em>we ignore</em> who is resident at top-camp (even though today we record this religiously because of the tax implications for the GastHof at base). We <em>do</em> need to track the in-computer associations between survex files: the <var>*include</var> tree, what directories they live in, what wallet-directory they relate to, and all the individual survex blocks of survey measurements within each survex file.
<p>We only need <strong>implementation-level</strong> diagrams for tiny, tricky issues. Python is very clear so serves as its own implementation specification. However Django does need some explanation even to a competent python programmer if they have not used it before.
<p>For a fundamental background to system specification the classic work of <ahref="http://www.syntropy.co.uk/syntropy/designing-object-systems.pdf">Cook and Daniels</a> (online PDF, 400 pages) cannot easily be improved upon (start reading at page 10, second paragraph).
<p>Class diagrams describe structure, but there are useful diagrams that describe <em>behaviour</em> too. Not much of our process is complicated enough to need them though.
<p>The <ahref="life-wallet.html">wallet lifecycle</a> is a "<ahref="https://en.wikipedia.org/wiki/Interaction_overview_diagram">interaction</a>" diagram showing the states and transitions between the states for a plastic wallet holding original caving notes and the software equivalent directory. The <ahref="seq-wallet.html">wallet process</a> is a "<ahref="https://en.wikipedia.org/wiki/Sequence_diagram">sequence</a>" diagram showing which actors (people) interact with a wallet during its lifecycle: inserting pages from the waterproof notebook, taking the notes and sketches and scanning the, processing the survey data to produce centreline plots etc.
<p>The Class diagram on this page was created online using the YUML free software at <ahref="https://yuml.me/mkay2100/edit/Troggle-1">https://yuml.me//</a>.
