<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>requirement analysis - the Greenhouse Integrated Pest</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Vojtech Merunka</string-name>
          <email>vmerunka@gmail.com</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Athanasios Podaras</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="editor">
          <string-name>Diagrams, Integrated Pest Management (IPM)</string-name>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Department of Information Engineering, Czech University of Life Sciences</institution>
          ,
          <addr-line>Prague</addr-line>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>IT Project Management Division</institution>
          ,
          <addr-line>Alpha Bank, Athens</addr-line>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>UCBTA Transition Rules, Use Case Main Success Scenario Steps</institution>
          ,
          <addr-line>BORM</addr-line>
        </aff>
      </contrib-group>
      <fpage>397</fpage>
      <lpage>408</lpage>
      <abstract>
        <p>The basic part of an innovative and modern approach to business process requirement analysis which is based on the simultaneous utilization of</p>
      </abstract>
      <kwd-group>
        <kwd>Business process requirement Analysis</kwd>
        <kwd>UCBTA</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>B
R&amp;S\ULJKWEHD¶VXQPGOIYF
RIU6XVWDLQEOH$JSGF(YP+,&amp;7NK
Q,06DOPSVL$WRXHG3UFJIK&amp;
QDG&amp;RPXLFW7HKOJV</p>
      <p>Czech
UML</p>
      <p>Use</p>
      <p>Case approach and the</p>
      <p>Business</p>
      <p>Object Relation</p>
      <p>
        Modelling
approach is analyzed in the present paper. Precisely the transition rules by
which the Use Case Main Success Scenario steps for a computer based process
are converted into to a BORM workflow diagram, entitled as the Use Case To
BORM Transformation Algorithm (UCBTA) transition rules, are presented as
a pattern based method which leads to the effective and efficient business
process requirement analysis. The rules are introduced in order to support the
UCBTA algorithmic concept. A Greenhouse Integrated Pest Management case
study is analyzed as a brief delineation of the algorithm’s implementation in a
specified agricultural computer based process.
Algorithm,
The most common technique utilized worldwide for detailed requirement analysis is
the UML Use Case model. Use Cases are often the foundation of most Object –
Oriented development methods [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]. However, it has been stated by IT experts, who
strongly recommend UML tools such as Use Case diagrams followed by the
Sequence, Collaboration and State Transition Diagrams for the integration of
efficient and effective requirement analysis, that the above mentioned tools are
mainly oriented at the programming concepts and are regarded as weak [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ] in terms
of business logic and business process modeling. Provided that stakeholders are not
familiar with computer – oriented concepts, communication between IT experts and
stakeholders cannot be achieved at the early stages of system development and
throughout requirement analysis phase. BORM methodology [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ] on the other hand
can be successfully utilized in this circumstance while it is business oriented, and it
can be consequently absorbed by stakeholders and end users. In BORM diagrams the
business process flow is depicted; consequently it can be viewed, controlled and
absorbed at a satisfactory level, even by end – users and stakeholders who have no
computer orientation. The author’s proposal for the derivation of a complete business
process requirement analysis is the transformation of the Use Case requirement
analysis to the BORM approach with the introduction of a pattern based algorithmic
method (Fig.1); the Use Case to BORM Transformation Algorithm (UCBTA) [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ] is
constructed to cover all possible weaknesses that emerge from the Use Case model
and the BORM method when they are utilized solely and not simultaneously for
defining and analyzing end – user requirements during the requirement analysis of a
business process. The mathematical theory behind UCBTA algorithm is the Non –
Deterministic Finite Automaton [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. The UCBTA algorithm is comprised of several
steps [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]. Throughout the current document the algorithmic phase analyzed is the
transition of the Use Case main success scenario to a BORM diagram which aims at
the workflow demonstration to the end users of a system or application. A practical
implementation of the UCBTA approach within the area of Agriculture is delineated
as a tool for ameliorating automated Greenhouse processes.
      </p>
    </sec>
    <sec id="sec-2">
      <title>USE CASE MODEL</title>
      <sec id="sec-2-1">
        <title>UCBTA</title>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>BORM MODEL</title>
      <sec id="sec-3-1">
        <title>Objectives and methodology</title>
        <p>Primary objectives of the current paper are:
· the justification of the construction of indispensible specified transition rules
according to which the Use Case requirement analysis model is transformed
to the BORM approach to business process requirement analysis without
data loss
· demonstration of the way according to which Use Case main success
scenario steps are demonstrated via BORM Diagrams after the transition is
completed
· practical proof via the Agricultural Case Study that the UCBTA transition
rules are the most important part of the UCBTA transformation, due to the
fact that end users with no IT background from any business process area
are able to absorb the business process functionality.
The root methodologies from which the Use Case To BORM Transformation
algorithm stems are the Use Case analysis and the BORM business process
requirement analysis.
3</p>
      </sec>
      <sec id="sec-3-2">
        <title>Discussion</title>
        <sec id="sec-3-2-1">
          <title>UCBTA Algorithmic Steps and Transition Rules. The transition path, through</title>
          <p>which the Use Case Analysis model is transformed into a BORM Business Process
workflow diagram and through which the desired process result is reached, is
comprised of the following steps:
a) UCBTA Input – Process Definition
b) UCBTA 1st Part – Defining the Use Case:
If Uc = Use Case and P=Process it is considered that Uc Í P
c)</p>
          <p>UCBTA 2nd Part – BORM general function definition (Transformation
Initiation)
If BF = BORM Function and P=Process it is considered that U Í BF and P Í BF
d) UCBTA 3rd Part – Considering Use Case Actors
e)</p>
          <p>UCBTA 4th Part – BORM Participant determination
