expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2024-11-22 07:11:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

Cross-references between related pages

Browse Source
This commit is contained in:
Philip Sargent 2020-08-02 21:58:32 +01:00
parent 940a602d3c
commit 1fff005d2d
4 changed files with 73 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
handbook/l/life-wallet.html
View File

@ -13,10 +13,16 @@ CUCC Expo Handbook: Wallet Process UML Diagrams
<div class="centre">
<img alt="wallet process lifecycle diagram" src="../i/life-wallet.jpg" /></div>
<p>This diagram was created online using the free software at <a href="https://app.creately.com/diagram/4nGSj2FkKGg/edit">https://app.creately.com/</a>
<p>This "activity" diagram was created online using the free software at <a href="https://app.creately.com/diagram/4nGSj2FkKGg/edit">https://app.creately.com/</a>
<p>
You can edit your own version to revise this when it becomes outdated.
<p>We also have a "<a href="seq-wallet.html">sequence diagram</a> which shows clearly the sequence of wallet actions in a time-line.
<p>Both "activity" and "sequence" diagrams are part of the UML software specifiction system. We also have a "<a href="trogclass-1.html">class</a>" diagram for troggle.
That page also defines the "essential", "specification" and "implementation" levels at which troggle is designed and maintained.
<p>
Statcharts are a standard diagram in the analysis of complex systems.
They are used by the more professional analysts when planning a new software system. They are not quite the same thing as a finite state machine:
@ -26,8 +32,8 @@ They are used by the more professional analysts when planning a new software sy
<li><a href="https://en.wikipedia.org/wiki/UML_state_machine">wikipedia.org/wiki/UML_state_machine</a>
</ul>
<p><em>"The Statechart diagram is one of the five UML diagrams used to model the dynamic nature of a system. They define different states of an object during its lifetime and these states are changed by events. Statechart diagrams are useful to model the reactive systems. Reactive systems can be defined as a system that responds to external or internal events.</em>
<p>They were devised by David Harel, Weizmann Instiutute, in his paper: <a href="https://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf">STATECHARTS: A VISUAL FORMALISM FOR
COMPLEX SYSTEMS</a> Science of Computer Programming 8 (1987) 231-274.
<p>They were devised by David Harel, Weizmann Instiutute, in his paper: <a href="https://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf">Statecharts: A Visual Formalism For Complex Systems</a> Science of Computer Programming 8 (1987) 231-274.
Or for a quicker cheat-sheet, see <a href="https://instadeq.com/blog/posts/paper-didnt-read-statecharts-a-visual-formalism-for-complex-systems/">Paper; Didn't Read - Statecharts</a>
<!--
Wallet Lifecycle Statechart
# Philip Sargent 20 May 2020

6
handbook/l/seq-wallet.html
View File

@ -21,6 +21,12 @@ CUCC Expo Handbook: Wallet Process UML Diagrams
<li><a href="https://www.tutorialspoint.com/uml/uml_interaction_diagram.htm">Sequence and Collaboration Diagrams</a>
<li><a href="https://www.guru99.com/interaction-collaboration-sequence-diagrams-examples.html">Interaction, Collaboration, Sequence Diagrams</a>
</ul>
<p>We also have a "<a href="life-wallet.html">activity</a>" lifecycle diagram which shows clearly the states which a wallet can be in during its life.
<p>Both "activity" and "sequence" diagrams are part of the UML software specifiction system. We also have a "<a href="trogclass-1.html">class</a>" diagram for troggle.
That page also defines the "essential", "specification" and "implementation" levels at which troggle is designed and maintained.
<h3>This diagram</h3>
<p>This diagram was created online using the free software at <a href="https://www.websequencediagrams.com/">www.websequencediagrams.com/</a>.
<p>
You can edit your own version to revise this when it becomes outdated. <br>This is the entire source code that generates the diagram:

63
handbook/l/trogclass-1.html
View File

