++++++++++++++++++ FME2001: - Review reports for paper 13 +++++++++++++++++++++ - Dear author(s) : this file was extracted automatically from a very large - mailbox. In case you find any problem concerning mail encodings (or any - other kind of anomaly disturbing your understanding of the reviews) please - email any of the PC cochairs (pamela@research.att.com,jno@di.uminho.pt). ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ PAPER NUMBER: 13 CATEGORY: 1 TITLE: Towards a Formal Framework for Object Oriented Architecture AUTHOR(S): Amnon H. Eden Yoram Hirshfeld -------------------------------------------------------------------------------- 1. Briefly SUMMARIZE the paper (2-3 lines): The paper proposes and discusses a framework in which properties of object-oriented design patterns can be formally specified. 2. RELEVANCE: Please provide a rating of the paper's relevance to the FME Symposium, using the scale: 0 = Out of scope 1 = Marginal interest 2 = Minority interest 3 = Majority interest 4 = Outstanding interest Numeric Rating: 2 - 3 Please comment your rating: The paper is about the combination of formal and informal techniques in which there is significant interest. 3. OVERALL RECOMMENDATION: Please provide a rating of the paper's acceptability, using the scale: 1 = Strong reject 2 = Weak reject 3 = Could go either way 4 = Weak accept 5 = Strong accept Numeric Rating: 4 - 5 NB: There should be a correlation between the two rates above. 4. CONFIDENCE LEVEL: Please provide a rating oof your expertise in the area addressed by the paper, using the scale: 1 = Know virtually nothing about this area 2 = Not too knowledgeable, but I know a bit 3 = Know a moderate amount, about average I'd say 4 = Not my main area of work, but I know a lot about it 5 = My area of work, I know it extremely well Numeric Rating: 5 NB: PC members are responsible for ensuring that 1 is not used here. 5. ORIGINALITY. What is NEW and SIGNIFICANT in the work reported here? Comment: The proposed framework provides a new way of expressing properties of object-oriented design patterns. 6. How WORTHWILE is the goal of the authors? Comment: The goal is to provide a means of formally reasoning about object-oriented design patterns, which are generally expressed in terms of informal notation. I believe this is worthwhile. 7. How well is this goal EXPLAINED and JUSTIFIED? Comment: The explanations and justifications are generally good. 8. TECHNICAL QUALITY. Are the technical parts (definitions, statements, specifications, proofs, algorithms, etc.) SOUND? Comment: Generally. However, I have a few fairly minor reservations. First, the set of ground relations defined in Table 1 does not allow the properties of parameters in methods to be specified although these play an important role in some patterns. In addition, some patterns have the property that certain entities (classes or methods) should be unique whereas in others they can occur multiply, and it does not seem as if the proposed framework can specify such a distinction. Second, patterns include relations between classes, which are modelled implicitly in this framework through the predicates Forwarding, Invocation, Inheritance, and Reference. (As an aside, the distinction between Forwarding and Invocation is not clear. Perhaps more explanation would be useful.) Some explanation of how these relate to the different types of relation found in the patterns, in particular relating to association and agregation relations, would help. Third, the distinction between rudiment C (Uniform sets) and Rudiment D (Higher Order Sets) is not clear, more especially since the same example is offered as an instance of both (factory methods in Abstract Factory pattern). Perhaps this could be clarified. Fourth, the definition of Discovery in section 5.1 effectively says that any subprogram is a pattern (because there is no constraint on the set of instances that must be identified). In general this is perhaps the best definition one can give, but it is hardly useful! Fifth, the claims on page 5 that clans, bijections and inheritance hierarchies occur in every GoF pattern is wrong -- none of these exist in the Singleton pattern, for example, and hierarchies and clans do not appear in the Memento pattern either (unless perhaps the definition of a clan applies to a single class). Finally, it is not clear that the notions of conciseness and compactness introduced in section 6 have any useful meaning. On could imagine an extremely concise definition of a pattern which depended on extremely complicated primitives, and which may then not be the most usable formulation. Perhaps the criterion is rather one of usability. But all such concepts are inherently almost impossible to quantify as one user may simply find one particular formalism more usable because he is already familiar with that formalism. I have some doubt about the usefulness of this section in its current form. 9. APPLICABILITY. If the work is primarily theoretical or conceptual, are the implications in terms of applicability adequately justified? If the paper is about a new formal technique, are satisfactory arguments presented in favor of the new technique? If a methodology is proposed, is it sound? If experimental results are presented, is their relevance justified? Comment: OK 10. PRESENTATION: Describe the QUALITY of the writing, including suggestions for changes where appropriate. Comment: The paper is generally well-written and understandable. I did notice a few typos: The last sentence in paragraph 3 of the introduction (beginning Clearly, coherent architectures ...) appears not to make sense -- two "such" clauses which don't appear to connect to each other. First paragraph of section 1.1, and also third paragraph of same section: deign -> design Example 1: BorderDecorato -> BorderDecorator Last but one paragraph on page 7: classed -> classes Missing reference at the top of page 14 11. Were there any formatting or mechanical problems with this paper?: No Are the figures and length acceptable?: OK Are the references correct?: OK 12. OTHER COMMENTS you believe would be useful to the author(s), including pointers to missing relevant work: +++++++++++++++++++++ End of FME 2001 Paper Review Report ++++++++++++++++++++++ PAPER NUMBER: 13 CATEGORY: 1 TITLE: Towards a Formal Framework for Object Oriented Architecture AUTHOR(S): Amnon H. Eden Yoram Hirshfeld -------------------------------------------------------------------------------- 1. Briefly SUMMARIZE the paper (2-3 lines): This paper presents a tentative formalisation of design patterns in order to give a precise definition of the architecture of object oriented systems. 2. RELEVANCE: Please provide a rating of the paper's relevance to the FME Symposium, using the scale: 0 = Out of scope 1 = Marginal interest 2 = Minority interest 3 = Majority interest 4 = Outstanding interest Numeric Rating: 3 Please comment your rating: Formalisation of patterns is important and should contribute to provide a bridge between semi-formal and formal methods. 3. OVERALL RECOMMENDATION: Please provide a rating of the paper's acceptability, using the scale: 1 = Strong reject 2 = Weak reject 3 = Could go either way 4 = Weak accept 5 = Strong accept Numeric Rating: 2 NB: There should be a correlation between the two rates above. 4. CONFIDENCE LEVEL: Please provide a rating oof your expertise in the area addressed by the paper, using the scale: 1 = Know virtually nothing about this area 2 = Not too knowledgeable, but I know a bit 3 = Know a moderate amount, about average I'd say 4 = Not my main area of work, but I know a lot about it 5 = My area of work, I know it extremely well Numeric Rating: 3 NB: PC members are responsible for ensuring that 1 is not used here. 5. ORIGINALITY. What is NEW and SIGNIFICANT in the work reported here? Comment: Formalizing patterns is a difficult task, and little has been done in this direction. The work presented in this paper is a first step. 6. How WORTHWILE is the goal of the authors? Comment: Design patterns are a good starting point to study OO architecture. Formalizing them is essential to avoid ambiguities, lack of precision and misunderstanding. 7. How well is this goal EXPLAINED and JUSTIFIED? Comment: This goal is well explained and justified. 8. TECHNICAL QUALITY. Are the technical parts (definitions, statements, specifications, proofs, algorithms, etc.) SOUND? Comment: Many definitions are too informal. For example : definition IV p. 9; definition VI p.12; definition VIII p. 13. The paper would have been much more convincing, had any definition been written in a formal language. The authors should avoid to use terms such as uniform -in Uniform Sets p. 4 - or compactness pp. 15-16 in an informal acception. The examples given by the authors to illustrate their definitions are often too simple: for instance, example 2 p. 9. In definition X p. 14, a variable of type F is substituted to a variable of type P(F) in a formula, and no mention is made of any restriction to this formula. 9. APPLICABILITY. If the work is primarily theoretical or conceptual, are the implications in terms of applicability adequately justified? If the paper is about a new formal technique, are satisfactory arguments presented in favor of the new technique? If a methodology is proposed, is it sound? If experimental results are presented, is their relevance justified? Comment: The paper is not really concerned with applicability, due to its exploratory character. Mentions to automation and tools - for example p. 13 - are too vague to be convincing. 10. PRESENTATION: Describe the QUALITY of the writing, including suggestions for changes where appropriate. Comment: There are many typos, for instance: p. 1 Abstract line 2 Formalism p.2 l.36 O-O deign p. 6 l. 11 from bottom : algebraic band p. 7 l. 5 To p. 9 l. 10 from bottom Creates instead of Creation in table 1 p. 9 l. 4 from bottom : Creates instead of Create in example 1... p.10 there is some confusion between extract 2 and extract 3 p.11 Formula 7: factory-method instead of Factory-method p. 14 Definition X: X is a free variable of X 11. Were there any formatting or mechanical problems with this paper?: Are the figures and length acceptable?: Are the references correct?: the reference XXX is not in the bibliography. Reference in note p. 15 is not in the bibliography All references http://www.math.tau.ac.il.... are inaccessible. The reference [24] does not contain definition of monadic logic. 12. OTHER COMMENTS you believe would be useful to the author(s), including pointers to missing relevant work: +++++++++++++++++++++ End of FME 2001 Paper Review Report ++++++++++++++++++++++ PAPER NUMBER: 13 CATEGORY: 1 TITLE: Towards a Formal Framework for Object Oriented Architecture AUTHOR(S): Amnon H. Eden Yoram Hirshfeld -------------------------------------------------------------------------------- 1. Briefly SUMMARIZE the paper (2-3 lines): A formal, set-theoretic model for the static aspects of design patterns is presented. Implementation and refinement of design patterns are formally defined. 2. RELEVANCE: Please provide a rating of the paper's relevance to the FME Symposium, using the scale: 0 = Out of scope 1 = Marginal interest 2 = Minority interest 3 = Majority interest 4 = Outstanding interest Numeric Rating: 3 Please comment your rating: Formal capturing of design patterns is of emminent importance for software engineering tools. 3. OVERALL RECOMMENDATION: Please provide a rating of the paper's acceptability, using the scale: 1 = Strong reject 2 = Weak reject 3 = Could go either way 4 = Weak accept 5 = Strong accept Numeric Rating: 3 NB: There should be a correlation between the two rates above. 4. CONFIDENCE LEVEL: Please provide a rating oof your expertise in the area addressed by the paper, using the scale: 1 = Know virtually nothing about this area 2 = Not too knowledgeable, but I know a bit 3 = Know a moderate amount, about average I'd say 4 = Not my main area of work, but I know a lot about it 5 = My area of work, I know it extremely well Numeric Rating: 3 NB: PC members are responsible for ensuring that 1 is not used here. 5. ORIGINALITY. What is NEW and SIGNIFICANT in the work reported here? Comment: The authors claim to provide a framework for formalising design patterns (architectures, as they call it). Alas, comparison or integration (with the static aspects) of other approaches, which, however, are mentioned [26, 27], is omitted. Thus, as introducing a framework, the significance of this paper is hard to tell. The formalisation of design patterns itself seems to be quite elegant; however, most of the notions captured by the formal model could be expressed in any other object-oriented modelling language, like UML, too. The major exception is the relation on methods "may call", which, in UML, could only be expressed by collaborations or some annotations (and has been realised as being useful before). 6. How WORTHWILE is the goal of the authors? Comment: Formalisation of design patterns is worthwile (at least for some authors; I don't think that all the essentials of design patterns can be covered formally); but, as mentioned above, I'm not sure about the necessity of building a framework to do so. 7. How well is this goal EXPLAINED and JUSTIFIED? Comment: The authors do not make clear why it is necessary to have a framework for formalising design patterns (I would not have denied that for architecture; but there is so much work on this). The introduced extensible model language is quite similar to UML or other modelling language, but is much simpler and more smooth, as it only uses entities and relations between these entities. This is a nice idea and is partly justified on p. 7. 8. TECHNICAL QUALITY. Are the technical parts (definitions, statements, specifications, proofs, algorithms, etc.) SOUND? Comment: p. 9, Def. IV: What are ground entities? p. 9, Def. IV: Model $M'$ in $M$: introduce the notion of sub-model. p. 9, Ex. 2: What's the interpretation of $\mathit{Creates}$? p. 11, Form. 7: What's the interpretation of $\mathit{tribe}$, $\mathit{Commute}$? p. 14, Def. X: How to replace a $2^\mathcal{T}$ by a $\mathcal{T}$? 9. APPLICABILITY. If the work is primarily theoretical or conceptual, are the implications in terms of applicability adequately justified? If the paper is about a new formal technique, are satisfactory arguments presented in favor of the new technique? If a methodology is proposed, is it sound? If experimental results are presented, is their relevance justified? Comment: The approach itself is promising and we would like to see this implemented! 10. PRESENTATION: Describe the QUALITY of the writing, including suggestions for changes where appropriate. Comment: The presentation is alright. The methodological remarks on p. 3 are too well-known... There are some typos: Page 1: - Supporting Formalisms -> formalisms - establish unambiguous -> establish an unambiguous - constructs such elementary building blocks and repeating abstractions -> ? Page 2: - of deign -> of design - O-O deign -> O-O design Page 3: - concepts O-O architecture -> concepts of O-O architecture (?) Page 4: - factory-methods vs. factory methods Page 5: - also that a $F$ -> also that $F$ Page 6: - comprehend. if -> comprehend. If - invocation to constructor -> invocation to a constructor - well formed -> well-formed (and passim) Page 7: - BorderDecorato::Draw -> BorderDecorator::Draw - However, To -> However, to - first class -> first-class (and passim) - contains one attribute -> contains an attribute - classed -> classes Page 8: - and $\mathit{collaborations}$ -> and where $\mathit{collaborations}$ - discussion in patterns -> discussion of patterns (?) - composite abstractions -> composite abstractions; Page 9: - well defined -> well-defined Page 10: - Where $\mathit{Mediator}$ -> where $\mathit{Mediator}$ Page 11: - defined as extension to UML -> defined as an extension of UML - 1st -> first - Table 1 respectively -> Table 1, respectively Page 12: - \emph{Validation} test -> \emph{Validation} tests - supports such process -> supports such a/this process - just add new -> just adds new Page 13: - assignments into -> assignments of - Assignment $A$ assigns both free variables with concrete entities -> Assignment $A$ assigns concrete entites to both free variables - designated -> designates - such process -> such a process - ``refine'' -> ``refines'' Page 15: - than it is necessary -> than is necessary Page 16: - subsets are not -> subsets that are not Page 17: - thank also to -> thank 11. Were there any formatting or mechanical problems with this paper?: Are the figures and length acceptable?: Are the references correct?: p. 10: Box Extract 3 p. 10: Where is Extract 2? p. 14, first line: Which reference is meant? 12. OTHER COMMENTS you believe would be useful to the author(s), including pointers to missing relevant work: I thinks that's interesting and good work; but I would definitely like to see some more results, a tool, or an application. +++++++++++++++++++++ End of FME 2001 Paper Review Report ++++++++++++++++++++++