If UA = Use Case Actor and BP = BORM Participant it is considered that UA = BP
f)</p>
          <p>UCBTA 5th Part – Use Case Main Success Scenario Statement – Initial step
UMSS = Use Case Main Success Scenario; the relation to the BORM General Function
will be the following: UMSS Í BF</p>
          <p>g) UCBTA 6th Part – BORM Initiation Statement
The BORM Initiation is equivalent to the Use Case Main Success Scenario initial
step.
h) UCBTA 7th Part – Defining Use Case Steps
The Use Case Steps are symbolized as u1, u2, u3……un and the corresponding sub
steps as u1A, u1B, u2A, u2B,…… unA, unB , n є N*
i)</p>
          <p>UCBTA 8th Part – BORM Action specification
If BORM Action is symbolized as BA, then the relation which involves the BORM
Action and the Use Case Steps will be the following:
BA = {u1, u2, u3……un}
and
u1={ u1A, u1B, …},
u2={ u2A, u2B …},
un ={ unA, unB …} , n є N*
j)
k)
l)</p>
          <p>UCBTA 9th Part – Design the Use Case Diagram
UCBTA 10th Part – Define BORM Data Flows</p>
          <p>BORM Diagram Construction (Object Relation Diagram)
m) UCBTA Output: BORM Result
UCBTA Transition Rules. Transformation models are inadequate in the case that
part of data is lost during the execution of the transition from the one model to the
other. For the precise comprehension of how data loss is eliminated during the
transformation of the Use Case Model to the BORM business process requirement
analysis approach, the author’s concept is based on the creation of specific
regulations that cover all the cases according to which the Use Case Main Success
Scenario comprised of steps and sub steps is converted to BORM data flows, states
and activities. Throughout the sections that follow the above mentioned regulations
called UCBTA Transition Rules are analyzed in detail.</p>
        </sec>
        <sec id="sec-3-2-2">
          <title>3.1 Basic UCBTA Transition Rule</title>
          <p>The basic type of the UCBTA transition rules comprises of the core transition from
