</code></pre></div></div>]]></content><author><name></name></author><category term="sample-posts"/><category term="xmi,"/><category term="plantuml,"/><category term="uml,"/><category term="java,"/><category term="code-generation"/><summary type="html"><![CDATA[This post provides a brief explanation on how to connect visualization tools to code generation, without using propietary software.]]></summary></entry><entry><title type="html">Process algebra and StateCharts</title><link href="https://logds.github.io/blog/2018/java-state/" rel="alternate" type="text/html" title="Process algebra and StateCharts"/><published>2018-09-16T00:00:00+00:00</published><updated>2018-09-16T00:00:00+00:00</updated><id>https://logds.github.io/blog/2018/java-state</id><content type="html" xml:base="https://logds.github.io/blog/2018/java-state/"><![CDATA[<p>If we want to model an access to a resource that could not be read and written at the same time, we could use either process algebra or State Charts from UML analysis. In either cases the desired object is an element that could perform both read and write operations, without changing the type of the element or to remember to close and re-open the object in a different state.</p> \[P = \textup{read}.P + \textup{read}.P\] <p><img src="https://raw.githubusercontent.com/jackbergus/LucenePdfIndexer/master/images/Diagramma1_2.png" alt="P = read.P + write.P" style="margin:auto; display:block;"/></p> <p>We know that usually it is not good to keep reading and writing operations on the same object, and hence we have always to close and re-open the object if we want to change the type of the operation. As a consequence we have to handle three objects at a time, an initial state (<code class="language-plaintext highlighter-rouge">P</code>), an opened state for reading purposes (<code class="language-plaintext highlighter-rouge">R</code>) and another one for writing (<code class="language-plaintext highlighter-rouge">W</code>). This could be easily modelled as follows</p> \[\begin{cases} P = \textup{openRead}.R + \textup{openWrite}.W & \\ R = \textup{read}.R + \textup{close}.P & \\ W = \textup{write}.W + \textup{close}.P & \end{cases}\] <p><img src="https://raw.githubusercontent.com/jackbergus/LucenePdfIndexer/master/images/twostates_2.png" alt="Representing states P, R and W" style="margin:auto; display:block;"/></p> <p>Now we want to hide all the open and close operations, and hence we want to define an object, that is a State Machine, that keeps track of all the object states and then “smartly decides” which operations have to be carried out in order to reach the desired operation to execute.</p> \[\begin{cases} ClosedObject = \overline{\textup{OpenRead}}.\overline{\textup{close}}.ClosedObject + \overline{\textup{OpenWrite}}.\overline{\textup{close}}.ClosedObject& \\ ReadableObject = {\textup{OpenRead}}.R& \\ WritableObject = {\textup{OpenWrite}}.W& \\ R = \textup{read}.R + \textup{close}.ReadableObject& \\ W = \textup{write}.W + \textup{close}.WritableObject& \end{cases}\] \[(\nu (\textup{OpenRead},\textup{OpenWrite},\textup{close})) ( ClosedObject | ReadableObject | WritableObjeect)\] <p><img src="https://raw.githubusercontent.com/jackbergus/LucenePdfIndexer/master/images/complete_2.png" alt="Representing the synchronized states" style="margin:auto; display:block;"/></p> <p>We could easily see that this implementation corresponds to the first tone, that is the model that we want to reach.</p> <h2 id="using-interfaces-to-implement-the-internal-states">Using Interfaces to implement the internal states</h2> <p>Firstly, we must declare in Java that closed, opened, readable and writable states belong to a same type of object. This allows define an unique interface for any possible state of the internal object.</p> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="cm">/**
0 commit comments