我们知道UML是统一的建模语言.那么它可以模拟任何类型的软件(如Linux内核,开放式办公室,任何Web应用程序等)吗？或者只能建模使用面向对象语言(Java,c ++等)的软件？
我认为建模是找出软件的好方法.如果我们不使用UML进行建模,我们可以使用哪些其他建模方法？
你知道什么样的建模方法用于大型开源项目(Linux内核,Openoffice.org,Firefox,Apache http,MySQL,Eclipse,VIM等),我们在哪里可以找到它们的建模文档？
谢谢任何答案!
UML首先是一个沟通工具,它可以帮助您将想法传达给团队中的其他人(或将来三个月),并且应该根据您表达的任何内容的容易程度进行评估. .
由于与语言无关,UML不能用于表达使用给定API或模块的预期的,惯用的方式,但这是设计的一个重要部分:忽略它往往最终会得到准确模拟底层问题的代码,但需要数十行样板代码与之交互.
此外,UML无法轻松捕获算法所依赖的数据结构的某些特定属性.例如,红黑树更容易用小树状草图表示,"这是一个红黑树"或"这不是红黑树,因为"描述,而不是相应的UML类图.
最后,语言可能有未在UML优雅派代表参加所有功能 - 在有他们的任何语言,例如,目的CAML模块函子,或倒闭.
好问题，但大问题。首先是一些具体情况，具体是主要的失败，然后是具体的答案。
向下滚动到UML *重大失败，如果您想跳过上下文
UML只是新手。是的，当然还不如敏捷。但与以前相比是新的。
首先了解一些内容可能会有所帮助。我们使用模型，建模技术和符号已有40年了。他们很多。最常见的不是最合适或最成功的（在技术和目的上）；它恰好是广告和“销售最多”的广告。
重新建模的第二个标准是，它是团队之间（不同技能集）以及团队与用户之间进行交流的工具。当一个团队使用一组符号而另一组使用另一组符号时，或者当符号对必须批准功能定义并为项目提供资金的用户无意义时，它变得愚蠢。
我们使用建造桥梁的标准，以使它们不会倒塌（至少在发达国家）；确保购买者和供应商在绘制标准螺栓的符号时的意思相同；而且我们以相同的方式在IT中使用标准。
关于标准的一句话。在过去的20年中，IT行业严重恶化。我们有许多不合格且未经培训的人员从事技术工作。因此，在较小的公司中存在一种松散和天真的现象。甚至“标准”一词也已被劫持。人们松散地谈论“行业标准”：实际上没有这样的东西，它们只是意味着行业中最常见的事物。那是惯例，而不是标准。
标准由国际标准机构制定。没有一个供应商。由于MS从未遵守标准，因此他们创建了单一供应商反标准，并试图以这种方式垄断行业（非法，这就是美国司法部能够很容易地将它们分开的原因。）
一个标准还是所有的“标准”？是的，MS的计算机方法，购买了我们的设备，您会很高兴的。如果没有，您只需要购买更多我们的设备。极端是愚蠢的。IT的每个主题领域都已经存在了很长一段时间，这是一个专门领域，需要专门的资格和技能。一个好的Data Modeller可能会使程序员变得可怕，反之亦然。您不希望妇科医师擅长剖腹产手术。
这允许每个标准在自己的道路上发展和进步，同时保持对其他标准的引用
标准是公共领域，它们是免费的（您可能必须为印刷本支付印刷价）
。
另一个原因所有主题领域的一个“标准”永远都行不通，这种严重不足的原因当然是Maslow的Hammer，（如果您不愿意单击链接，请确保已阅读最后一句话）。对于只在工具箱中装有锤子的人来说，每个问题都像钉子。UML的作者以及当今的Fowlers和Amblers都用锤子完成所有任务。“数据库”是钉子；建筑是钉子。
供应商或财团也没有制定标准，因为它们没有监管控制权或授权来对提交的文件盖章。大多数这样的财团向自己提出意见，没有透明度或同行评审或监督。
除了ObjectClass Modeling部分之外，AFAIK不是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程序员也不会眨眼。这是谁一无所知OO类型中一种很常见的，悲伤的态度其它有关系统和IT，它是由像Martin Fowler的白痴，谁写OO这种方式产生的。这就是OO限于小型项目的原因，以及OO类型在OO之外的任何其他项目上失败的原因，因为它们不愿深入了解任何其他主题领域。以及为什么在过去的15年中可能有30种面向对象的“数据库”产品，以及为什么所有这些产品都失败了。
例。Fowler首先会教您如何创建和实现不完整的类，并将它们“持久化”到“数据库”中。如果这样做不起作用，则您必须购买下一本书，以通过添加更多定义来弄清楚如何纠正它们（嗯，毫不奇怪）。当您意识到要对它们进行大量的改正，而实际上却是相似的改正时，您必须购买下一本书，以弄清楚如何“重构”类，使改正自动化，并确保已全部应用同时到相关位置。而且每次，您也必须“重构”“数据库”。适合没有其他知识的OO类型。
对于不“购买”禽类零件的IT专业人员，他们在OO之外具有一定的知识和深度，可以产生定义，这样我们就不会浪费时间或金钱来重新定义，重构和重新实现。我们定义和构建一次，然后根据需要进行改进。
并且我们将软件保持规范化，因此不需要“重构”，我们只需扩展类和方法即可。仅当初始结构具有结构时，才有可能。
由于我们对关系数据库进行规范化和建模，因此尽管应用程序可以不断变化和增长，但我们永远不需要“重构”数据库。重新实现代码非常昂贵。重新实现大型数据库的成本令人望而却步。专业人士应避免这种情况。
之所以如此受欢迎，是因为这些天来，人们已经接受过MS生活方法方面的培训（任何人都可以是程序员，不需要任何资格，只要您相信即可），并且在OO / UML中，他们看到了神奇的子弹（现在，有了这个闪亮的新锤子，您也可以构建任何东西）。蛇油推销员。不要开枪射击，但事实是，没有魔术子弹，您需要的不仅仅是锤子来建造任何东西，而且还需要放在硬地里。
这些是UML作为“标准”的主要失败之处。这意味着图表和“方法”的特定离散问题，而不是使用后将产生的最终问题。
一个符号
一个矩形代表几乎所有事物。
与14种不同类型的图表相关的部分。虽然标准对数据不同的符号，VS流程，VS GUI等。由于存在那些项目没有固定集需要确定的事情（14种类型的东西），每个人都实现了被他们认为事情是，或更糟糕的是，他们所知道的是什么，这很少。
一个人不知道一个人在看什么生物，或者完整性水平是什么。
很少的次要符号
由于它试图为每个人做所有事情，并试图对大型和小型项目进行“建模”，因此有许多次要符号。
事实上，太多的（如果你明白我上面所述），应该有各自的14种绘制的一些小符号，而且应该要求，否则就不是一个标准，它是松散和软盘。
但是，次要符号太少了。在正常使用中，每个人都会发明自己的一些次要符号，以填补UML符号中的空白。结果当然是可怕的：每个项目团队都有各种其他的次要符号，这些符号不在UML中，因此在项目外无法理解。与标准目的完全相反。
总体而言，结果（不限于一个项目团队）是太多的次要符号，其中有数百个次要符号，其中一些表示相同的事物，而其他的则表示略有（重要）不同的事物。
。
我从200开始停止计数。
与真正的标准相比，以上两点导致对象（事物）的文档中完全缺少“定义”，这正是标准所期望的。在标准的第一条标准下，这是完全失败的：*首先，最重要的是，它是一种交流工具。为了理解UML“模型”，必须将其放在一边并与作者手动通信。
最后，但最重要的是...
在设计之前没有构成/分解分析的功能，我们需要分析（作为一门科学）应用程序应该做什么，然后才能设计（作为一门科学）实施程序。（不幸的是，这些天，未经训练的人们将自己投入到设计阶段，因为他们不知道该应用程序是什么，因为他们没有分析该应用程序，这毫无头绪。保证了灾难。）
分析阶段和设计阶段都需要具备查看应用程序所包含功能的能力：
在不同的层次：
一。从10,000米开始：几乎看不到整个范围……但是所有界面，[缩小]或
b。1,000米或
c。1米：查看所有细节（小范围放大）。
这意味着可以将应用程序分解为功能，首先是大型组件，然后再分解为较小的组件，直到定义了最小的或原子的组件（单个Object或Function（）或Stored Proc或Subroutine）为止。
这为Analysis提供了一个完整的建模阶段，然后使您有信心继续进行下一阶段...
这样就可以提供Design，现在可以将对象和物品进行归一化和组织成一组合法的Function了。规范化的代码意味着没有功能重复。
IDEF0和SSADM具有完整的成分-分解。大型应用程序在许多页面上使用树结构（该应用程序是）进行建模，每个页面仅显示该Level上的相关内容。（除此之外，如果它是一个OO客户端，那么这是不能跳过的，我们可能只有这些对象的UML图。
使用UML的结果是，您一无所获。
无法进行分析。太好了，对于那些不知道分析是一门科学的人来说，它是任何严肃项目的第一阶段。
没有真正的设计是可能的。太好了，对于那些不知道设计是一门科学的人来说，步骤与平台有关，等等。这是任何重要项目的第二阶段。人们直接进入“设计”其OO对象的过程，就好像那是宇宙的中心一样。他们甚至试图通过这些热闹的生物来控制其数据完整性。
除了不被设计之外，该应用最终还是一个巨大的整体，具有大量的代码重复。一个笑话，以真正的工程师。
首先，请确保为您的工具包购买了一些工具，并始终使用正确的工具来完成工作。
OO是个好主意，UML可能是建模对象类的好技术，但它完全不足以建模其他任何事物或与用户进行通信。唯一会给人留下深刻印象的用户是那些自称为“技术” 并且没有见过任何建模标准的用户（即，他们没有参考点，并且容易受到影响）。
充其量，使用准确的单词，UML是仅用于建模对象类且仅与OO类型相关的标准（即，在任何其他主题领域中都没有专门技能）。就像在其中一样，我发现它不能传达现代对象类和复杂方法的所有控制和微妙之处，因此我必须在UML图中添加符号以使其完整。
对于仅由OO类型建模和实施的小型项目而言，它就足够了。
我看不出什么是“统一的”，更多的是反标准的。除了14个UML模型中的另一个模型之外，它什么都没有集成。
我们没有使用UML将人员放在月球上，也没有为常规的太空飞行或战斗机建造航天飞机。我们使用以下标准做到了这一点。发达国家的银行和金融机构（我的职责范围）和政府部门要求（要求）标准。按照（6），它们都相互集成在一起：
并且，为了传达各种细节，请确保在项目的相关阶段显示线框，屏幕截图，状态图和序列图。
当然，对于建模对象类，如果这是一项需要特殊建模技术的重大任务，请使用UML或其他任何方法。
在大型项目中，界限，技能和职责的明确分离很重要。我们需要大师级建筑团队。千斤顶将无法生存。银行不会花钱逐步开发软件原型，而是按固定预算工作，而像我公司这样的供应商则按固定价格/固定交付合同工作。这就意味着在编码之前要进行定义（这些天不是规范）。
在我所有的大型项目中，OO团队仅在其团队内部使用UML，并且使用了很长时间，并且从未在团队外部发布过。作为架构师，我最终从他们的UML 和代码中绘制了他们的类图，只是为了获取文档并签字（非常便宜的绘图工具上非常快速，不需要“ UML建模软件”）。不需要“用例”等，因为该内容已经（在编写代码之前）以更容易理解的形式（在SSADM / IDEF0和页面布局中）交付。状态转换和顺序图，网络图，总体体系结构图，全部使用了适用的标准，并且比它们替代的UML图更完整。
仔细想想，我最近所有的项目都是第二代，完全重新实现了“纯OO”项目，这些项目向Magick承诺了，因为它们都是失败的，“数据库”已经瘫痪，审计员拒绝了它们。重写仅针对每个主题领域使用了适当的科学，并符合标准。科学中没有魔力。结果是每个区域100％的成功率是100％，而不是每个区域100％的成功率是20％。通常使用完全相同的OO个人。