the Use Case Model to the BORM Business Process model. Throughout the core
UCBTA transition, it is depicted how precisely a basic Use Case step of the main
success scenario is diagrammatically adjusted to the BORM approach and
represented by the BORM Process – Participant interaction model. The Process –
Participant interaction model is also entitled as BORM Diagram. In the case that the
above mentioned basic main success scenario Use Case step is divided into several
sub steps the constructed BORM Diagram includes the aforementioned sub steps as
well as they are described throughout the BORM method.</p>
          <p>Let us assume a delineated Process A and its corresponding Use Case A. The Use
Case analysis also involves Actors who take part in the process and are defined as
Actor A and Actor B who are expressed as participants in BORM. Moreover, the Use
Case step of the main success scenario is defined in the following way:
1.</p>
          <p>Actor A sends message to Actor B
The aforementioned step is supposed to be comprised of the following sub steps as
well:
1a) Actor A expects reply
1b) Actor B receives message
1c) Message received by Actor B
The main goal is the transformation of the above written step and its subs steps to
BORM activities flows and states, without any loss of data.</p>
        </sec>
        <sec id="sec-3-2-3">
          <title>3.2 Primary or Initial Step UCBTA Transition rule</title>
          <p>The second type of the analyzed rules of the Use Case transition to BORM is the
Primary UCBTA Transition. Throughout the primary transition it is explained by the
author how the Initial and the second step of the main success scenario are
transformed to BORM activities, states and data flows.</p>
          <p>The delineation of the primary transition is initiated with the assumption that
UCBTA requirement analysis has to be performed for Process A. It is also assumed
that the corresponding Use Case which is related to the aforementioned process is
Use Case A.</p>
          <p>The Use Case analysis also involves actors who take part in the process and are
defined as Actor A and Actor B who are expressed as participants in BORM.
Moreover, the initial and the second step of the main success scenario are defined in
the following way:
1. Actor A sends message to Actor B
2. Actor B sends reply message to Actor A
Considering the initial step of the main success scenario the sub steps involved are:
1a) Actor A expects reply
1b) Actor B receives message
1c) Message received by Actor B
2a) Actor B expects new info message
2b) Actor A receives reply
2c) Reply message is received by Actor A</p>
        </sec>
        <sec id="sec-3-2-4">
          <title>3.3 Middle Step UCBTA transition</title>
          <p>The second type regarding the UCBTA Transition rules is the Middle Step UCBTA
transition. The specific type follows exactly the same transformation path as the
Primary UCBTA transition type; the main difference due to which the two types are
distinguished is the fact that the Middle transition type refers to middle Use Case
steps.</p>
          <p>Provided that the UCBTA requirement analysis is implemented for a defined Process
B, the corresponding Use Case B is defined as well. An additive assumption is that
the Use Case Steps of which the analyzed Use Case main success scenario is
comprised is n, where n є N*.</p>
          <p>The Middle UCBTA Transition rule is applied for steps k and k+1, where 2&lt;k&lt;n,
k+1 &lt; n and k, n є N*. The steps and sub steps of the main success scenario will be
defined in the same way as in the primary UCBTA transition rule, and the BORM
aspect is depicted (Fig.4) the BORM Diagram. It can be noticed that the difference
with the first rule is that the middle step transition in BORM is without starting or
ending points.</p>
        </sec>
        <sec id="sec-3-2-5">
          <title>3.4 Conditional UCBTA Transition Rule</title>
          <p>The final type of the analyzed rules of the Use Case transition to BORM is the
Conditional UCBTA Transition. The specified UCBTA transition rule is based on the
fact that one or more steps of the Use Case main success scenario could lead the
process in many different states.</p>
          <p>1. Actor A sends message to Actor B
2. Actor B replies to Actor A, if the message is recognized
3. Actor B rejects message, if message is not recognized, and procedure
terminates
Considering the initial step of the main success scenario the sub steps involved are:
1a) Actor A expects reply
1b) Actor B receives message
1c) Message received by Actor B
In the same way the second step includes the following sub steps:
2a) Actor B expects new info message
2b) Actor A receives reply
2c) Reply message is received by Actor</p>
        </sec>
      </sec>
      <sec id="sec-3-3">
        <title>3.5 UCBTA Case Study – Greenhouse Integrated Pest Management Business</title>
        <sec id="sec-3-3-1">
          <title>Process Requirement Analysis</title>
          <p>
            Integrated Pest Management (IPM) is defined by many experts as a sustainable
