Create mermaid function use flowchart

[athowes]

Following on from #46, we should create a function use diagram to keep in the package documentation.

I did start creating a PR (#54) for this, but stopped short and only implemented the static function use diagram. The reason for this is that I found it quite aversive to understand all of the existing functions and their use. As I touch more of the package I hope that this gets better. I think anything that I've not used / don't understand is getting more likely to be redundant as time goes on. Could also focus on building out the function use from first principles based around the code I do understand (e.g. the epidist function)

Here are some additional details to help with this issue:

• Solid lines indicate implemented features/analysis
• Dashed lines indicate planned features/analysis
• Current EpiAware model diagram looks as follows

flowchart LR

A["Underlying GI
Bijector"]

EpiModel["AbstractTuringEpiModel
----------------------
Choice of target
for latent process:

DirectInfections
    ExpGrowthRate
    Renewal"]

InitModel["Priors for
initial scale of incidence"]

DataW[Data wrangling and QC]


ObsData["Observational Data
---------------------
Obs. cases y_t"]

LatentProcPriors["Latent process priors"]

LatentProc["AbstractTuringLatentModel
---------------------
RandomWalk"]

ObsModelPriors["Observation model priors
choice of delayed obs. model"]

ObsModel["AbstractObservationModel
---------------------
DelayObservations"]

E["Turing model constructor
---------------------
generate_epiaware"]

G[Posterior draws]
H[Posterior checking]
I[Post-processing]

A --> EpiData
EpiData --> EpiModel
InitModel --> EpiModel
EpiModel -->E
ObsData-->E
DataW-.->ObsData
LatentProcPriors-->LatentProc
LatentProc-->E
ObsModelPriors-->ObsModel
ObsModel-->E


E-->|sample...NUTS...| G
G-.->H
H-.->I

Loading

[seabbs]

Could also focus on building out the function use from first principles based around the code I do understand (e.g. the epidist function)

This was the second proposed step after understanding the current package. In theory in documentation driven dev it should have come before starting to implement the methods. I think doing this sooner rather than later would be a good idea

[athowes]

In theory in documentation driven dev it should have come before starting to implement the methods. I think doing this sooner rather than later would be a good idea

Do not neccessarily disagree but note that my previous experience with DDD and wanting to do things "in theory correct" in practise resulted in me feeling mentally blocked and not making as much progress as something closer to "trying things".

Similar to sentiment expressed previously: I do see downsides of lock-in type effects from lack of planning, but think that specific to this project and it's stage those risks can be effectively mitigated.

[athowes]

This said, I do think having written the S3 refactor / epidist function, I'm in a good position to plan out the functionality from there and could do this soon.

[athowes]

Resources for use here:

• Proposal: transform get_prior, make_stancode and make_standata into S3 methods paul-buerkner/brms#1604
• https://github.com/venpopov/bmm