![]() |
| ![]() |
| ![]() |
|
UMLTM Parsing Analysis of the Telelogic white paper
"Using UML2.0 to Solve Systems Engineering Problems" Parsed source: Author: Andy Gurd, Senior Project Manager, Telelogic Title: Using UML2.0 to Solve Systems Engineering Problems URL: http://www.telelogic.com/download/get_file.cfm?ID=3541 (opens in new window) Copyright: unknown: please advise UML Parsing Analysis: Parser: Darren Kelly UML version: 2.0 (partial) Tool: Magicdraw UML 9.0 URL: ./white_paper (opens in new window)
This UMLTM Parsing Analysis of Andy's paper is presented as very large exported images in a folder in a separate window without metadata or further commentary. The images are NOT numbered after the paper, but to order them in the folder. Navigate with your back button. This is a very interesting paper. I would go so far to suggest it is a "must read" for anybody interested in the gulf (and it is that) between systems engineering culture and Unified Modelling Language (UML)TM, that UML2.0TM aims to address. So it might come as a surprise that my parsing of it, and many suggestions for improvements of the diagramming technique - seems so very critical at times. To students of the Unified Modelling Language (UML)TM I say: Please DO NOT DIAGRAM they way Andy does here. He is using many techniques that are obsolete, and are no longer necessary with UML2.0TM and modern UML tools supporting UML2.0 notation. In particular, note my use of reusable port classes rather than just port names (which afford no reuse). Let the port class tell you what the port is unless it has a special 'role'. If you are a student your lecturer will probably tell you that Darren Kelly is a nutter (which is true in any case and proves nothing) and to do it the old way. Ignore them. Time will show that my technique is much better. And your hands will love you for it. Give my way a go, make the experience of it in a modern tool like MagicDraw UMLTM and you'll understand what I am doing and why. Then teach your lecturer. Even some UML experts may disagree with me on my 'allergy' to named ports. Please try my way nevertheless. Yes, the port has a name (the attribute). One does not have to, and SHOULD NOT, show the name during my design technique. In most cases the default name COULD be automagically generated as the lower case version of the class name (unless it has a special "role"), which is my proposal for the next generation of UML tools supporting executable UML. Show the port _class_ and name port classes functionally. Rely on the class name (for ports and otherwise) whenever possible. This is very important for achieving executable UML2.0TM with JavaTM after my approach, and for maximising reuse, and I want you to develop the habit now. It is also important for fractal ports - ports that have ports - and you SHOULD be thinking about those, too, for that's how the universe seems to work. And please avoid interace names like "IMissile"; let interfaces be UML 'Interface' model elements (und Schluss) ! What Andy is showing you is a throwback to the early days of Unified Modelling Language (UML)TM where 'I' was used to indicate classes used as interfaces (before dedicated interface model elements). You'll find a lot of lecturers doing that one. Don't do it ! Don't do it ! Don't do it ! (Andy was allowed to do it in July 2003, you are not to do it in 2005+.) Indeed one of the reasons I chose the paper for this important work is that it contains elements that are no longer necessary under the current UML2.0TM specification, masochist that I am: To Andy: I hope you understand that my going to so much effort to rip your diagrams apart is the greatest complement ! It has really helped me distill my ideas on port-based systems engineering, and I am very grateful. And at least you had the guts to actually model something, which is more than I can say for many authors writing about UML2.0TM (and only writing, no more). My own analysis still has some obvious errors in it, and I only parsed selected parts of the paper. I've run out of time and interest for now. It is hopefully useful as is. Well of course it is, it's a lot of work, and I know why I did it, why else would someone do such a thing for days ? I am indeed the UML Parser :) To get the most out of my parsing you SHOULD read Andy's paper first ! I suggest you SHOULD probably read his paper anyway, it is important. And so is UML2.0TM. Yes, this is quite a lot to take in, but UML2.0TM is not for cowards or the lazy. Please enjoy, and don't play with missiles, they are not toys (and neither is real systems engineering, sometimes it gets very serious). Luckily Andy's "Missile Control System" will not be killing anybody, as it's demonstrably not under consistent model-driven development of a real system ! Then again, few of the UML2.0TM "examples" I've seen are. Darren, 2005-04-07 PS: The telelogic UML tool is probably a very good one, I just have not used it yet. Thanks to Telelogic for supporting the Unified Modelling Language (UML)TM community. Related links |