UML is first and foremost a communication tool, it helps you communicate ideas to other people on your team (or to yourself three months in the future), and as such, should be evaluated based on how easy it can express whatever you have in mind.
Being language-independent, UML cannot be used to express the expected, idiomatic way to use a given API or module, yet this is an essential part of the design: ignoring it can often end up with code that accurately models the underlying problem but requires dozens of lines of boilerplate code to interact with.
Also, UML cannot easily capture some specific properties of data structures that are relied on by algorithms. A red-black tree, for instance, is more easily represented by small tree-like sketches with "this is a red-black tree" or "this isn't a red black tree because" descriptions, than the corresponding UML class diagram.
Finally, languages may have features that are not represented elegantly in UML at all - for instance, Objective Caml module functors, or closures in any language that has them.
一切都有一个标准或“标准”？啊，是的，MS 的计算机方法，购买我们的装备，您会很高兴；如果没有，您只需购买更多我们的装备即可。这是愚蠢到了极点。 IT 中的每个学科领域都已经存在了很长一段时间，都是一个专门的领域，需要专门的资格和技能。一个好的数据建模者可能会成为一个糟糕的程序员，反之亦然。您不需要一位擅长剖腹产并进行脑部手术的妇科医生。
它如此受欢迎的原因是，如今，人们已经接受了 MS 生活方式的培训（任何人都可以成为程序员，不需要资格，只要你相信），并且在 OO/UML 中，他们看到了神奇的子弹（现在有了这个闪亮的新锤子，您也可以构建任何东西）。蛇油推销员。不要向元帅开枪，但事实是，没有灵丹妙药，你需要的不仅仅是一把锤子来建造任何东西，而且你需要投入坚硬的院子。
Good question, but a big question. First some context, the specific major failures, and then the specific answers.
Scroll down to UML * Gross Failures if you would like to skip the Context
UML is just the new kid on the block. Yeah sure, not so new as Agile; but new in comparison to what was available before.
It might help to understand something first. We have been using models, modelling techniques, and symbols for 40 years. They are many of them. The most common is not the most appropriate or successful (in the technical and purpose sense); it just happens to be the most advertised and "sold".
The second criterion re models is that it is a tool for communication, both between teams (different skill sets), and between teams and users. It gets silly when one team uses one set of symbols and another uses another set, or when the symbols are not meaningful to the user, who has to approve functional definitions, and funds the project.
We use standards for building bridges, so that they do not fall over (at least in developed countries); to ensure that the purchaser and the supplier mean the same thing when they draw a symbol for a standard bolt; and we use standards in IT to in the same way.
to convey unambiguous meaning for each symbol
to be complete (if it is a Data Model, then the relations are not missing)
to convey the complexities and subtleties of the design (which non-standard symbols and diagrams cannot). .
A word about Standards. The IT industry as deteriorated badly in the last 20 years. We have many unqualified and untrained people doing technical work. So there is a looseness and naïveté that is common in the smaller companies. Even the word standard has been hijacked. People talk loosely about "industry standards": actually there is no such thing, they simply mean whatever is most common in the industry. That is a convention, not a Standard.
Standards are set by international standards bodies. Not by a single vendor. Since MS have never complied with Standards, they have created their single-vendor anti-standard, and sought to monopolise the industry in that manner (illegal, which is why the US Justice Dept were able to take them apart quite easily.)
MS may be the most common PC or PC application software (Windows is not an OS, even though it passes for one), but it is not standard in any way, shape, or form.
Re (4) MS is famous for coming up with at least 20 (that I know of) tools for "modelling" databases, different for each product and version; each with a different set of cute symbols; but none of them are Standard
as a counterpoint, SQL is a Standard, identified by IEC/ISO and more recently, ANSI.
Sybase, DB2 and MSQL SQL Server comply with the SQL Standard (Oracle doesn't, even though they state that they do)
none of the freeware "SQLs" comply with the SQL Standard .
One Standard or "standard" for everything ? Ah yes, the MS approach to computers, buy our gear, and you will be happy; if not, you just need to buy more of our gear. It is stupid in the extreme. Each Subject Area in IT has been around for quite a while, a specialised area, requiring specialised qualifications and skills. A good Data Modeller may make a horrible programmer, and vice versa. You do not want a gynaecologist who is good with c-sections performing brain surgery.
Therefore, as the Standards bodies have recognised for decades, Standards are specific to a Subject Area
further, the Standards are Normalised. That means that a Standard in one Subject Area is integrated with the Standard in any other applicable Subject Area
By reference (without duplicating the whole text)
This allows each Standard to develop and progress on its own path, whilst maintaining its reference to other Standards
Standards are public domain, they are free (you might have to pay a printing price for a copy) .
The other reason One "standard" for all Subject Areas will never work, the reason for this gross inadequacy, is of course Maslow's Hammer, (if you bother to click the link, make sure you read the last sentence). To the man who only has a hammer in the toolkit, every problem looks like a nail. The authors of UML, as well as the Fowlers and Amblers of today, use a hammer for all tasks. A "database" is a nail; architecture is a nail.
Standards are also not set by groups of vendors or consortia, as they do not have the regulatory control or authority to put their stamp on submissions. Most of such consortia make their own submissions to themselves, there is no transparency or peer review or oversight.
UML may be marvellous and rich and all that (to those know nothing else), OMG may be a great consortium, but OMG is not an international Standards body, and the full UML (14 models) is not a Standard.
it is supported a consortium
it has not been accepted by any international Standards body
the portion that has been recognised as a Standard by ISO is the Object Class modelling portion only
it exists in it own universe, separate from the rest of the universe
they would like you to think it is a full-blown Standard, so they use the word all over the place
at the end of the day, it is about selling product
much like MS .
AFAIK, other than the ObjectClass Modelling portion, UML is not a Standard, there is no ISO/IEC/ANSI/NIST designation for the other portions. There are two reasons for that.
Re (6). Several different Modelling Standards, each highly specialised for its Subject Area, existed long before UML was hatched. Instead of extending the existing Standard Modelling techniques, as any qualified technical person would do, the authors created a completely new model. UML, in each of those Subject Areas does not come close to providing the utility of the Standard; does not comply with the Standard requirement; does not identify or convey the full meaning.
Example. Given that modelling data and modelling software are quite different sciences, with different rules, and that Databases are designed to be independent of any software that uses it, it is stupid to model a "database" using OO concepts or UML. Which is what OMG would have you do, and states UML can do. Just check the number of identical questions on SO, where OO types are stuck with this exact problem.
First, it will not be a Database in any way, shape or form; it will be only a data storage location. You will have none of the power or speed or integrity of a Relational Database.
Second, the sequence is backwards. Data does not change; programs do (frequently), so if you model the objects after modelling the data, nothing changes. But if you model the data after the objects, you spend your life incrementally changing both, going backwards and forwards.
Third, UML may be good for defining a data location to "persist" data to, but it is completely inadequate for defining the elements of a Relational Database. Since there has been a Standard for Modelling Relational Databases for 30 years, that provides complete difinition, you will be better off using that.
Re (7). It tries to do everything. First, due to its inadequacy in the Subject Areas, it does not stand a reasonable chance of displacing the established Standards. Second, it suffers the Jack of all trades, master of none problem.
Of course, OMG has 14 different UML models, which can be covered with 2 to 4 Standard models. Using that many different models, for different purposes, has an additional set of problems.
to be clear, UML replaces nothing. OO is relatively new. It only supplies OO Modelling for the OO portions of a project.
Last, UML is specialised for OO. And nothing but OO. As if the entire Universe was OO and nothing else existed. Even die-hard COBOL programmers aren't this blinkered. This is a very common and sad attitude among OO types who know nothing else about systems and IT, and it is generated by the idiots like Martin Fowler, who write about OO that way. This is the reason OO is limited to small projects, and why OO types fail miserably at anything outside OO, because they are unwilling to learn about any other Subject Area in depth. And why there has been perhaps 30 OO "database" products, over the last 15 years, and why all of them have failed.
Example. Fowler will first teach you how to create and implement incomplete classes and "persist" them to a "database". When that does not work, you have to buy the next book to figure out how to correct them, by adding more definition (er, no surprise). When you realise that you are correcting them an awful lot, and the corrections are in fact similar, you have to buy the next book to figure out how to "re-factor" the classes, automate the corrections, make sure they are all applied to the relevant locations at the same time. And each time, you will have to "re-factor" the "database" as well. Good for the OO types who have no other knowledge.
For IT professionals who do not "buy" fowling pieces, who have some knowlede and depth outside OO, can produce definitions, so that we do not waste time or money re-defining and re-factoring and re-implementing. We define and build once, then improve as necessary.
And we keep our software Normalised, so there is never a need to "re-factor", we just keep extending the classes and methods. Which is only possible if the initial structure had structure.
Since we Normalise and Model our Relational Databases, although the apps can keep changing and growing, we never need to "re-factor" the Database. Re-implementing code is expensive enough; the cost of re-implementing large Databases is prohibitive. Professionals are expected to avoid that.
The reason it is so popular, is that these days, people have been trained in the MS approach to life (anyone can be a programmer, no qualification required, if only you believe), and in OO/UML, they see the magic bullet (now with this shiny new hammer, you too, can build anything). Snake oil salesmen. Don't shoot the marshall, but the truth is, there is no magic bullet, you need more than a hammer to build anything, and you need to put in the hard yards.
UML • Gross Failure
The main failures of UML as a "standard", are these. This means the specific discrete issues with the diagrams and the "method", not the resulting problems that you will have if you use it (later).
One Symbol One rectangle for absolutely anything and everything.
With sections that are relevant to the 14 different types of diagrams. Whereas Standards have a different symbol for Data, vs Process, vs GUI, etc. Since there is no fixed set of items that are required to define a thing (14 types of things), each person implements what they think the thing is, or worse, what they know the thing to be, which is very little.
One does not know what creature one is looking at, or what the level of completeness is.
Too Few Minor Symbols Since it tries to do everything for everyone, and tries to "model" both small and large projects, there are many, many minor symbols.
Actually, too many (if you understand what I have stated above), there should be a few minor symbols for each of the 14 types of drawing, and they should be required, otherwise it is not a Standard, it is loose and floppy.
Nevertheless, the minor symbols are too few. In normal use, each person invents a few minor symbols of their own, to fill in the gaps in UML symbols. The result is of course, horrendous: each project team has various additional minor symbols that are not in UML, and thus not understood outside the project. The very opposite of the purpose of a Standard.
The result overall (not limited to one project team), is too many minor symbols, hundreds of them, some of which mean the same thing, and others which mean slightly (importantly) different things. . I stopped counting at 200.
Compared with genuine Standards, the above two points result in a gross lack of Definition in the documentation of objects (things), the very thing that is expected (demanded) from a Standard. It is a total failure at the first criterion of a Standard: *first and foremost, it is a communication tool. On receipt of a UML "model", in order to understand it, one has to set it aside and manually communicate with the author.
Last, but the most important ...
No Facility for Composition/Decomposition Analysis comes before Design, we need to analyse (as a science) what an application is supposed to do, before we can design (as a science) the program to implement it. (Unfortunately, these days, untrained people throw themselves at the Design phase, clueless that they do not know what the app is, because they have not analysed it. Guaranteed disaster.)
Both the Analysis phase and the Design phase demand the ability to look at the Function that the application comprises:
at different levels: a. from 10,000 metres: see the whole scope with little detail ... but all interfaces, [zoom out] or b. 1,000 metres, or c. 1 metre: see all detail for a small scope [zoom in] . That means, the ability to break the app into its Functions, first large components, and then again, into smaller components, until the smallest or Atomic components are defined (single Object or Function() or Stored Proc or Subroutine).
That affords Analysis, a complete phase of modelling, before achieving confidence to proceed with the next phase ...
That affords Design, now the objects and articles can be arranged and organised, Normalised, into a legitimate set of Functions. Normalised code means no function duplication.
IDEF0 and SSADM have full Composition - Decomposition. A large app is modelling using a tree structure (which the app is), on many pages, each page showing only what is relevant at that Level. (In addition to that, which cannot be skipped, if it is an OO client, we may have an UML diagram for those Objects only.
The result of using UML is, you get none of that.
No analysis is possible. Great, for those who do not know that Analysis is a science, that it is the first phase in any serious project.
No genuine design is possible. Great, for those who do not know that Design is a science, steps are relevant to the platform, etc. That it is the second phase in any serious project. People go straight into "designing" their OO objects, as if that is the centre of the universe. They even try to control their data integrity via these hilarious creatures.
In addition to not being designed, the app ends up being one great big monolith, with massive code duplication. A joke to genuine engineers.
Answer
First and foremost, make sure you acquire a few tools for your toolkit, and always use the right tool for the job.
OO is a fine idea, UML may be a great technique for modelling object classes, but it is completely inadequate for modelling anything else, or for communicating with users. The only users who will be impressed are those who fancy themselves as "technical" and who have not seen any Modelling Standard (ie. they have no point of reference, and are easily impressed).
At best, using accurate words, UML is a Standard for modelling Object Classes only and relevant to OO types only (ie. no specialised skills in any other subject Area). As in, I find it does not convey all the control and subtlety of modern object classes and complex Methods, and thus I have to add notations to the UML diagram to make it complete.
it is adequate for for small projects, which are to be modelled and implemented by OO types onlly.
I do not see much that is "unified", it is more of an anti-standard. It integrates with nothing, except (maybe) another of the 14 UML models.
We did not put men on the Moon, or build space shuttles for regular space flight or fighter aircraft, using UML. We did that using the following Standards. Standards are required (demanded ?) by banks and financial institutions (my ambit) and govt depts in developed countries. As per (6), they are all integrated with each other:
SSADM (the Gane & Sarson original, not the volumes created by others) , in particular the Data Flow Diagramsfor Function Modelling. It is good for non-technical users or projects that do not need the high definiton of IDEF0.
And sure, for communicating various details, at the relevant stage of the project, wireframes, screenshots, State and Sequence Diagrams.
And sure, for Modelling object classes, if that is a substantial task that requires a special modelling technique, use UML or anything else.
In large projects, boundaries, a clear separation of skills and responsibilities, is important. We need teams of Master builders. Jacks will not survive. Banks do not spend money to prototype software incrementally, they work to fixed budgets, and suppliers like my firm work to fixed price/fixed delivery contracts. That means definition (not specification these days) before coding.
In all my large projects, the OO team used UML within their team only, stuffed around for ages, and never published it outside the team. As architect, I ended up drawing their class diagrams from their UML and code, just to get the documentation out the door and signed off (very fast on my cheap drawing tool, no need for "UML Modeling software"). No "Use Cases" etc were necessary, because that content was already delivered (before writing code) in much more understandable form, in SSADM/IDEF0 and page layouts. State Transition and Sequence diagrams, network diagrams, overall architecture diagrams, all used applicable Standards and were more complete than the UML diagrams they replaced.
Come to think of it, all my projects recently are second generation, full re-implementations of "pure OO" projects, which promised magick, because they were failures, the "databases" were crippled, and the Auditors had rejected them. The re-writes simply used the appropriate science, and complied with Standard, for each Subject Area. there is no magic involved in science. The result is 100% success in each area, with 20% OO, instead of 20% success in each area using 100% OO. Usually using the exact same OO indiividuals.
UML is language independent so you can model any language that supports objects and classes. For example it would be hard to model application written in assembler as this language doesn't operate on objects.
Don't stick tight to UML standard notation. UML was created for you, not you were created to obey UML reference guide. Its purpose is to help you show your concepts of a system, so if you (and your team) accept different notation it's OK.
Another thing is that UML is not REQUIRED for every application (even big) that is created. So many open source projects don't have it, because it is impossible to maintain actual UML diagrams for a software that is being developed by a huge community.
From Agile point of view you should not create enormous UML documentation because soon it becomes burden, not aid. Use it wisely, preferreably on a black board only to show your team what you mean. Your aim is to create application, so don't waste time on synchronising diagrams with continously changing code.
UML/OMT and other modeling languages designed to help you to do 2 things - model your design before you implement it and second to communicate your design to other developers. For first you can really use whatever notation you like but UML gives you a standard that is almost universally understood by most developers. Same as with code - bad, unnecessarily complicated code requires lots of commenting, UML diagram for badly structured design looks bad exposing the ugliness.
Despite that some people say, stick to standard as much as possible down to small details. Incorrectly specified cardinality on static class diagram may not appear a big deal for example but it is big deal because if you make error like this in your code it simply won't work. UML diagrams often created after the fact for wrong reasons - to impress your manager for example. In that case it is usually a useless exercise.
I use UML very often. I don't use any UML editing tools. In the beginning of the project, before any new code is created I take a large sheet of paper that is used of engineering drawing and start adding classes or modules, data structures starting from the center. It is important to keep whole diagram at same level of detail. I use pencil and eraser to draw entire diagram. As much as possible avoid coding design you have modeled yourself - delegate it to other developers and swap roles if necessary. If implementer shows misunderstanding and resistance because design is hard to understand or to implement - it is a good sign that you have to change your design - but do all changes on paper first, talk to other developers on team and ask them what they would change to implement that code. Supplement static diagram with sequence diagrams - good practice is to keep one interaction sequence per sheet of paper. Add data flow diagrams, state transition charts etc. This paper and pencil method has some strange effect of greatly influencing your design in very positive way. I think it is because it tend to bring up all imperfections and places them in plain view. At some point you'll have to redraw the central diagram, so it is good idea to copy stable sections of it to UML editing tool so that they can be printed instead of re-drawing them by hand. Make that sheet of paper center of your "war room" and you'll notice that everyone is coming to that table if they want to add or change something - there you go, you started REALLY using UML and getting benefits from it.
发布评论
评论（4）
UML 首先是一个沟通工具，它可以帮助您与团队中的其他人（或未来三个月的自己）交流想法，因此，应该根据它的容易程度进行评估可以表达你的想法。
由于独立于语言，UML 不能用于表达使用给定 API 或模块的预期、惯用方式，但这是设计的重要部分：忽略它通常会导致代码能够准确地模拟底层问题，但需要数十行样板代码可供交互。
此外，UML 无法轻松捕获算法所依赖的数据结构的某些特定属性。例如，与相应的 UML 类图相比，红黑树更容易用带有“这是一棵红黑树”或“这不是红黑树，因为”描述的小型树状草图来表示。
最后，语言可能具有在 UML 中根本无法优雅表示的功能 - 例如，Objective Caml 模块函子，或任何具有这些功能的语言中的闭包。
UML is first and foremost a communication tool, it helps you communicate ideas to other people on your team (or to yourself three months in the future), and as such, should be evaluated based on how easy it can express whatever you have in mind.
Being language-independent, UML cannot be used to express the expected, idiomatic way to use a given API or module, yet this is an essential part of the design: ignoring it can often end up with code that accurately models the underlying problem but requires dozens of lines of boilerplate code to interact with.
Also, UML cannot easily capture some specific properties of data structures that are relied on by algorithms. A red-black tree, for instance, is more easily represented by small tree-like sketches with "this is a red-black tree" or "this isn't a red black tree because" descriptions, than the corresponding UML class diagram.
Finally, languages may have features that are not represented elegantly in UML at all - for instance, Objective Caml module functors, or closures in any language that has them.
背景
好问题，但却是一个大问题。首先是一些背景信息，具体的主要失败，然后是具体的答案。
如果您想跳过上下文，请向下滚动至UML * 严重失败
UML 只是该领域的新成员。是的，当然，不像敏捷那么新；但与之前可用的内容相比是新的。
首先了解一些内容可能会有所帮助。 40 年来，我们一直在使用模型、建模技术和符号。他们很多。最常见的并不是最合适或最成功的（在技术和目的意义上）；它恰好是广告最多和“销售”最多的。
重新建模的第二个标准是它是团队（不同技能组）之间以及团队和用户之间的沟通工具。当一个团队使用一组符号而另一个团队使用另一组符号时，或者当符号对用户没有意义时，用户必须批准功能定义并为项目提供资金，这就变得很愚蠢。 重新建模的第二个标准
我们使用建造桥梁的标准，以免桥梁倒塌（至少在发达国家）；确保买方和供应商在绘制标准螺栓符号时意思相同；我们以同样的方式使用 IT 标准。
.
关于标准的一句话。 IT行业在过去20年里严重恶化。我们有很多不合格、未经培训的人在做技术工作。因此，松散和天真在小公司中很常见。甚至“标准”这个词也被劫持了。人们笼统地谈论“行业标准”：实际上没有这样的东西，它们只是指行业中最常见的东西。这是一个约定，而不是标准。
标准由国际标准机构制定。不是由单一供应商提供的。由于微软从未遵守标准，他们创造了单一供应商反标准，并试图以这种方式垄断该行业（非法，这就是为什么美国司法部能够很容易地将他们拆散。）
.
一切都有一个标准或“标准”？啊，是的，MS 的计算机方法，购买我们的装备，您会很高兴；如果没有，您只需购买更多我们的装备即可。这是愚蠢到了极点。 IT 中的每个学科领域都已经存在了很长一段时间，都是一个专门的领域，需要专门的资格和技能。一个好的数据建模者可能会成为一个糟糕的程序员，反之亦然。您不需要一位擅长剖腹产并进行脑部手术的妇科医生。
这使得每个标准能够在自己的道路上发展和进步，同时保持对其他标准的引用
标准是公共领域，它们是免费的（您可能需要支付副本的印刷费）
。
另一个原因，所有学科领域的一个“标准”永远不会起作用，造成这种严重不足的原因当然是马斯洛之锤，（如果您费心点击链接，请确保您读最后一句）。 对于工具包中只有锤子的人来说，每个问题看起来都像钉子。UML 的作者以及今天的 Fowlers 和 Amblers 都使用锤子来完成所有任务。 “数据库”是一个钉子；建筑是一颗钉子。
标准也不是由供应商团体或财团制定的，因为他们没有监管控制权或权力在提交的内容上盖上印记。大多数此类联盟都会向自己提交意见，没有透明度、同行评审或监督。
。
据我所知，除了 ObjectClass 建模部分之外，UML 不是标准，其他部分没有 ISO/IEC/ANSI/NIST 指定。原因有两个。
回复 (6)。几种不同的建模标准，每种都针对其主题领域高度专业化，早在 UML 诞生之前就已经存在了。作者没有像任何合格的技术人员那样扩展现有的标准建模技术，而是创建了一个全新的模型。 UML 在每个主题领域都无法提供标准的实用性；不符合标准要求；无法识别或传达完整含义。
示例。鉴于建模数据和建模软件是完全不同的科学，具有不同的规则，并且数据库被设计为独立于任何使用它的软件，因此使用 OO 概念或 UML 来建模“数据库”是愚蠢的。这是 OMG 希望您做的事情，并且说明 UML 可以做。只需检查 SO 上相同问题的数量，其中 OO 类型就会遇到这个确切的问题。
首先，它不会是任何方式、形状或形式的数据库；它只是一个数据存储位置。您将无法获得关系数据库的功能、速度或完整性。
第二，顺序是倒着的。数据不变；程序（经常）这样做，因此如果在对数据建模之后对对象进行建模，则不会发生任何变化。但是，如果您根据对象对数据进行建模，那么您将花费一生的时间来逐步改变这两者，前后移动。
第三，UML 可能适合定义“持久”数据的数据位置，但完全不足以定义关系数据库的元素。由于关系数据库建模标准已经存在 30 年了，它提供了完整的定义，因此使用它会更好。
回复 (7)。它试图做所有事情。首先，由于其在主题领域的不足，它没有合理的机会取代既定标准。其次，它遇到了“万事通，一无是处”的问题。
当然，OMG 有 14 种不同的 UML 模型，可以用 2 到 4 个标准模型来覆盖。为了不同的目的而使用许多不同的模型会带来一系列额外问题。
需要明确的是，UML 不能替代任何内容。 OO 相对较新。它仅为项目的 OO 部分提供 OO 建模。
最后，UML 专门用于 OO。除了OO之外什么也没有。就好像整个宇宙都是面向对象的，其他什么都不存在。即使是顽固的 COBOL 程序员也不会如此狭隘。对于那些对系统和 IT 一无所知的 OO 类型来说，这是一种非常常见且可悲的态度，这种态度是由像 Martin Fowler 这样的白痴产生的，他们以这种方式撰写 OO。这就是 OO 仅限于小型项目的原因，也是 OO 类型在 OO 之外的任何事情上都惨败的原因，因为他们不愿意深入了解任何其他主题领域。以及为什么在过去 15 年里大约有 30 个 OO“数据库”产品，以及为什么它们都失败了。
示例。 Fowler 将首先教您如何创建和实现不完整的类并将它们“持久化”到“数据库”。当这不起作用时，您必须购买下一本书来找出如何通过添加更多定义来纠正它们（呃，这并不奇怪）。当你意识到你纠正了很多，并且纠正实际上很相似时，你必须购买下一本书来弄清楚如何“重构”类，自动化纠正，确保它们全部被应用同时前往相关地点。每次，您都必须“重构”“数据库”。适合没有其他知识的面向对象类型。
对于不“购买”鸟件的 IT 专业人员，他们在 OO 之外有一定的知识和深度，可以生成定义，这样我们就不会浪费时间或金钱重新定义、重构和重构。实施。我们定义和构建一次，然后根据需要进行改进。
我们保持软件规范化，因此永远不需要“重构”，我们只是不断扩展类和方法。这只有在初始结构具有结构时才有可能。
由于我们对关系数据库进行了标准化和建模，尽管应用程序可以不断变化和增长，我们永远不需要“重构”数据库。重新实现代码的成本已经够高的了；重新实施大型数据库的成本令人望而却步。专业人士应该避免这种情况。
它如此受欢迎的原因是，如今，人们已经接受了 MS 生活方式的培训（任何人都可以成为程序员，不需要资格，只要你相信），并且在 OO/UML 中，他们看到了神奇的子弹（现在有了这个闪亮的新锤子，您也可以构建任何东西）。蛇油推销员。不要向元帅开枪，但事实是，没有灵丹妙药，你需要的不仅仅是一把锤子来建造任何东西，而且你需要投入坚硬的院子。
UML • 严重失败
UML 作为“标准”的主要失败如下。这意味着图表和“方法”的具体离散问题，而不是您使用它（稍后）时将遇到的问题。
一个符号
一个矩形可以容纳任何东西。
包含与 14 种不同类型的图表相关的部分。而标准对数据、流程、GUI 等有不同的符号。由于定义事物（14 种事物）需要没有固定的项目集，因此每个人都实现什么他们认为事情就是这样，或者更糟糕的是，他们认为事情就是这样，而他们所知道的却很少。
人们不知道自己正在看什么生物，也不知道其完整性程度如何。
次要符号太少
由于它试图为每个人做所有事情，并尝试为小型和大型项目“建模”，因此有很多很多次要符号。
其实太多了（如果你明白我上面说的的话），14种绘图中的每一种都应该有一些小符号，而且它们应该是必需的，否则它就不是标准，它是松散且软弱的。
尽管如此，次要符号还是太少了。在正常使用中，每个人都会发明一些自己的小符号，以填补 UML 符号中的空白。结果当然是可怕的：每个项目团队都有各种附加次要符号，这些符号不在 UML 中，因此在项目之外无法理解。与标准的目的恰恰相反。
总体结果（不限于一个项目团队）是太多次要符号，数百个，其中一些表示相同的意思，而另一些则表示轻微的意思（重要的是） ）不同的东西。
.
我数到200就停止了。
与真正的标准相比，上述两点导致对象（事物）的文档中严重缺乏定义，而这正是标准所期望（要求）的东西。它完全不符合标准的第一个标准：*首先也是最重要的，它是一种沟通工具。收到 UML“模型”后，为了理解它，必须将其放在一边并手动与作者沟通。
最后，但也是最重要的......
没有组合/分解的设施
分析先于设计，我们需要分析（作为一门科学）应用程序应该做什么，然后才能设计（作为一门科学）程序来实现它。 （不幸的是，现在，未经培训的人投入设计阶段，不知道他们不知道应用程序是什么，因为他们没有分析它。保证灾难。）
分析阶段和设计阶段都要求能够查看应用程序包含的功能：
不同级别：
一个。从 10,000 米处：看到整个范围，几乎没有细节......但所有接口，[缩小]或
b. 1,000 米，或
c. 1 米：查看小范围的所有细节 [放大]
.
这意味着，能够将应用程序分解为其功能，首先是大型组件，然后再次分解为较小的组件，直到定义最小或原子组件（单个对象或 Function() 或存储过程或子例程）。
在获得信心继续下一阶段之前，提供分析，这是一个完整的建模阶段......
提供设计，现在可以将对象和物品排列和组织、规范化为一组合法的功能。规范化代码意味着没有功能重复。
IDEF0和SSADM具有完整的组成 - 分解。一个大型应用程序正在使用树结构（应用程序为）进行建模，在许多页面上，每个页面仅显示级别的相关内容。 （除此之外，不能跳过的，如果它是OO客户端，我们可能只为这些对象有一个UML图。
使用UML的结果是，您没有得到任何一个
除了没有设计外，该应用最终还是一个巨大的大型整体，并具有大量的代码重复。 a 笑话给真正的工程师。
首先回答
首先，请确保您为工具包购买了一些工具，并始终使用正确的工具来工作。
首先
oo是一个很好的主意，UML可能是建模对象类的绝佳技术，但是它完全不足以建模其他任何东西或与用户进行通信。唯一会印象深刻的用户是那些认为自己是“技术” 和的人，他们没有看到任何建模标准（即他们没有参考，并且很容易印象深刻）。
充其量是使用准确的单词，UML是建模对象类的标准仅，仅与OO类型相关（即，在任何其他主题领域都没有专门技能）。与IN一样，我发现它不能传达现代对象类和复杂方法的所有控制和微妙，因此我必须在UML图中添加符号才能使其完成。
它足以适用于小型项目，这些项目应一开始由OO类型建模和实施。
我看不到“统一”的太多，而是一个反标准。它一无所有，除了（也许）14个UML模型中的另一种。
我们没有将男子放在月球上，也没有使用UML建造正常航天飞机或战斗机的航天飞机。我们使用以下标准做到了这一点。在发达国家，银行和金融机构（我的机构）和政府部门需要标准（要求？）。根据（6），它们都彼此集成：
可以确保在项目的相关阶段传达各种细节，线框，屏幕截图，状态和序列图。
可以肯定的是，对于对象类建模，如果这是一项需要特殊建模技术的实质性任务，请使用UML或其他任何东西。
在大型项目中，边界，明确的技能和职责分离很重要。我们需要大型建筑商团队。千斤顶将无法生存。银行不会逐步花钱到原型软件，它们用于固定的预算，以及像我的公司工作一样固定价格/固定交付合同的供应商。这意味着在编码之前定义（这些天不规格）。
在我所有的大型项目中，OO团队仅在他们的团队中使用UML，塞满了很长时间，并且从未在团队外发表过它。作为架构师，我最终从他们的UML 和代码中绘制了他们的班级图，只是为了将文档放到门上并签字（在我的廉价绘图工具上很快，不需要“ UML建模软件”）。不需要“用例”等，因为在SSADM/IDEF0和页面布局中，该内容已经以更易于理解的形式传递（在编写代码之前）。状态过渡和序列图，网络图，整体体系结构图，所有使用的标准都比它们更换的UML图更完整。
想到这一点，我最近的所有项目都是第二代，对“纯OO”项目的完整重新实施，该项目承诺魔术，因为它们是故障，“数据库”被削弱了，审计师拒绝了他们。重新写的只是为每个主题领域使用适当的科学并符合标准。科学没有魔术。结果是每个区域的100％成功，有20％的OO，而不是使用100％OO在每个区域的成功中取得了20％的成功。 使用完全相同的OO。
Context
Good question, but a big question. First some context, the specific major failures, and then the specific answers.
Scroll down to UML * Gross Failures if you would like to skip the Context
UML is just the new kid on the block. Yeah sure, not so new as Agile; but new in comparison to what was available before.
It might help to understand something first. We have been using models, modelling techniques, and symbols for 40 years. They are many of them. The most common is not the most appropriate or successful (in the technical and purpose sense); it just happens to be the most advertised and "sold".
The second criterion re models is that it is a tool for communication, both between teams (different skill sets), and between teams and users. It gets silly when one team uses one set of symbols and another uses another set, or when the symbols are not meaningful to the user, who has to approve functional definitions, and funds the project.
We use standards for building bridges, so that they do not fall over (at least in developed countries); to ensure that the purchaser and the supplier mean the same thing when they draw a symbol for a standard bolt; and we use standards in IT to in the same way.
.
A word about Standards. The IT industry as deteriorated badly in the last 20 years. We have many unqualified and untrained people doing technical work. So there is a looseness and naïveté that is common in the smaller companies. Even the word standard has been hijacked. People talk loosely about "industry standards": actually there is no such thing, they simply mean whatever is most common in the industry. That is a convention, not a Standard.
Standards are set by international standards bodies. Not by a single vendor. Since MS have never complied with Standards, they have created their single-vendor anti-standard, and sought to monopolise the industry in that manner (illegal, which is why the US Justice Dept were able to take them apart quite easily.)
.
One Standard or "standard" for everything ? Ah yes, the MS approach to computers, buy our gear, and you will be happy; if not, you just need to buy more of our gear. It is stupid in the extreme. Each Subject Area in IT has been around for quite a while, a specialised area, requiring specialised qualifications and skills. A good Data Modeller may make a horrible programmer, and vice versa. You do not want a gynaecologist who is good with c-sections performing brain surgery.
This allows each Standard to develop and progress on its own path, whilst maintaining its reference to other Standards
Standards are public domain, they are free (you might have to pay a printing price for a copy)
.
The other reason One "standard" for all Subject Areas will never work, the reason for this gross inadequacy, is of course Maslow's Hammer, (if you bother to click the link, make sure you read the last sentence). To the man who only has a hammer in the toolkit, every problem looks like a nail. The authors of UML, as well as the Fowlers and Amblers of today, use a hammer for all tasks. A "database" is a nail; architecture is a nail.
Standards are also not set by groups of vendors or consortia, as they do not have the regulatory control or authority to put their stamp on submissions. Most of such consortia make their own submissions to themselves, there is no transparency or peer review or oversight.
.
AFAIK, other than the ObjectClass Modelling portion, UML is not a Standard, there is no ISO/IEC/ANSI/NIST designation for the other portions. There are two reasons for that.
Re (6). Several different Modelling Standards, each highly specialised for its Subject Area, existed long before UML was hatched. Instead of extending the existing Standard Modelling techniques, as any qualified technical person would do, the authors created a completely new model. UML, in each of those Subject Areas does not come close to providing the utility of the Standard; does not comply with the Standard requirement; does not identify or convey the full meaning.
Example. Given that modelling data and modelling software are quite different sciences, with different rules, and that Databases are designed to be independent of any software that uses it, it is stupid to model a "database" using OO concepts or UML. Which is what OMG would have you do, and states UML can do. Just check the number of identical questions on SO, where OO types are stuck with this exact problem.
First, it will not be a Database in any way, shape or form; it will be only a data storage location. You will have none of the power or speed or integrity of a Relational Database.
Second, the sequence is backwards. Data does not change; programs do (frequently), so if you model the objects after modelling the data, nothing changes. But if you model the data after the objects, you spend your life incrementally changing both, going backwards and forwards.
Third, UML may be good for defining a data location to "persist" data to, but it is completely inadequate for defining the elements of a Relational Database. Since there has been a Standard for Modelling Relational Databases for 30 years, that provides complete difinition, you will be better off using that.
Re (7). It tries to do everything. First, due to its inadequacy in the Subject Areas, it does not stand a reasonable chance of displacing the established Standards. Second, it suffers the Jack of all trades, master of none problem.
Of course, OMG has 14 different UML models, which can be covered with 2 to 4 Standard models. Using that many different models, for different purposes, has an additional set of problems.
to be clear, UML replaces nothing. OO is relatively new. It only supplies OO Modelling for the OO portions of a project.
Last, UML is specialised for OO. And nothing but OO. As if the entire Universe was OO and nothing else existed. Even die-hard COBOL programmers aren't this blinkered. This is a very common and sad attitude among OO types who know nothing else about systems and IT, and it is generated by the idiots like Martin Fowler, who write about OO that way. This is the reason OO is limited to small projects, and why OO types fail miserably at anything outside OO, because they are unwilling to learn about any other Subject Area in depth. And why there has been perhaps 30 OO "database" products, over the last 15 years, and why all of them have failed.
Example. Fowler will first teach you how to create and implement incomplete classes and "persist" them to a "database". When that does not work, you have to buy the next book to figure out how to correct them, by adding more definition (er, no surprise). When you realise that you are correcting them an awful lot, and the corrections are in fact similar, you have to buy the next book to figure out how to "re-factor" the classes, automate the corrections, make sure they are all applied to the relevant locations at the same time. And each time, you will have to "re-factor" the "database" as well. Good for the OO types who have no other knowledge.
For IT professionals who do not "buy" fowling pieces, who have some knowlede and depth outside OO, can produce definitions, so that we do not waste time or money re-defining and re-factoring and re-implementing. We define and build once, then improve as necessary.
And we keep our software Normalised, so there is never a need to "re-factor", we just keep extending the classes and methods. Which is only possible if the initial structure had structure.
Since we Normalise and Model our Relational Databases, although the apps can keep changing and growing, we never need to "re-factor" the Database. Re-implementing code is expensive enough; the cost of re-implementing large Databases is prohibitive. Professionals are expected to avoid that.
The reason it is so popular, is that these days, people have been trained in the MS approach to life (anyone can be a programmer, no qualification required, if only you believe), and in OO/UML, they see the magic bullet (now with this shiny new hammer, you too, can build anything). Snake oil salesmen. Don't shoot the marshall, but the truth is, there is no magic bullet, you need more than a hammer to build anything, and you need to put in the hard yards.
UML • Gross Failure
The main failures of UML as a "standard", are these. This means the specific discrete issues with the diagrams and the "method", not the resulting problems that you will have if you use it (later).
One Symbol
One rectangle for absolutely anything and everything.
With sections that are relevant to the 14 different types of diagrams. Whereas Standards have a different symbol for Data, vs Process, vs GUI, etc. Since there is no fixed set of items that are required to define a thing (14 types of things), each person implements what they think the thing is, or worse, what they know the thing to be, which is very little.
One does not know what creature one is looking at, or what the level of completeness is.
Too Few Minor Symbols
Since it tries to do everything for everyone, and tries to "model" both small and large projects, there are many, many minor symbols.
Actually, too many (if you understand what I have stated above), there should be a few minor symbols for each of the 14 types of drawing, and they should be required, otherwise it is not a Standard, it is loose and floppy.
Nevertheless, the minor symbols are too few. In normal use, each person invents a few minor symbols of their own, to fill in the gaps in UML symbols. The result is of course, horrendous: each project team has various additional minor symbols that are not in UML, and thus not understood outside the project. The very opposite of the purpose of a Standard.
The result overall (not limited to one project team), is too many minor symbols, hundreds of them, some of which mean the same thing, and others which mean slightly (importantly) different things.
.
I stopped counting at 200.
Compared with genuine Standards, the above two points result in a gross lack of Definition in the documentation of objects (things), the very thing that is expected (demanded) from a Standard. It is a total failure at the first criterion of a Standard: *first and foremost, it is a communication tool. On receipt of a UML "model", in order to understand it, one has to set it aside and manually communicate with the author.
Last, but the most important ...
No Facility for Composition/Decomposition
Analysis comes before Design, we need to analyse (as a science) what an application is supposed to do, before we can design (as a science) the program to implement it. (Unfortunately, these days, untrained people throw themselves at the Design phase, clueless that they do not know what the app is, because they have not analysed it. Guaranteed disaster.)
Both the Analysis phase and the Design phase demand the ability to look at the Function that the application comprises:
at different levels:
a. from 10,000 metres: see the whole scope with little detail ... but all interfaces, [zoom out] or
b. 1,000 metres, or
c. 1 metre: see all detail for a small scope [zoom in]
.
That means, the ability to break the app into its Functions, first large components, and then again, into smaller components, until the smallest or Atomic components are defined (single Object or Function() or Stored Proc or Subroutine).
That affords Analysis, a complete phase of modelling, before achieving confidence to proceed with the next phase ...
That affords Design, now the objects and articles can be arranged and organised, Normalised, into a legitimate set of Functions. Normalised code means no function duplication.
IDEF0 and SSADM have full Composition - Decomposition. A large app is modelling using a tree structure (which the app is), on many pages, each page showing only what is relevant at that Level. (In addition to that, which cannot be skipped, if it is an OO client, we may have an UML diagram for those Objects only.
The result of using UML is, you get none of that.
No analysis is possible. Great, for those who do not know that Analysis is a science, that it is the first phase in any serious project.
No genuine design is possible. Great, for those who do not know that Design is a science, steps are relevant to the platform, etc. That it is the second phase in any serious project. People go straight into "designing" their OO objects, as if that is the centre of the universe. They even try to control their data integrity via these hilarious creatures.
In addition to not being designed, the app ends up being one great big monolith, with massive code duplication. A joke to genuine engineers.
Answer
First and foremost, make sure you acquire a few tools for your toolkit, and always use the right tool for the job.
OO is a fine idea, UML may be a great technique for modelling object classes, but it is completely inadequate for modelling anything else, or for communicating with users. The only users who will be impressed are those who fancy themselves as "technical" and who have not seen any Modelling Standard (ie. they have no point of reference, and are easily impressed).
At best, using accurate words, UML is a Standard for modelling Object Classes only and relevant to OO types only (ie. no specialised skills in any other subject Area). As in, I find it does not convey all the control and subtlety of modern object classes and complex Methods, and thus I have to add notations to the UML diagram to make it complete.
it is adequate for for small projects, which are to be modelled and implemented by OO types onlly.
I do not see much that is "unified", it is more of an anti-standard. It integrates with nothing, except (maybe) another of the 14 UML models.
We did not put men on the Moon, or build space shuttles for regular space flight or fighter aircraft, using UML. We did that using the following Standards. Standards are required (demanded ?) by banks and financial institutions (my ambit) and govt depts in developed countries. As per (6), they are all integrated with each other:
And sure, for communicating various details, at the relevant stage of the project, wireframes, screenshots, State and Sequence Diagrams.
And sure, for Modelling object classes, if that is a substantial task that requires a special modelling technique, use UML or anything else.
In large projects, boundaries, a clear separation of skills and responsibilities, is important. We need teams of Master builders. Jacks will not survive. Banks do not spend money to prototype software incrementally, they work to fixed budgets, and suppliers like my firm work to fixed price/fixed delivery contracts. That means definition (not specification these days) before coding.
In all my large projects, the OO team used UML within their team only, stuffed around for ages, and never published it outside the team. As architect, I ended up drawing their class diagrams from their UML and code, just to get the documentation out the door and signed off (very fast on my cheap drawing tool, no need for "UML Modeling software"). No "Use Cases" etc were necessary, because that content was already delivered (before writing code) in much more understandable form, in SSADM/IDEF0 and page layouts. State Transition and Sequence diagrams, network diagrams, overall architecture diagrams, all used applicable Standards and were more complete than the UML diagrams they replaced.
Come to think of it, all my projects recently are second generation, full re-implementations of "pure OO" projects, which promised magick, because they were failures, the "databases" were crippled, and the Auditors had rejected them. The re-writes simply used the appropriate science, and complied with Standard, for each Subject Area. there is no magic involved in science. The result is 100% success in each area, with 20% OO, instead of 20% success in each area using 100% OO. Usually using the exact same OO indiividuals.
UML 与语言无关，因此您可以对任何支持对象和类的语言进行建模。例如，很难对用汇编语言编写的应用程序进行建模，因为这种语言不对对象进行操作。
不要严格遵守 UML 标准符号。 UML 是为您创建的，而不是您被创建来遵守 UML 参考指南。它的目的是帮助您展示系统的概念，因此如果您（和您的团队）接受不同的表示法也没关系。
另一件事是，并不是每个创建的应用程序（即使是大型应用程序）都需要 UML。很多开源项目都没有它，因为不可能为一个由庞大社区开发的软件维护实际的 UML 图。
从敏捷的角度来看，您不应该创建大量的 UML 文档，因为它很快就会成为负担，而不是帮助。明智地使用它，最好是在黑板上只向你的团队展示你的意思。您的目标是创建应用程序，因此不要浪费时间将图表与不断更改的代码同步。
UML is language independent so you can model any language that supports objects and classes. For example it would be hard to model application written in assembler as this language doesn't operate on objects.
Don't stick tight to UML standard notation. UML was created for you, not you were created to obey UML reference guide. Its purpose is to help you show your concepts of a system, so if you (and your team) accept different notation it's OK.
Another thing is that UML is not REQUIRED for every application (even big) that is created. So many open source projects don't have it, because it is impossible to maintain actual UML diagrams for a software that is being developed by a huge community.
From Agile point of view you should not create enormous UML documentation because soon it becomes burden, not aid. Use it wisely, preferreably on a black board only to show your team what you mean. Your aim is to create application, so don't waste time on synchronising diagrams with continously changing code.
UML/OMT 和其他建模语言旨在帮助您完成两件事：在实现设计之前对其进行建模，以及将您的设计传达给其他开发人员。首先，您确实可以使用您喜欢的任何符号，但 UML 为您提供了一个几乎被大多数开发人员普遍理解的标准。与代码相同 - 糟糕的、不必要的复杂代码需要大量注释，糟糕的结构化设计的 UML 图看起来很糟糕，暴露了丑陋。
尽管有人说，要尽可能坚持标准，直至小细节。例如，在静态类图上错误指定的基数可能看起来没什么大不了的，但它很重要，因为如果您在代码中犯了这样的错误，它根本就不起作用。 UML 图通常出于错误的原因而在事后创建 - 例如，为了给您的经理留下深刻印象。在这种情况下，这通常是无用的练习。
我经常使用 UML。我不使用任何 UML 编辑工具。在项目开始时，在创建任何新代码之前，我会拿一张用于工程绘图的大纸，并从中心开始添加类或模块、数据结构。使整个图表保持相同的细节水平非常重要。我用铅笔和橡皮画出整个图表。尽可能避免您自己建模的编码设计 - 将其委托给其他开发人员并在必要时交换角色。如果实施者因为设计难以理解或实施而表现出误解和阻力 - 这是一个好兆头，表明您必须更改设计 - 但首先在纸上进行所有更改，与团队中的其他开发人员交谈并询问他们会更改什么来实现该代码。
用序列图补充静态图 - 好的做法是在每张纸上保留一个交互序列。添加数据流程图、状态转换图等。
这种纸笔方法有一些奇怪的效果，以非常积极的方式极大地影响您的设计。我认为这是因为它往往会暴露所有的缺陷并将它们置于显而易见的位置。
在某些时候，您必须重新绘制中心图，因此最好将其稳定部分复制到 UML 编辑工具，以便可以打印它们，而不是手动重新绘制它们。将这张纸放在“作战室”的中心，您会注意到，如果每个人想要添加或更改某些内容，都会来到这张桌子前 - 就这样，您开始真正使用 UML 并从中受益。
UML/OMT and other modeling languages designed to help you to do 2 things - model your design before you implement it and second to communicate your design to other developers. For first you can really use whatever notation you like but UML gives you a standard that is almost universally understood by most developers. Same as with code - bad, unnecessarily complicated code requires lots of commenting, UML diagram for badly structured design looks bad exposing the ugliness.
Despite that some people say, stick to standard as much as possible down to small details. Incorrectly specified cardinality on static class diagram may not appear a big deal for example but it is big deal because if you make error like this in your code it simply won't work. UML diagrams often created after the fact for wrong reasons - to impress your manager for example. In that case it is usually a useless exercise.
I use UML very often. I don't use any UML editing tools. In the beginning of the project, before any new code is created I take a large sheet of paper that is used of engineering drawing and start adding classes or modules, data structures starting from the center. It is important to keep whole diagram at same level of detail. I use pencil and eraser to draw entire diagram. As much as possible avoid coding design you have modeled yourself - delegate it to other developers and swap roles if necessary. If implementer shows misunderstanding and resistance because design is hard to understand or to implement - it is a good sign that you have to change your design - but do all changes on paper first, talk to other developers on team and ask them what they would change to implement that code.
Supplement static diagram with sequence diagrams - good practice is to keep one interaction sequence per sheet of paper. Add data flow diagrams, state transition charts etc.
This paper and pencil method has some strange effect of greatly influencing your design in very positive way. I think it is because it tend to bring up all imperfections and places them in plain view.
At some point you'll have to redraw the central diagram, so it is good idea to copy stable sections of it to UML editing tool so that they can be printed instead of re-drawing them by hand. Make that sheet of paper center of your "war room" and you'll notice that everyone is coming to that table if they want to add or change something - there you go, you started REALLY using UML and getting benefits from it.