@ -21,8 +21,10 @@
<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.
<h3>Design Diagrams</h3>
<p>Analysis of expo and design of troggle is done using three levels:
<p>Analysis of expo and design of troggle is done using <a href="#cookanddaniels">three levels</a>:
<style>
li {padding-left: 0;margin-left: 0;line-height:160%;}
ul, ol {padding-inline-start: 1em;}
@ -35,9 +37,13 @@ ul, ol {padding-inline-start: 1em;}
<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 we ignore who is resident at top-camp (even though today we record this religiously because of the tax implications for the GastHof at base). We do need to track the in-computer associations between survex files: the *include 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>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 <a href="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>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.
<h3>Class Diagrams</h3>
<p>A Class Diagram is one the the basic types of structural diagram (as opposed to behavioral diagrams) used to understand complex systems.
<ul>
@ -45,11 +51,16 @@ This is where we decide which aspects of the real world <em>we will ignore</em>
<li><a href="https://www.tutorialspoint.com/uml/uml_class_diagram.htm">UML - Class Diagram</a>
</ul>
<p>
The purpose of class diagram is to model the static view of an application.
The purpose of class diagram is to model the static view of an application: the unchanging structure.
<h3>Other UML Diagrams documenting Expo systems</h3>
<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 <a href="life-wallet.html">wallet lifecycle</a> is a "<a href="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 <a href="seq-wallet">wallet process</a> is a "<a href="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 hand-drawn sketch title "Packages" on the <a href="../troggle/trogarch.html">troggle architecture</a> page is a UML "deployment" diagram.
<p>See <a href="https://www.martinfowler.com/tags/uml.html">Fowlers pages on UML</a> for more examples of UML in use.
<h3>Online free class diagram editor</h3>
<p>This diagram was created online using the YUML free software at <a href="https://yuml.me/mkay2100/edit/Troggle-1">https://yuml.me//</a>.
<p>The Class diagram on this page was created online using the YUML free software at <a href="https://yuml.me/mkay2100/edit/Troggle-1">https://yuml.me//</a>.
<p>
You can edit your own version to revise this when it becomes outdated. <br>This is the entire source code that generates the diagram:
<pre><code style ="font-size:x-small">
@ -91,7 +102,47 @@ You can edit your own version to revise this when it becomes outdated. <br>This
[PersonExpedition{bg:yellowgreen}]
</code></pre>
<h3 id="cookanddaniels">Cook & Daniels - Three Levels</h3>
<p>From <a href="http://www.syntropy.co.uk/syntropy/designing-object-systems.pdf">Cook and Daniels</a> (online PDF, 400 pages, pp10-11):
<div style="text-align: left; font-size: smaller; margin-left: 7%; margin-right:15%">
<p>
"In this book we present three kinds of object-oriented model. The first kind, which
we call <em>the essential model</em>, considers the model to be a description of some real or
imaginary situation, which may or may not contain software. We use the word
situation rather than system because ‘system’ has so many possible meanings including
the software we may be trying to build, and rather than world to emphasise that we are
considering purposeful systems situated in a context rather than trying to describe all of
some supposedly objective reality. <em>The purpose of building the essential model is to
understand and establish the facts about this situation.</em> The building blocks which we
use to build essential models are objects (actually object types) and events (actually
event types). An essential model is built by drawing annotated diagrams, and
interpreted as descriptions of sets, functions and sequences with meanings in the
situation being described.
<p>
In the second kind of model, called <em>the specification model</em>, we are concerned with
specifying software. To create a specification model it is necessary to establish <em>which
parts of the overall situation will be implemented in software</em>. In some cases this might
be a large part of the situation, whereas in others it might not be a part at all. The
activity of specifying exactly what is to be implemented in software is quite different
from the activity of establishing the facts about the overall situation; however both of
these activities would conventionally fall under the heading of ‘analysis’. Like
essential models, specification models deal with objects and events and are built by
drawing annotated diagrams. They are interpreted as a description of the abstract
stimulus–response behaviour of the software. The specification model describes
software at a high level of abstraction, and in particular says nothing about internal
sequencing or concurrency. An important part of building a specification model is the
allocation among object types of responsibility for aspects of software behaviour.
<p>
The third kind of model, <em>the implementation model</em>, is concerned with establishing
patterns of control flow within the software. In this model we take into account the
fact that computer programs have a limited number of well-defined flows of control,
which execute at a finite speed. The building blocks for implementation models are
objects and messages. Object interactions are described as messages sent from one
object to another, and the implementation model describes message sequencing and
concurrency control. Annotated diagrams are used again, although in the
implementation model our repertoire of diagrams is richer than for the other kinds of
model."
</div>
<hr />
</body>
</html>

2
handbook/troggle/trogarch.html
View File

@ -55,7 +55,7 @@ See the <a href="https://docs.djangoproject.com/en/3.0/misc/design-philosophies/
<h3>Troggle parsers and input files</h3>
<div class="onright">
<figure>
<a href="https://djangobook.com/mdj2-django-structure/"><img src="mtv_drawing2.jpg"></a>
<a href="https://djangobook.com/mdj2-django-structure/"><img src="../i/mtv_drawing2.jpg"></a>
<br><figcaption>Django server and webpage (client)</figcaption>
</figure>
</div>