UML collaboration diagram syntax: an empirical study of comprehension. Purchase, H., H., Colpoys, L., McGill, M., & Carrington, D. In … for Understanding and …, pages 13-22, 2002. IEEE Comput. Soc. abstract bibtex The UML syntactic notation used in texts, papers, documentation and CASE tools is often different, despite UML being considered a software engineering standard. Our initial empirical study considered variations in the notation used for UML class diagrams; the experiment reported concentrates on UML collaboration diagrams. The decision as to which of the semantically equivalent notational variations within the UML standard to use appears to be according to the personal preference of the author or publisher, rather than based on any consideration of the ease with which the notation can be understood by human readers. This paper reports on an experiment that takes a human comprehension perspective on UML collaboration diagrams. Five notations were considered: for each, two semantically equivalent (yet syntactically or stylistically different), variations were chosen from published texts. Our experiment required subjects to indicate whether a supplied pseudo-code specification matched each of a set of experimental UML collaboration diagrams. The results reveal that our informal, personal intuitions (which were based on our view of the complexity of the notation) are validated with respect to confirming that a specification matches a diagram, but not when errors in a diagram are to be identified. The subjects' preferences are in favour of the more concise notational variants.
@inProceedings{
id = {de53b397-fede-358b-8a63-69f4aebfbe6c},
title = {UML collaboration diagram syntax: an empirical study of comprehension},
type = {inProceedings},
year = {2002},
identifiers = {[object Object]},
keywords = {Collaboration,Computer aided software engineering,Documentation,Humans,Information technology,Performance analysis,Software engineering,Software standards,Standards publication,UML class diagrams,UML collaboration diagram syntax,Unified modeling language,diagrams,human comprehension perspective,pseudo-code specification,semantically equivalent notational variations,software engineering,specification languages},
created = {2014-11-04T17:14:10.000Z},
pages = {13-22},
websites = {http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1019790,http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1019790},
publisher = {IEEE Comput. Soc},
accessed = {2014-10-29},
file_attached = {false},
profile_id = {6b46cd49-f8a1-3799-91ac-6861cf9a050e},
group_id = {f76fdab6-f3b3-324f-8ded-1f7ff6220077},
last_modified = {2014-11-14T20:41:25.000Z},
read = {false},
starred = {false},
authored = {false},
confirmed = {true},
hidden = {false},
short_title = {Visualizing Software for Understanding and Analysi},
abstract = {The UML syntactic notation used in texts, papers, documentation and CASE tools is often different, despite UML being considered a software engineering standard. Our initial empirical study considered variations in the notation used for UML class diagrams; the experiment reported concentrates on UML collaboration diagrams. The decision as to which of the semantically equivalent notational variations within the UML standard to use appears to be according to the personal preference of the author or publisher, rather than based on any consideration of the ease with which the notation can be understood by human readers. This paper reports on an experiment that takes a human comprehension perspective on UML collaboration diagrams. Five notations were considered: for each, two semantically equivalent (yet syntactically or stylistically different), variations were chosen from published texts. Our experiment required subjects to indicate whether a supplied pseudo-code specification matched each of a set of experimental UML collaboration diagrams. The results reveal that our informal, personal intuitions (which were based on our view of the complexity of the notation) are validated with respect to confirming that a specification matches a diagram, but not when errors in a diagram are to be identified. The subjects' preferences are in favour of the more concise notational variants.},
bibtype = {inProceedings},
author = {Purchase, H.C. HC and Colpoys, L. and McGill, M. and Carrington, D.},
booktitle = {… for Understanding and …}
}
Downloads: 0
{"_id":"BpLXsNwEEkuC9fWsS","bibbaseid":"purchase-colpoys-mcgill-carrington-umlcollaborationdiagramsyntaxanempiricalstudyofcomprehension-2002","downloads":0,"creationDate":"2015-03-19T12:05:44.944Z","title":"UML collaboration diagram syntax: an empirical study of comprehension","author_short":["Purchase, H., H.","Colpoys, L.","McGill, M.","Carrington, D."],"year":2002,"bibtype":"inProceedings","biburl":null,"bibdata":{"id":"de53b397-fede-358b-8a63-69f4aebfbe6c","title":"UML collaboration diagram syntax: an empirical study of comprehension","type":"inProceedings","year":"2002","identifiers":"[object Object]","keywords":"Collaboration,Computer aided software engineering,Documentation,Humans,Information technology,Performance analysis,Software engineering,Software standards,Standards publication,UML class diagrams,UML collaboration diagram syntax,Unified modeling language,diagrams,human comprehension perspective,pseudo-code specification,semantically equivalent notational variations,software engineering,specification languages","created":"2014-11-04T17:14:10.000Z","pages":"13-22","websites":"http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1019790,http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1019790","publisher":"IEEE Comput. Soc","accessed":"2014-10-29","file_attached":false,"profile_id":"6b46cd49-f8a1-3799-91ac-6861cf9a050e","group_id":"f76fdab6-f3b3-324f-8ded-1f7ff6220077","last_modified":"2014-11-14T20:41:25.000Z","read":false,"starred":false,"authored":false,"confirmed":"true","hidden":false,"short_title":"Visualizing Software for Understanding and Analysi","abstract":"The UML syntactic notation used in texts, papers, documentation and CASE tools is often different, despite UML being considered a software engineering standard. Our initial empirical study considered variations in the notation used for UML class diagrams; the experiment reported concentrates on UML collaboration diagrams. The decision as to which of the semantically equivalent notational variations within the UML standard to use appears to be according to the personal preference of the author or publisher, rather than based on any consideration of the ease with which the notation can be understood by human readers. This paper reports on an experiment that takes a human comprehension perspective on UML collaboration diagrams. Five notations were considered: for each, two semantically equivalent (yet syntactically or stylistically different), variations were chosen from published texts. Our experiment required subjects to indicate whether a supplied pseudo-code specification matched each of a set of experimental UML collaboration diagrams. The results reveal that our informal, personal intuitions (which were based on our view of the complexity of the notation) are validated with respect to confirming that a specification matches a diagram, but not when errors in a diagram are to be identified. The subjects' preferences are in favour of the more concise notational variants.","bibtype":"inProceedings","author":"Purchase, H.C. HC and Colpoys, L. and McGill, M. and Carrington, D.","booktitle":"… for Understanding and …","bibtex":"@inProceedings{\n id = {de53b397-fede-358b-8a63-69f4aebfbe6c},\n title = {UML collaboration diagram syntax: an empirical study of comprehension},\n type = {inProceedings},\n year = {2002},\n identifiers = {[object Object]},\n keywords = {Collaboration,Computer aided software engineering,Documentation,Humans,Information technology,Performance analysis,Software engineering,Software standards,Standards publication,UML class diagrams,UML collaboration diagram syntax,Unified modeling language,diagrams,human comprehension perspective,pseudo-code specification,semantically equivalent notational variations,software engineering,specification languages},\n created = {2014-11-04T17:14:10.000Z},\n pages = {13-22},\n websites = {http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1019790,http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1019790},\n publisher = {IEEE Comput. Soc},\n accessed = {2014-10-29},\n file_attached = {false},\n profile_id = {6b46cd49-f8a1-3799-91ac-6861cf9a050e},\n group_id = {f76fdab6-f3b3-324f-8ded-1f7ff6220077},\n last_modified = {2014-11-14T20:41:25.000Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {true},\n hidden = {false},\n short_title = {Visualizing Software for Understanding and Analysi},\n abstract = {The UML syntactic notation used in texts, papers, documentation and CASE tools is often different, despite UML being considered a software engineering standard. Our initial empirical study considered variations in the notation used for UML class diagrams; the experiment reported concentrates on UML collaboration diagrams. The decision as to which of the semantically equivalent notational variations within the UML standard to use appears to be according to the personal preference of the author or publisher, rather than based on any consideration of the ease with which the notation can be understood by human readers. This paper reports on an experiment that takes a human comprehension perspective on UML collaboration diagrams. Five notations were considered: for each, two semantically equivalent (yet syntactically or stylistically different), variations were chosen from published texts. Our experiment required subjects to indicate whether a supplied pseudo-code specification matched each of a set of experimental UML collaboration diagrams. The results reveal that our informal, personal intuitions (which were based on our view of the complexity of the notation) are validated with respect to confirming that a specification matches a diagram, but not when errors in a diagram are to be identified. The subjects' preferences are in favour of the more concise notational variants.},\n bibtype = {inProceedings},\n author = {Purchase, H.C. HC and Colpoys, L. and McGill, M. and Carrington, D.},\n booktitle = {… for Understanding and …}\n}","author_short":["Purchase, H., H.","Colpoys, L.","McGill, M.","Carrington, D."],"bibbaseid":"purchase-colpoys-mcgill-carrington-umlcollaborationdiagramsyntaxanempiricalstudyofcomprehension-2002","role":"author","urls":{},"keyword":["Collaboration","Computer aided software engineering","Documentation","Humans","Information technology","Performance analysis","Software engineering","Software standards","Standards publication","UML class diagrams","UML collaboration diagram syntax","Unified modeling language","diagrams","human comprehension perspective","pseudo-code specification","semantically equivalent notational variations","software engineering","specification languages"],"downloads":0},"search_terms":["uml","collaboration","diagram","syntax","empirical","study","comprehension","purchase","colpoys","mcgill","carrington"],"keywords":["collaboration","computer aided software engineering","documentation","humans","information technology","performance analysis","software engineering","software standards","standards publication","uml class diagrams","uml collaboration diagram syntax","unified modeling language","diagrams","human comprehension perspective","pseudo-code specification","semantically equivalent notational variations","software engineering","specification languages"],"authorIDs":[]}