approach to managing pests that combines biological, cultural, physical, and
chemical tools in a way that minimizes economic, health, and environmental risks. It
is a proven approach that balances economic, environmental, and health objectives
[12], [15], [
            <xref ref-type="bibr" rid="ref3">3</xref>
            ].
          </p>
          <p>Throughout the current research, the Evaluation of Pesticide Effectiveness Business
Process is analyzed via the UCBTA approach to requirement analysis at a business
level as a demonstrative Case Study.</p>
          <p>Input Part – Process Definition: “Evaluation of pesticide effectiveness through
monthly record keeping”
Use Case Definition: “Evaluate pesticide effectiveness through monthly record
keeping”
BORM General Function: “Economic IPM Administration” According to the
mathematical model of the UCBTA algorithm, the Use Case To BORM transition
can be continued since evaluation of pesticide effectiveness through monthly record
keeping is also part of a general Economic IPM administration.</p>
          <p>Defining Actors: The Actors involved in the current Use Case are the following:
IPM Management System (Computer System, Database Derver)</p>
          <p>Grower
BORM Participants: BORM participants are the same as the Use Case Actors:
IPM Management System (Computer System, Database Derver)</p>
          <p>Grower
Use Case Main Success Scenario Initial Step: “Grower selects monthly report task
with regard to the amount of pesticide consumed”.</p>
          <p>BORM Initiation: “Grower selects monthly report task with regard to the amount of
pesticide consumed”
Use Case Steps definition:
A) Main Success Scenario
1) Grower selects pesticide monthly report task
2) Computer System demands time period
3) Grower stores time period data
4) Computer System demands registration number of the pesticide
5) Grower stores pesticide data
6) Computer System sends pesticide information to the Database Server
7) Database Server produces monthly pesticide data report and message about its
effectiveness
8) Computer System displays message to the grower for the pesticide effectiveness
B) Sub steps
1a) Computer System receives pesticide monthly report command
1b) Selection is obtained by the Computer System
1c) Grower awaits response
2a) Grower receives time period demand by the system
2b) Computer System awaits data
2c) Demand (for time period data) is received by the user
3a) Grower expects registration number request
3b) Computer System receives expected time period data
3c) Time period data is obtained by the Computer System
4a) Grower receives pesticide registration number request
4b) Computer System expects registration number
4c) Pesticide registration number is obtained by the Grower
5a) Grower expects system’s pesticide report
5b) Computer System receives registration number
6a) Database Server receives monthly data of the used pesticide
6b) Computer System expects server report
6c) 4 week pesticide information is obtained by the DB Server
7a) Computer System receives monthly pesticide report
8a) Grower obtains monthly pesticide effectiveness report and corresponding action
message
Main success scenario, as a subset of the BORM General Function: It should be
mentioned once more that the main success scenario must be a subset of the BORM
function; the aforementioned Use Case scenario comprises of a standard subset of the
BORM General Function; consequently the model transformation algorithmic
procedure can be normally continued.</p>
          <p>Use Case Diagram: The Use Case Diagram which is related to the business process
requirement analysis of the Pesticide effectiveness evaluation through monthly
record keeping process will be designed according to Fig. 5
Defining the BORM Data flows: The BORM Data flows are related to the analyzed
throughout the previous section concepts of the Business Process Diagram.
Communication between participants, states, and transitions are defined in terms of
ORD (Object Relation Diagram or Business Process Diagram) construction.
Design the BORM Diagram (Process – Participant Interaction Model or Object
Relation Diagram (ORD)) (FIG. 6)
UCBTA Output – BORM Result: BORM Result is equivalent to the final step or sub
– step of the Use Case Main success scenario.
“Grower obtains monthly pesticide effectiveness report and corresponding action
message”.</p>
          <p>Fig. 6 BORM Diagram of the IPM Process
