Enhancing UML Connectors with Behavioral ALF Specifications for Exogenous Coordination of Software Components

Round 1

Reviewer 1 Report

 

Summary：

       The authors abstract a new model to implement external coordination of components, thus reducing complexity and improving usability. The paper is also an expanded version of their previous study, with additional concrete implementations and application examples to demonstrate the validity of the proposed approach.

The quality of writing could be improved. The top-down organization is hard to follow, which could be more friendly for readers. In addition, the paper could add some tables to simplify the description.

Strength：

1.    The background and related work are introduced in great detail.

2.    The method proposed by the authors has shown the expected results in practical application.

Weakness：

1.    The abstract can begin with a description of the background, while simplifying the description of the specific implementation process.

2.    The advantages of ALF mentioned in Section 4.2 should be briefly introduced in Section 1 or Section 2.

3.    The abbreviation introduction can be placed at the front of the article or explained directly in the paper, otherwise it can be easily ignored when placed at the end.

4.    There is an extra letter ‘s’ at the end of the first paragraph on page 5. Please check it.

5.    The content of Figure 4 is inconsistent with the caption in describing subfigures (a) and (b).

6.    There are some grammatical errors at the end of page 6 and in the first point of Connector Behavior Specification, like ‘the case that involve’ or ‘Routing requests means’.

7.    Figure 6.b introduces a single FIFO request buffer. If requests are merged only when the FIFO buffer is full, this seems to increase the running time of the program. Why not perform the merge operation while caching the subsequent requests?

 

8.    The examples and applications in real-life projects in Section 6 and 7 demonstrate that the proposed approach increases reusability. Besides, is there any improvement in the efficiency of program initialization or execution?

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 2 Report

In the  present paper the  authors purpose an
approach for the specification of connector
behaviors in UML and present a well documented
examples arising from real-life avionics
software projects. The article is well written,
well structured and in a broad sense is
easy to read.
However, the current version of  the paper has some parts which
can improved, in order to adapt to the standard articles of the journal.
Mainly the following issues:

1.-  line 73, in ``We demonstrate the connector ...'' change the word ``demonstrate'',
  since it is usually used to the construction of a systematic proof.
 
2.-  line 92, the authors state that  `` Section 10 presents our discussions and future work'',
 but on section 10 it is not clear which is the future work. Please
 write an specific paragraph for future word.
 
3.-  in section 3 there is a single section labeled with 3.1, it is strange! my suggestion
 is split the current information in at least three subsections: 3.1 motivation, 3.2 problem statement
 and 3.3 the current section 3.1.
 
 

Conclusion : The results obtained in the paper are interesting.
However, some minor inaccuracies are necessary to be fixed.
After the revision I will have
no objection to recommend it for
publication in Applied Sciences.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

You should prepare a separate response file to answer the comments raised by the reviewers one by one.

Author Response

Thank you for your comment. We prepared a response file that answers the reviewers' comments one by one. We added the file inside the cover letter and uploaded it into the system. 

We improved the manuscript's language by simplifying long sentences and fixing minor grammatical errors. We believe that the text is significantly more readable in the final revision. Please see the uploaded diff.pdf file for round 2 for the revisions.

Author Response File: Author Response.pdf