@<< = Welcome to the Cartesian Tool. This document is meant to be a tutorial mixed up with a concrete example on the different possibilities of the cartesian software. Feel free to use it, change it, use it, adapt it. The licence for it is apache 2.0 (http://www.apache.org/licenses/LICENSE-2.0.html) Please notice, that we use some free software, please have a look at <<Copyrights (FOSS)>> for the links. == Documentating features As you may have already seen, text between the 3 '"' caracters is ment to for documentation. To be more precise, this text will be directly exported for further work through asciidoc. This means, that you are invited to document here according to asciidoc format ( -> https://asciidoctor.org/ for more details) To add some specific diagrams, you may use `@usecase` to represent the use case diagram associated, or `@activity id` to represent the activity diagram associated to the id `id` Here the complete use case diagram corresponding to this tutorial document. @>> @usecase @<< == Scenarios and Use Cases The use cases are described through different scenarios. The cartesian software will take the different scenarios and put automatically the behviours together to one activity diagram. Here an example of three scenarios for the use case `use_case_1`: .... scenario use_case_1 : some actor_1 does activity_1 then some actor_1 does activity_2 scenario use_case_1 : some actor_1 does activity_2 creating some class_1 scenario use_case_1 : some actor_1 does activity_2 updating some class_1 then the actor_1 concrete_actor does activity_3 deleting some class_1 .... @>> scenario use_case_1 : some actor_1 does activity_1 then some actor_1 does activity_2 scenario use_case_1 : some actor_1 does activity_2 creating some class_1 scenario use_case_1 : some actor_1 does activity_2 updating some class_1 then the actor_1 concrete_actor does activity_3 deleting some class_1 @activity use_case_1 @<< The keyword `scenario` is typically followed by an id representing the use case for which you will describe a scenario. Please note that you may use the keywork `for` after `scenario` for readbility purposes. There is no effect associated. Have a look at the examples for the `use_case_2` or `use_case_3`. Then, after a `:`, begins the description of the different activities included in the scenario, separated by the keyword `then` for sequential activities or `and` for a parallelization. Please notice that the keyword `and` has a higher precedence then the keyword `then`. You may have a look at the scenarios associated to `use_case_2`, `use_case_3`, `use_case_3`, `use_case_4` or `use_case_5`. In `use_case_6`, we use the keywords `bundling` and `together` to force other precedendes. Construct with 'then': @>> scenario for use_case_2 : some actor_1 does activity_2 then some actor_1 does activity_3 scenario for use_case_3 : some actor_1 does activity_4 and some actor_2 does activity_5 @activity use_case_2 @<< Construct with `and`: @>> @activity use_case_3 @<< Construct `a then b and c`: @>> @activity use_case_4 scenario use_case_4 : some actor_1 does activity_1 then some actor_1 does activity_2 and some actor_1 does activity_3 @<< Construct `a and b then c` @>> @activity use_case_5 scenario use_case_5 : some actor_1 does activity_1 and some actor_1 does activity_2 then some actor_1 does activity_3 @<< Construct `bundling a then b together and c` @>> @activity use_case_6 scenario use_case_6 : bundling some actor_1 does activity_1 then some actor_1 does activity_2 together and some actor_1 does activity_3 @<< As the ids used are not really nice in a printed variant, it is possible to add a label to each id. For this purpose, the construct is `id .. "The label that will be used for representation"`. A label may be added only one time, it will then be reused for each usage of the given id. Here following example for this construct: `scenario use_case_7 : some actor_1 .. "the actor 1" does activity_1 .. "The activity 1"` @>> @activity use_case_7 scenario use_case_7 : some actor_1 .. "the actor 1" does activity_1 .. "The activity 1" @<< == Quick concepts * *Use Case*: A use case is the generic unity representing a whole process. * *Scenario*: A scenario is a typical usage for a use case. Use cases are represented through 1 or more scenarios. * *Activity*: Scenarios or more generally use cases are represented through linked activities. An activity may be detailed through scenarios. In this case, the activity becomes a use case. This means, that an activity or a use case are the same kind of object from the point of view of cartesian. * *Actor*: Actors are classes (in an object oriented way) that represent a role acting on the activity or the use case. * *Object*: Concrete objects related to a class * *Class*: A class containing some information / data. Actors are a special case of classes == Missing stuff in this tutorial * Inheritance between scenarios and classes == Futher links Asciidoctor: https://asciidoctor.org/docs/[Documentation], https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/[Quick Reference]. == Copyrights (FOSS) For our usage we use following software. Please notice, that we only use it as complete packages, and don't modify it: * Asciidoctor: https://github.com/asciidoctor/asciidoctor/blob/master/LICENSE * plantuml: https://plantuml.com or http://www.gnu.org/licenses/gpl-3.0.html for the license * graphviz: https://graphviz.gitlab.io/license/ * ocsigen / eliom: https://github.com/ocsigen/eliom/blob/master/LICENSE * ocaml: https://ocaml.org/docs/license.html @>>