++++++++++++++++++ FME2001: - Review reports for paper 54 +++++++++++++++++++++ - 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: 54 CATEGORY: 1 TITLE: Extending the UML for Managing the Software Architecture Landscape in a Large Enterprise AUTHOR(S): Christian J=E4nsch Christoph Maier Thomas Tensi -------------------------------------------------------------------------------- 1. Briefly SUMMARIZE the paper (2-3 lines): The paper describes the ARCUS method, which is a method based on an extension of UML for describing enterprise architectures. Four layers are distinguished: a process architecture layer, a problem domain layer, a logical application architecture layer and a system architecture layer. Tool support, based on the extension of a = commercial CASE tool, for the ARCUS method is briefly described.=09 2. RELEVANCE: Please provide a rating of the paper's relevance to the FME Symposium, using the scale: 0 =3D Out of scope 1 =3D Marginal interest 2 =3D Minority interest 3 =3D Majority interest 4 =3D Outstanding interest Numeric Rating: 0 Please comment your rating: The paper is not about formal methods but about architecture and UML 3. OVERALL RECOMMENDATION: Please provide a rating of the paper's acceptability, using the scale: 1 =3D Strong reject 2 =3D Weak reject 3 =3D Could go either way 4 =3D Weak accept 5 =3D Strong accept Numeric Rating: 1 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 =3D Know virtually nothing about this area 2 =3D Not too knowledgeable, but I know a bit 3 =3D Know a moderate amount, about average I'd say 4 =3D Not my main area of work, but I know a lot about it 5 =3D My area of work, I know it extremely well Numeric Rating: 4 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: New is the way UML is extended and used for this kind of problem. 6. How WORTHWILE is the goal of the authors? Comment: Very worthwhile 7. How well is this goal EXPLAINED and JUSTIFIED? Comment: Goals are well explained and justified 8. TECHNICAL QUALITY. Are the technical parts (definitions, statements, specifications, proofs, algorithms, etc.) SOUND? Comment: Yes. 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 work seems very applicable, I would be interested in using it = myself. 10. PRESENTATION: Describe the QUALITY of the writing, including suggestions for changes where appropriate. Comment: Clearly written and well presented. A coherent example would add to the = quality. I miss some conclusions in terms of follow-up work: what is to be done = next? 11. Were there any formatting or mechanical problems with this paper?: "have" should be "has", 3rd line of "1. Introduction". On page 3, 4th bullet, last sentence: reference in "(see section )" is = missing. Are the figures and length acceptable?: Yes. Are the references correct?: Yes 12. OTHER COMMENTS you believe would be useful to the author(s), including pointers to missing relevant work: I would have recommended accepting your paper if it had been for = another conference. +++++++++++++++++++++ End of FME 2001 Paper Review Report ++++++++++++++++++++++ PAPER NUMBER: 54 CATEGORY: 1 TITLE: Extending the UML for Managing the Software Architecture Landscape in a Large Enterprise AUTHOR(S): Christian Jänsch Christoph Maier Thomas Tensi -------------------------------------------------------------------------------- 1. Briefly SUMMARIZE the paper (2-3 lines): The authors propose a notation for expressing several viewpoints related to architectural concerns in Enterprise. The model proposes several views which are defined on top of the UML. 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: 1 Please comment your rating: The paper would definitely better fit into a conference related to Software architecture or to UML. Most of the paper is not relevant to formal methods, except some very short sections on the proposed meta-model. 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: 1 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 authors propose a new set of notations for representing architectural views. Unfortunately, I am not convinced that this proposal is significant because similar efforts have already been done. In particular, i'd like to know how their work relates/distinguishes itself from the TINA/RM-ODP efforts performed by the telecom industry. 6. How WORTHWILE is the goal of the authors? Comment: The goal of the authors is to represent various aspects of software architecture. Finding out the right sets of notations is definitely a difficult issue and research into that direction makes sense. 7. How well is this goal EXPLAINED and JUSTIFIED? Comment: The paper is too short (10 pages). Most of the paper is a presentation of the notation by an example. The authors should take more space to better justify and detail their proposal and to compare with related work. 8. TECHNICAL QUALITY. Are the technical parts (definitions, statements, specifications, proofs, algorithms, etc.) SOUND? Comment: THis is not really relevant here. 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 proposed work seems applicable. It corresponds to the level of notations such as UML. 10. PRESENTATION: Describe the QUALITY of the writing, including suggestions for changes where appropriate. Comment: The paper is easy to read but too short. As far as its structure is concerned, I recommend that you spend more time detailing the fundamental concepts of each view. In particular, explain what each concept corresponds to, why it was needed, why you don't need more concepts (e.g. in section 4.3, you say tha the model elements are "application", "component", "module" , "data" but you don't explain the distinction between these e.g. is an Ada Package considered to be a component or a module?) 11. Were there any formatting or mechanical problems with this paper?: Are the figures and length acceptable?: too short Are the references correct?: There are only 6 references and most of them are not cited. 12. OTHER COMMENTS you believe would be useful to the author(s), including pointers to missing relevant work: I don't think your paper will be accepted for two reasons: a) the topic does not correspond to the conference b) even in UML or Architecture conferences, I don't think it would be selected because the paper merely presents the surface of a notation. I think it should be more precise, and provide more justifications for the concepts (in particular by a comparison with related work). Some examples: in section 4.1 you explain that your Business Process Layer is "very similar to the UML activity diagrams". So the reader wonders why you need a new notation and what distinguishes it from that particular UML diagram. As mentioned earlier, section 4.3 does not explain the difference between "module" "component" and "application". Is a Unix executable program, used as a filter (e.g. sort), considered as a component or as an application? Your notion of "derived relation" seems to be an interesting and original concept. But you should define it more clearly and precisely. Your work seems to be related to the following reference which do not appear in your bibliography @Article{Kruchten:1995:VMA, author = "Philippe B. Kruchten", title = "The $4+1$ view model of architecture", journal = "IEEE Software", volume = "12", number = "6", pages = "42--50", month = nov, year = "1995", coden = "IESOEG", ISSN = "0740-7459", bibdate = "Sat Jan 25 07:35:26 MST 1997", acknowledgement = ack-nhfb, affiliation = "Rational Software", affiliationaddress = "Richmond, BC, Can", classification = "722.2; 723.1; 723.2; 723.5; 921.6", journalabr = "IEEE Software", keywords = "Computer architecture; Computer hardware; Computer software; Data structures; Development view; End users; Iterative methods; Mathematical techniques; Physical view; Process view; Program documentation; Program processors; Software architecture; Software configuration; Software engineering; Synchronization; User interfaces; View-model", } +++++++++++++++++++++ End of FME 2001 Paper Review Report ++++++++++++++++++++++ PAPER NUMBER: 54 CATEGORY: 1 TITLE: Extending the UML for Managing the Software Architecture Landscape in a Large Enterprise AUTHOR(S): Christian Jänsch Christoph Maier Thomas Tensi -------------------------------------------------------------------------------- 1. Briefly SUMMARIZE the paper (2-3 lines): The paper presents an extension of the UML which has been developed to describe the architecture of the software application landscape in a large enterprise. 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: this paper reports on an application of (semi-)formal methods in a "real" project in a large enterprise. It tackles the crucial problem of the complexity of dependencies between different software applications which large enterprises have to face. 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 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: 4 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 significance of the work is that the method proposed in this paper does not only consider the architecture-in-the-small of a single application, but that it deals with the complexity of the dependencies between different applications. This complexity is a problem large enterprises have to face. The modeling language used in the approach has been obtained by tailoring the UML in such a way that it can address different audiences as the management and the developing project. This is achieved by providing a layered architecture model containing different aspects of a software system (business processes, business notions, logical application architecture layer, system architecture layer). 6. How WORTHWILE is the goal of the authors? Comment: the goal of the authors is to contribute to the compatibility of hardware and software systems within the enterprise. This goal is of crucial importance for enterprises. 7. How well is this goal EXPLAINED and JUSTIFIED? Comment: the goal is explained and justified in a convincing way. Some more information might be given on the embedding of architecture management into the organisation. In the abstract it is mentioned that "to implement this method tools are vital, but also new roles within the organisation have to be established". Therefore, it would be interesting to get some information on these roles. 8. TECHNICAL QUALITY. Are the technical parts (definitions, statements, specifications, proofs, algorithms, etc.) SOUND? Comment: The technical parts of the paper (Figure 2: extract from the ARCUS metamodel and chapter 5: Specific Metamodel Constructs) look sound. In section 5.2 (derived relations) it would be helpful if some definition of the notion of a "transparent element" was given. 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 ARCUS-method presented in the paper has been implemented by a tool and has been applied in a large enterprise. 10. PRESENTATION: Describe the QUALITY of the writing, including suggestions for changes where appropriate. Comment: The paper is written in a well-structured, clear and understandable way. 11. Were there any formatting or mechanical problems with this paper?: no Are the figures and length acceptable?: the length is such that some details might still be included (see comments below). Are the references correct?: the references themselves seem to be correct, but some of them are not referred to from within the paper. 12. OTHER COMMENTS you believe would be useful to the author(s), including pointers to missing relevant work: 1. Figure 2: Extract from the ARCUS metamodell for modeling business processes: the referee is aware of the fact that this is meant only to be a part of the metamodell for business processes. But since in section 5.1 it is said that the "role" is central in modelling business processes, it might be considered to include this concept also in Figure 2. 2. Section 4.5: Inter-Layer-Relationships There is still space in the paper for an example involving inter-layer-relationships. 3. It would be interesting to have some information on experiences obtained by the introduction of ARCUS in the organisation. 4. In the list of references the referee misses some reference to the ARIS method (architecture of integrated information systems) [e.g. Scheer, A.-W. Business Process Frameworks, Springer, 1998]. ARIS provides a visual language for the description of business processes, which also allows to interconnect business processes with supporting software components. 5. Minor Details - page 3, first paragraph of the enumeration, last sentence: "The altogether about 50 stereotypes for classes for a proper hierarchy". The second "for" has to be replaced (perhaps by form??). - page 3, last paragraph of the enumeration: (see section ). The section number is missing. - page 6, Figure 4, left box: there is an arrowhead missing (in the link between "travel data" and "travel expense system"). - page 8, paragraph below Figure 6: "e.g. between "activity 1" and subA11". Should it not rather be subA21 instead of subA11 ? +++++++++++++++++++++ End of FME 2001 Paper Review Report ++++++++++++++++++++++