4</p>
        </sec>
      </sec>
      <sec id="sec-3-4">
        <title>Conclusion</title>
        <p>The most critical phase of the application or system development is the requirement
analysis phase. Throughout the concrete phase the business needs of the end users are
defined and analyzed by the IT experts. The most significant of the Object – Oriented
methodologies to requirement analysis, named as Use Case analysis, is not adequate
for that purpose if it is not followed by an equally tested and pure Object – Oriented
approach; the concrete approach is the Business Object Relation Modeling (BORM).
For the above stated reason the Use Case to BORM Transformation Algorithm
(UCBTA) is introduced as a complete solution for implementing efficient business
process requirement analysis. The most important part of the transition from the Use
Case model to the BORM approach to requirement analysis is the creation of specific
rules that cover all the cases according to which the Use Case Main Success Scenario
comprised of steps and sub steps is converted to BORM data flows, states and
activities and as a result data loss is eliminated and end users utterly comprehend the
business process functionality. The UCBTA methodology can be successfully
implemented on complicated Greenhouse Integrated Pest Management computer
based business processes, throughout the initial phase of a Greenhouse Information
System Integration.</p>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Stiglitz</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          (
          <year>2002</year>
          )
          <article-title>Globalisation and its discontents</article-title>
          . London: Allen Lane.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Aggleton</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Chalmers</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          (
          <year>2000</year>
          )
          <article-title>Nursing models and nursing practice</article-title>
          . 2nd ed. Basingstoke: Macmillan.
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Taruskin</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          (
          <year>1988</year>
          )
          <article-title>The pastness of the present and the present of the past</article-title>
          . In Authenticity and Early Music, ed.
          <source>N. Kenyon</source>
          , p.
          <fpage>137</fpage>
          -
          <lpage>207</lpage>
          . Oxford: Oxford University Press.
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Colley</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Banton</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Down</surname>
            ,
            <given-names>J</given-names>
          </string-name>
          and
          <string-name>
            <surname>Pither</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          (
          <year>1992</year>
          )
          <article-title>An expert-novice comparison in musical composition</article-title>
          .
          <source>Psychology of music, 20</source>
          , p.
          <fpage>124</fpage>
          -
          <lpage>34</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Cuperus</surname>
            <given-names>G. W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mulder</surname>
            <given-names>P. G.</given-names>
          </string-name>
          , and
          <string-name>
            <surname>Royer</surname>
            <given-names>T. A.</given-names>
          </string-name>
          ,
          <article-title>Insect Pest Management Techniques for Environmental Protection, Chapter 6</article-title>
          ,
          <string-name>
            <given-names>CRC</given-names>
            <surname>Press</surname>
          </string-name>
          <string-name>
            <surname>LLC</surname>
          </string-name>
          ,
          <year>2000</year>
          , ISBN 1-56670-478-2
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Flint</surname>
            <given-names>M.L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Daar</surname>
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Moinar</surname>
            <given-names>R.</given-names>
          </string-name>
          ,
          <article-title>Establishing Integrated Pest Management Policies and Programs: A guide for public agencies</article-title>
          , University of California,
          <source>Division of Agriculture and Natural Resources</source>
          ,
          <year>2003</year>
          , ISBN 978-1-
          <fpage>60107</fpage>
          -267-2
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>ATTRA</surname>
          </string-name>
          <article-title>(Appropriate Technology Transfers for Rural Areas), Integrated Pest Management for Greenhouse Crops</article-title>
          ,
          <source>Pest Management Systems Guide, ISBN 800-346-9140)</source>
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Knott</surname>
            ,
            <given-names>R. P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Merunka</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Polak</surname>
            ,
            <given-names>J.:</given-names>
          </string-name>
          <article-title>The BORM methodology: a third-generation fully object-oriented methodology</article-title>
          ,
          <source>in: Knowledge-Based Systems Elsevier Science International New York, ISSN 0950-7051</source>
          (
          <year>2003</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>