![]() There is a well-known syndrome among software practitioners who are passionate about their craft, which is best summarized by the phrase “I can do it better.” Unfortunately, this often leads to “reinventing the wheel” syndrome, which seems to be the case here. This leaves the screen map and screen layout “diagrams,” which are indeed outside the scope of UML but that can certainly be combined with UML diagrams in precisely the same way as specified by Hugos. ![]() The system architecture diagram is a standard example of a UML collaboration diagram (including the use of PC, network and similar icons for the various components), and the software object model is yet another UML class diagram in which all the classes are artifacts. The logical data model of Hugos' approach is a limited form of UML class diagram (but one that seems to leave many open questions about aspects such as multiplicities and compositional relationships). The advantage of a profile as opposed to a homegrown notation is that one can take full advantage of standard UML tools as well as widely available UML expertise. ![]() ![]() Of course, these diagram types in UML offer many additional modeling capabilities, but for those who would prefer to keep things slim, it is always possible to define a UML profile that limits the diagrams to just the desired subset. Thus, Hugos' process flow diagram, which actually consists of two different diagram types (one representing structure, and the other data flow) combined with some rather monotonous-looking text, is really a special case of a UML class diagram with information flows (for the structural part) and a special case of the UML activity diagram (for the data flow part). (Although a picture may be worth a thousand words, for engineering purposes, it is critical that it speaks the same thousand words to each observer.) This often led to misunderstandings that went undetected until extremely late in development and required expensive rework. The latter is crucial, since a well-known problem with many modeling notations of the past was that their semantics were either undefined or vague. Like Moliere's Monsieur Jourdain, who spoke prose all his life without knowing it, Hugos may be surprised to discover that four of his five diagram types are either valid UML diagrams or can be mapped directly to corresponding UML diagrams, with one important difference: UML diagrams are composed of elements that have a standard semantics associated with them. In fact, its graphical nature has been a primary focus of criticism by those who prefer text-based languages. How else can one explain the startling statement that diagram-based approaches to software specification should be used instead of UML? UML is fundamentally a visual language with a diagram-oriented concrete syntax supported by a formal metamodel that defines its well-formed rules and semantics. However, Hugos' critique seems to be based on secondhand knowledge of UML at best. There are, no doubt, valid reasons to criticize UML from a technical perspective - after all, like Fortran, it is in many ways the first of a new generation of computer languages. ![]() 24 Computerworld column, “Five Diagrams Beat a 'Victorian Novel' Text Specification,” Michael Hugos states that Unified Modeling Language “can probably be blamed for many failed system development projects.” He ascribes this to UML's voluminous text-based approach (which he compares to Victorian novels) and, as a remedy, recommends his own homegrown, diagram-based method, since “a picture is worth a thousand words.” ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |