Subject: Reference for C523 From: "Omer Rana" Date: Mon, 3 Sep 2001 18:05:00 +1000 (EST) To: fox@csit.fsu.edu X-UIDL: 06a7a8bed3210000 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Received: by mailer.csit.fsu.edu (mbox gcfpc) (with Cubic Circle's cucipop (v1.31 1998/05/13) Mon Sep 3 10:42:34 2001) X-From_: fox@mailer.csit.fsu.edu Mon Sep 3 10:31:51 2001 Return-Path: Delivered-To: gcfpc@csit.fsu.edu Received: from dirac.csit.fsu.edu (dirac.csit.fsu.edu [144.174.128.44]) by mailer.csit.fsu.edu (Postfix) with ESMTP id E1E2D23A04 for ; Mon, 3 Sep 2001 10:31:50 -0400 (EDT) Received: from localhost by dirac.csit.fsu.edu (AIX4.2/UCB 8.7) id KAA24484; Mon, 3 Sep 2001 10:31:50 -0400 (EDT) Resent-Message-Id: <200109031431.KAA24484@dirac.csit.fsu.edu> Delivered-To: fox@csit.fsu.edu Received: from wombat.cs.rmit.edu.au (wombat.cs.rmit.edu.au [131.170.24.41]) by mailer.csit.fsu.edu (Postfix) with ESMTP id EABC423A04 for ; Mon, 3 Sep 2001 04:15:09 -0400 (EDT) Received: from goanna.cs.rmit.edu.au (orana@goanna.cs.rmit.edu.au [131.170.24.40]) by wombat.cs.rmit.edu.au (8.9.3/8.9.3/cshub) with ESMTP id SAA29755 for ; Mon, 3 Sep 2001 18:05:06 +1000 (EST) Received: (from orana@localhost) by goanna.cs.rmit.edu.au (8.9.3/8.9.3/csnode) id SAA02423 for fox@csit.fsu.edu; Mon, 3 Sep 2001 18:05:01 +1000 (EST) Message-Id: <200109030805.SAA02423@goanna.cs.rmit.edu.au> In-Reply-To: <3B805F83.2010101@csit.fsu.edu> from "Geoffrey Fox" at Aug 19, 2001 07:53:23 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-To: Geoffrey Fox Resent-Date: Mon, 03 Sep 2001 10:31:49 -0400 Resent-From: Geoffrey Fox Hi, Reference attached. regards Omer ================================================================= C: Paper and Referee Metadata Paper Number Cnnn: C523 Date: SEPTEMBER 4, 2001 Paper Title: TOWARDS A COMMON DEVELOPMENT FRAMEWORK FOR DISTRIBUTED APPLICATIONS Author(s): FETHI A. RABHI Referee: OMER F. RANA Address: DEPARTMENT OF COMPUTER SCIENCE CARDIFF UNIVERSITY PO BOX 916, CARDIFF CF24 3XF, UK Referee Recommendations. Please indicate overall recommendations here, and details in following sections. ACCEPTED PROVIDED CHANGES SUGGESTED ARE MADE D: Referee Comments (For Editor Only) All comments for author and editor in section (E) below. E: Referee Comments (For Author and Editor) It is really hard to judge this paper, as it tries to cover a very large area of work. If the attempt is to bring together many different aspects of parallel and distributed computing together, then I would say that the author has succeeded in giving the reader a flavour of the pertinent themes in the area. I found the paper interesting to read, even though, as the author claims, the coverage is not meant to be exhaustive or complete. I have a rather contentious point about the title -- perhaps, it should have within it the word "Software Engineering" somewhere -- maybe? I would recommend the following additional references: ``An Object Oriented Framework for Data Parallelism'' J.-M. Jezequel, ACM Computing Surveys, Vol 32, Issue 1, 2000 http://www.acm.org/pubs/contents/journals/surveys/2000-32/ also in the same issue ``Programming languages and systems for prototyping concurrent applications'' Wilhelm Hasselbring and ``Selecting locking primitives for parallel programming'' P. E. McKenney, CACM 39, 10 (October), pp 75--82, 1996 My comments are based on the section in which they appear in the submitted paper. I hope they are useful to the author: SECTION 1: I am uncertain what is specifically different about the types of problems detailed here, that conventional software engineering techniques are not appropriate. For instance, many people have adopted existing SE approaches for developing Web based apps -- why are these approaches not suitable? SECTION 2.1: paragraph 1, line 3 I am not sure I understand what the author means by "should be minimal yet complete" Also, in the same section, some of the outlined requirements, such as "dynamic change management" are surely generally applicable, and therefore not necessarily a requirement of the outlined apps? This again brings me back to the previous comment of why the author thinks conventional approaches are not suitable. SECTION 3.2: paragraph 1, line 1 "formal methods are still far from being widely used" -- how does the author reach this conclusion, and under what context is this true? This is a very general statement, and should be grounded in the context of the on-going discussion. paragraph 2, line 2 not sure what "cycleromising" means paragrah 2, last line Why do practisioners feel these tools have limited value? Can the author provide a reference here? SECTION 4.2/4.3 There is no mention of the declarative style -- and what impact this is likely to have on developing modules. ALthough there is mention of agents towards the end of the paper, the particular approach adopted by this community is not discussed. SECTION 4.4 Why does the author feel that formal semantics are necessary. What is the overall objective of modelling here in the first place. paragraph 2, last line Not sure what "for static systems and do not ..." means SECTION 5.3 paragraph 3, last 2 lines Need more explanation about the patterns defined in figure 3 SECTION 5.4 paragraph 1 What is the impact of using a different design approach -- say a top down approach, rather than a bottom-up as recommended. What impact is this likely to have on the adopted styles? Also, what about hybrid approaches -- what issues arise in the use of these. paragraph 2, line 8/9 Give references for Parse and ADL paragraph 3 What the pitfalls in using the approach -- there is no discussion of this SECTION 6.2 There is no discussion of how relevant or valid are models such as BSP and PRAM for real world applications and architectures. What are issues in efficiency, performance, tool support etc (as identified in section 1 and 2 earlier in the paper) SECTION 7.2 There are lots of general statements here -- and I do not feel they have been truly quantified. For instance, the author claims that "most" structured OO design approaches do not provide replication structures -- which design approaches does he have in mind. How is this conclusion reached? Overall I find the paper interesting to read -- as it has tried to bring together many different ideas and themes. However, what the author has not done is provide a critique of existing approaches, or why they are inappropriate. The material is presented in a "as is" manner -- without direct comments from the author. Although a very time consuming task (and one which I do not necessarily advocate the author do), would be to have a working example (or multiple small examples) that are spread throughout the paper, and which highlight particular themes that the author is trying to suggest. The 2 examples in the Appendix do not fully bring out the issues that are highlighted and discussed in the paper. F: Presentation Changes SECTION 2.1 paragraph 3 (after bullet points), line 3 "serve" -> "serves" SECTION 2.2 second bullet point ("Interaction Management") delete "which components communicate with which" SECTION 4.1 pargraph 2, line 5 "occam" -> "Occam" SECTION 4.3 paragraph 2, line 2 second "that" -> "there" paragraph 6, line 2 "Ng ..." -> "Ng et al." SECTION 6.1 paragraph 1, line 2 insert a "," after the for second bullet point ("scalable" abstractions), after paragraph 4, line 2 re-phrase "the decomposition into tasks ..." SECTION 6.3 paragraph 1, line 8 remove second "include" SECTION 6.4 paragraph 3, line 8 remove "of" between `Several' and `such' paragraph 3, line 11 "than" -> "to" SECTION 7.1 line 8 insert "as" between `well' and `standard' Spelling error in Figure 4 in Implementation section "Secttion 5.2" -> "Section 5.2" REFERENCES Reference for CLEAVELAND, R should be CLEAVELAND, R. AND SMOLKA, S. A. This paper was written by many people -- and the actual reference says CLEAVELAND, R et al. SKILLICORN, D. and TALIA, D. -- replace "ans" -> "and" Spacing problem on "VICTOR, B." .