PDFUML 热病致死
ALEX E. BELL，波音公司
自我诊断和早期治疗对于对抗 UML 热病至关重要。
一种潜在的致命疾病，临床上称为 UML（统一建模语言）热病，如今正困扰着许多软件工程项目。这种热病有许多不同的变种，其致命性和传染性各不相同。然而，许多这些变种在症状上是相关的。严格的实验室分析表明，每种变种的起源和组成都是独特的。UML 热病一个特别阴险的特征，也是其大多数不同变种的共同特征，是个人和组织在自我诊断这种疾病方面遇到的困难。结果是，许多热病病例未经治疗，并且经常演变成更复杂和致命的变种。
关于 UML 热病的医学年鉴出版甚少，因为它只是最近才作为一种疾病出现。 《新英格兰医学杂志》对这种疾病保持沉默，世界上最负盛名的医疗机构的研究也是如此。本文的内容代表了多年的在职研究，并描述了所有已知的 UML 热病变种，以及已知的存在于它们之间的许多关系。本文最后将披露针对多种多样的 UML 热病的唯一已知解药。
在开始描述 UML 热病及其相关症状之前，重要的是要强调 UML 本身不是本文所述任何疾病的直接原因。相反，UML 在很大程度上是无辜的受害者，它被夹在糟糕的过程、没有过程或其用户的纯粹无能之间。然而，并非由于自身的过错，UML 有时确实会放大某些热病的症状，这是因为人们常常赋予它神圣的光环。例如，人们普遍认为，无论他们从事什么任务，仅仅使用 UML 就能在某种程度上使他们的努力合法化，或保证所产生工件的价值。
本文利用了一个事实，即程序中许多与软件相关的疾病的存在和相关严重程度，通常可以用 UML 来观察和衡量：例如，过多、过于详细和过于功能化。一些读者可能会很快提出，无论程序选择何种建模方法，都可以进行同样的利用。这里可能有一些道理，但没有其他技术像 UML 那样迅速而深入地渗透到软件工程生命周期中。
元热病
广泛的研究表明，UML 热病可以分为四个明确定义的组，称为元热病。它们的常用实验室名称是妄想型、情感型、波丽安娜型（指被认为是愚蠢或盲目乐观的人）和程序型（见图 1）。以下章节将描述这些元热病中的每一种，以及与之相关的变种。尽管关于每种变种的了解都比本文所写的要多得多，但本文的目的是描述它们，以便对其进行表征并与其他变种区分开来。
妄想型元热病。 妄想型元热病包括许多人认为是最致命的 UML 热病变种。这种元热病最出名的是它对原本健康的管理者和工程师的思维和判断过程产生的破坏性影响。妄想型类别的热病非常常见，它会损害人体免疫系统，以至于身体容易感染许多其他 UML 热病变种（见图 2）。
乌托邦热病。 患有乌托邦热病的受试者通常认为 UML 是一种具有近乎神圣起源的激进新技术。 “没有 UML，我们是如何走到今天的？”以及“如果我们 20 年前就拥有 UML，我们的技术革命将会多么先进？”等喃喃自语在患者中很常见。这种热病的其他症状包括类似失忆症的症状，导致人们忘记多年来在没有 UML 的好处的情况下，已经成功构建了许多基于复杂软件的系统。
这种热病本身的直接症状相对良性，但感染乌托邦热病肯定会导致感染更危险的变种，特别是 42 热病（稍后描述），在这种热病中，UML 被认为是解决所有问题的答案。探测疑似乌托邦热病携带者的一个好的试金石是询问他们是否知道 UML 的起源，或者工程师在 UML 之前使用什么方法来设计复杂的软件密集型系统。
现实是，当你停止相信它时，它不会消失。——菲利普·K·迪克
盲目采用者热病。 这种变种在那些在评估其自身程序可用技术和过程的适当使用方面失去判断力的人中被识别出来。与量身定制或拒绝相反，盲目采用者热病的受害者倾向于接受其他人在其他程序上所做的事情，即使它可能不适用于他们自己的程序。
已经观察到患有盲目采用者热病的工程师盲目地将状态机语义强加到他们的所有类中，仅仅是为了利用将 UML 图转换为代码的正向工程技术。这种热病的其他观察到的症状包括直接使用开箱即用的软件开发过程或过程框架，而不是根据自身程序的需求对其进行定制。使用此类过程的副作用是在生成许多不必要的工件上浪费时间和金钱。
对于大多数人来说，对一件事的不相信源于对另一件事的盲目相信。——格奥尔格·克里斯托夫·利希滕贝格
咒语热病。 在咒语热病患者中最常观察到的症状是现实感受损。已经观察到，当管理者被告知可以从 UML 图自动开发软件的技术时，会大量流口水。想到提高代码生产力指标，之前由于必须开发极其复杂的业务逻辑而拖累了指标，也会产生包括睁大眼睛和喃喃自语说要发大笔圣诞节奖金的症状。人们只能想象当管理者假设使用 MDA（模型驱动架构）自动开发整个系统时，咒语热病未来的症状。
虽然管理者是咒语热病的主要受害者，但工程师也已知易受感染。这种热病在工程层面的常见症状是期望从庞大的 UML 模型中获得几乎超现实的信息。例如，对吞吐量、容错性、延迟和系统安全性的洞察力仅仅是预期从 UML 模型中获得的少数几项，而无需费心编写代码或进行工程工作来表征全面的组件行为。咒语热病似乎在几乎没有使用 UML 实践经验的工程师中非常具有传染性。
真正受过教育的人是那种罕见的个体，他可以将现实与幻想区分开来。——佚名
42 热病。 正如道格拉斯·亚当斯在《银河系漫游指南》1 中提出的，著名的“42”是关于生命或宇宙的任何问题的答案，而患有 42 热病的人则认为“UML”实际上是正确的答案。在软件工程领域，患有 42 热病的人的经典症状是先验地妄想 UML 是解决所有软件工程问题的方案。研究表明，通过在 42 热病患者的工作区域秘密播放强调 UML 的创建者并不打算将其作为解决所有软件工程难题的答案2 的潜意识信息，可以显着减少患者的妄想。
尽管 42 热病和咒语热病相似，并且经常同时困扰它们的受害者，但一些细微的差异值得注意。患有 42 热病的人认为 UML 是所有问题的正确答案，句号。另一方面，患有咒语热病的人并没有妄想 UML 一定是所有问题的答案，只是他们认为它是神奇答案的问题的答案。
如果你唯一的工具是锤子，你就会倾向于把每个问题都看作钉子。——亚伯拉罕·马斯洛
策展人热病。 就像博物馆馆长对绘画有着迷恋和热情一样，软件工程领域中患有策展人热病的人也对 UML 图有着类似的沉迷。这种沉迷是由策展人热病倾向于使其受害者相信 UML 图的制作，而不是其背后的工程内容，是软件开发生命周期中最重要的一项活动所助长的。
策展人热病患者的一种常见行为是，领域分析师创建了大量的用例图，但仍然没有意识到用例建模最重要的工件是开发支持文本3。对象之间消息类似于“解决世界饥饿”的 UML 交互图对任何利益相关者都几乎没有价值。患有策展人热病的用例建模者经常宣称，如果软件设计师无法基于极其高级的图表生成软件设计，那么他们就是不称职的。软件设计师通常宁愿用图片代替千言万语的唯一地方是在博物馆里。
博物馆里的一幅画听到的荒谬意见比世界上任何东西都多。——埃德蒙·德·龚古尔
引力热病。 这种热病会导致患者产生妄想，认为引力加速度使其 UML 工件质量具有价值。对于那些不熟悉牛顿第二运动定律的人来说，患有引力热病的人认为软件工程工作的进展与项目的 UML 工件的重量成正比。
研究表明，软件管理者是最容易感染引力热病的人群。这种热病的一个常见症状是，监督代码黑客狂潮的管理者指示开发人员将其代码逆向工程为大量的 UML 图。这些 UML 图随后被当作设计模型来传递，而不是它们真正是实现模型。
引力热病经常被误诊为策展人热病，因为这两种疾病的相似性。然而，这两种热病之间的细微差别在于，患有策展人热病的人非常关注 UML 图的质量，而患有引力热病的人只关心它们的重量。
那些最常谈论进步的人是用数量而不是质量来衡量进步的。——乔治·桑塔亚纳
情感型元热病。 构成情感型元热病组的变种倾向于攻击和利用人体的情感系统。它们包括本节中描述的指责热病、舒适区热病、绝望热病和神圣牛热病（见图 3）。
指责热病。 这种热病恰好发生在那些正处于从先前感染的更严重的热病中恢复的最后阶段的人身上。指责热病的严重程度似乎与先前在被其他热病蹂躏时开发不必要的 UML 工件上浪费的时间和金钱量直接相关。指责热病的一个常见症状是，其患者不合理地指责软件开发过程或框架提倡开发过多的 UML 工件。这种热病的另一个常见症状是指责 UML 本身过于富有表现力，并鼓励将设计工件建模到不必要的低细节级别。
如果你的脸是歪的，责怪镜子是没有用的。——尼古拉·果戈里
舒适区热病。 舒适区热病的受害者通常在从事专注于创建 UML 工件的活动时，会享受到一种催眠般的宁静感。临床分析表明，其患者试图从创建 UML 图迁移到生命周期后期的软件开发活动中，会导致这种宁静感突然且痛苦地停止。结果，受害者的 UML 图变得数量庞大且极其详细（这让患有引力热病的人感到非常高兴）。
舒适区热病的识别特征是其受害者抵制离开 UML 图创建的舒适区。程序风险在舒适区热病存在的情况下经常被放大，因为拟议的设计没有像他们应该在实现形式中那样尽早得到验证。
贪图安逸的学者不配被称为学者。——孔子
绝望热病。 广泛的临床研究已经确定了绝望热病的发生与项目创伤（例如计划延误、生产力低下和产品质量差）的存在之间的相关性。患有绝望热病的人的症状是耳朵扁平，这是由于花费了过多的时间在电话上与供应商交谈，寻找能够解决所有已知项目难题的产品而导致的。
绝望热病的受害者经常购买昂贵的以 UML 为中心的产品，但后来才发现，正确使用这些产品与他们缺失或损坏的软件开发过程不一致，而这通常是他们最初问题的根源。由于高薪顾问告诉患者，新购买的产品如果不彻底改造现有的软件开发实践，就不会带来好处，因此绝望热病的严重程度通常会升级。
不做绝望的事情是智慧的特征。——亨利·戴维·梭罗
神圣牛热病。 患有神圣牛热病的人会对 UML 图产生强烈的情感依恋，并拒绝让任何已过时的 UML 图体面地死去。神圣牛热病会导致程序产生许多成本，包括维护过时工件的成本、错误信息传播以及不必要地消耗存储资源。临床研究表明，这种热病会导致其受害者相信，通过丢弃 UML 图，他们会在某种程度上对程序的向前进展产生负面影响（这让引力热病患者感到非常高兴）。
治疗神圣牛热病的受害者应包括咨询方案，强调 UML 图的价值通常是短暂的，并鼓励丢弃那些不再有价值的图4。
如今，无用的信息如此之少，真是一件非常可悲的事情。——奥斯卡·王尔德
程序型元热病。 属于程序型元热病的 UML 热病变种（见图 4）倾向于阻碍其受害者认识到他们没有遵循开发过程，或者他们可能正在遵循一个非常糟糕的过程。程序型元热病变种被称为开环型、围车型、吹毛求疵型、厨房水槽型和往返型。
开环型热病。 开环型热病的影响会刺激人们渴望大量创建 UML 图，而没有可追溯的目标或没有明显的利益相关者。开环型热病的受害者认为，仅仅创建 UML 图的行为本身就是增值活动的保证。临床研究表明，最容易感染开环型热病的人是那些从未成为 UML 图的最终用户的人，以及那些在软件生命周期中经历非常有限的人。
催眠已被证明可以有效缓解开环型热病的症状。受害者被编程为将图的创建与程序目标5联系起来，并与图的客户互动，以确保满足他们的需求。对这种热病患者的催眠后访谈导致发现 UML 图并不总是生命周期下游人员首选的工件。
疯狂的活动不能代替理解。——H. H. 威廉姆斯
围车型热病。 广泛的临床研究6导致了围车型热病的发现。它的主要症状是其受害者倾向于使用 UML 用例图来捕获其领域空间的细粒度功能分解。这种热病的名称源于观察到其受害者倾向于以可怕的马车队形阵型创建用例图，如图 5 所示。
尽管其受害者具有进行面向对象的领域分析的崇高意图，但研究表明，围车型热病放大了其受害者将问题分解成越来越小的块的自然倾向，以至于成为一种强迫行为。与简化用例建模活动相反，围车型热病的受害者实际上使它变得更加复杂，使得用例模型更难以理解。
围车型热病经常在具有功能分解背景的受害者中观察到。然而，这种热病没有界限；即使是有面向对象经验的人有时也会成为受害者。这是一种非常常见的热病，应仔细监测工程人员中的症状，特别是在程序生命周期的早期阶段。
智慧是知道下一步该做什么；美德是去做它。——大卫·斯塔尔·乔丹
吹毛求疵型热病在其受害者中被识别出来，其特征是非常强烈地渴望创建极其详细的 UML 图。不要与舒适区热病混淆，在舒适区热病中，详细建模是情感因素的副作用，吹毛求疵型热病的患者明确地认为，建模到非常低的细节级别很重要，因为这样做会增加生成的代码更正确的可能性。由于系统需求的变化以及并行发生的依赖性设计活动等变量，例如，花在低级别建模上的时间通常最好应用于实际实现。
临床研究表明，在那些实际上没有参与编码活动的建模者中，吹毛求疵型热病的感染率很高。支持研究结果的一种理论认为，编码经验对于培养价值感非常重要，这种价值感为建模者提供了洞察力，让他们了解什么对模型的下游客户有价值，什么没有价值。
良好的判断力来自经验。经验来自糟糕的判断力。——吉姆·霍宁
厨房水槽型热病。 厨房水槽型热病的受害者渴望构建庞大的 UML 模型，其中包括所有细粒度的设计元素及其详细的辉煌。厨房水槽型热病通常伴随着咒语热病，患有咒语热病的受害者认为，在没有代码的情况下，可以通过描述跨越模型表示的子系统的交互的低级别行为来推导出信息。厨房水槽型热病的受害者通常花费大量时间从建模工具崩溃的影响中恢复。
临床研究表明，厨房水槽型热病患者渴望其模型中包含所有可能的工件的原因之一是，他们对可以从中实际推导出哪些信息了解不足。研究还表明，那些感染这种热病的人通常从未使用过庞大的模型。
人类因其工具而变得愚蠢。——托马斯·伊莱沙·斯图尔特
往返型热病。 主要症状对其患者产生非常严重的影响：完全丧失使用抽象作为管理软件设计复杂性的手段的能力。往返型热病的受害者经常无法区分 UML 设计模型和他们从详细代码中逆向工程的实现模型。负责进行设计评审的软件架构师通常会给出不及格的评分，如果他们在评审包中收到实现模型的话。
往返型热病的起源似乎扎根于技术。它的受害者通常从传统的设计周期开始，创建非常低级别的实现模型，以便他们可以利用逆向工程工具集。往返型热病主要针对的人群是以技术为中心而不是以架构为中心的新毕业生。需要进一步研究，但年轻工程师抽象能力的严重缺陷的下游影响是一个令人担忧的问题。
我们的生活被细节琐事浪费掉了。简化，简化。——亨利·戴维·梭罗
波丽安娜型元热病。 与波丽安娜型元热病相关的变种（见图 6）通常在管理者中观察到，其特征是愚蠢或盲目乐观的结果。波丽安娜型元热病包括方枘圆凿型热病、独眼人型热病和变形者型热病。
方枘圆凿型热病。 这种变种使其受害者相信，所有项目工作人员都是可互换的，无论其经验、背景或教育程度如何。症状包括将需求人员安排到软件设计师的角色中，并将任何能够使用 UML 建模工具的人分配到领域分析师的角色中。当方法学家被安排到技术专家和实践者的角色中时，方枘圆凿型热病有可能引发各种变种的 UML 热病。
研究表明，一些方枘圆凿型热病病例是由大多数人都有能力创建类似于对绝望的观察者有价值的工件的 UML 图的能力引发的。面对人员短缺或技能组合不平衡时，方枘圆凿型热病尤其普遍。
任何数量的人为强化都无法抵消人类个体天生的不平等。——亨利·P·费尔柴尔德
独眼人型热病。 我们早就听说过一句谚语，“在盲人国里，独眼人为王。”这句谚语体现在软件工程领域，即独眼人型热病，通常困扰那些将不具备在该职位上所需的专业知识的人安排到职位上的管理者。独眼人型热病的受害者可以通过他们仅仅根据 UML 语法速成班的出席次数来选择项目的 UML 远见者来识别出来。
这种热病似乎在那些对其管辖范围内的技术不了解，以至于无法就这些技术做出决策的管理者中发病率很高。独眼人型热病的一个非常不受欢迎的副作用是，组织中的盲人经常将独眼人的做法误认为是最佳实践并加以采用。
博物馆里的一幅画听到的荒谬意见比世界上任何东西都多。——埃德蒙·德·龚古尔
变形者型热病。 变形者型热病的受害者表现出狂暴的疾病，他们将人们送到简短的设计工具和语言语法课程中，并期望他们作为最佳实践专家返回。患者误认为导航“文件”->“新建”->“类图”下拉菜单的能力是软件设计师的标志性品质。当关于工具和语言用法的课程脱离它们在程序中实际使用方式的背景进行教授时，变形者型热病的症状会特别加剧。正如有些人认为“人靠衣装”一样，这种热病的患者认为“UML 造就设计师”。
与波丽安娜型元热病类别中的其他变种非常相似，变形者型热病在预算受限和人员短缺时期最为普遍。
教育就像一把双刃剑。如果处理不当，它可能会被用于危险的用途。——伍廷芳
战斗
所描述的各种 UML 热病变种是基于第一手的痛苦和观察，而不是仅仅是虚构作家的缪斯。描述这些热病时所用的轻松方式绝不应安抚读者，让他们相信这些热病不是真实的，或者它们的症状可能不会对其自身软件程序的成功产生严重影响。
大多数 UML 热病的根源在于，负责选择和应用程序软件开发工作基础技术和过程的个人缺乏实践经验。这种缺乏经验转化为对技术的不切实际的期望和误用，而非或糟糕的软件开发过程常常加剧了这种情况，这是 UML 热病的完美滋生地。如果一个软件组织对抗 UML 热病的战斗要取得成功，那么至关重要的是，具有实践经验的人员要到位，推动技术的选择以及相关使用过程的制定。
一些软件组织在自我诊断疾病方面遇到的困难进一步使对抗 UML 热病的战斗复杂化。正如先前在妄想型元热病的描述中建议的那样，一些组织可能会完全沉迷于 UML，以至于他们忽视了他们的主要目标，即开发软件，而倾向于构建庞大的模型。在这种情况下，来自组织外部的独立专家帮助可能是启动 UML 热病恢复过程的唯一选择。项目管理部门必须定期评估有影响力的职位上的员工是否患有 UML 热病，因为它的发病有时是渐进的。未能及时诊断出 UML 热病可能会导致其以流行病的比例蔓延，并产生破坏性影响。
只有对其症状进行编目、描述和公开（这是本文的三个明确目标），才能对 UML 热病进行系统诊断。然而，诊断只是康复过程的第一步。受感染的软件组织还必须确定并认真遵循适当的治疗方案，才能摆脱 UML 热病带来的衰弱影响。康复之路并非总是容易的。试图为其受感染的组织启动诊断和治疗计划的善意人士可能不得不忍受否认、毫无根据的合理化和愤怒的不愉快，这些不愉快的强度通常与 UML 热病在组织领导层中的级别高低直接相关。对抗 UML 热病的战斗可以赢得胜利，但前提是它被承认为一种真正的疾病，并且那些患有这种疾病的人走上康复之路。
参考文献
1. 亚当斯，D. 《银河系漫游指南》。 Crown Publishing Group，纽约：NY，1980 年。
2. Rumbaugh，J.，Jacobson，I. 和 Booch，G. 《统一建模语言参考手册》。 Addison-Wesley，波士顿：MA，1998 年。
3. Larman，C. 《应用 UML 和模式》。 Prentice Hall PTR，上萨德尔河：NJ，2001 年。
4. Ambler，S. 敏捷建模的实践； http://www.agilemodeling.com/practices.htm。
5. Ambler，S. 敏捷建模的原则； http://www.agilemodeling.com/principles.htm。
6. Bittner，K. 为什么用例不是“函数”。 Rational Edge。（2000 年 12 月）； http://www.therationaledge.com/content/dec_00/t_ucnotfunctions.html。
ALEX E. BELL ([email protected]) 是波音公司的软件架构师。他在指挥与控制、空中交通管制和电信等多个领域拥有超过 22 年的软件经验。
UML 的生活：仍然是工作
PHILIPPE KRUCHTEN，软件架构师
Alex 的“UML 热病致死”中确定的许多热病都与软件过程、软件过程的缺失或对过程用途的根本误解有关。我听到诸如以下评论：“哦，我们运行了 RUP（Rational Unified Process，统一软件过程）描述的所有活动，并创建了它规定的所有 UML（统一建模语言）图...”或“UML 中有这个小部件，但我找不到 RUP 说如何使用它。” UML 是一种符号，在大多数情况下应简单地用于说明您的设计，并用作相应实现的一般路线图。不幸的是，一些 UML 用户将他们的大脑留在门厅，在键盘后面安顿下来，并忙于绘制 UML 图，因为这样做比进行困难的软件工程工作更容易。
热病是真实的
GRADY BOOCH，IBM 院士
80 年代末和 90 年代初，出现了许多相互竞争的软件设计方法，每种方法都有独特的概念、符号、术语、过程和与之相关的文化。虽然其中一些方法引入了新的和创新的想法，但大多数方法都渴望实现非常相似的目标，尽管使用了不同的几何图形、颜色和词汇来实现这些目标。
新兴的方法论大杂烩带来了许多后果，包括越来越多的软件工程师不具备可移植的技能，工具集不互操作的祸根，以及无法以普遍可理解的形式描述软件设计。由于没有一种方法正在成为领跑者，软件工程行业迫切需要标准化来推动迫切需要的统一。
UML（统一建模语言）专门创建用于充当这种统一力量，并在 1997 年 11 月被 OMG（对象管理组织）一致通过作为标准。 UML 引入了一种标准符号和底层语义，用户可以使用它来描述和交流软件设计，这在以前是无法实现的。它的符号旨在超越编程语言、操作系统、应用程序领域和软件生命周期阶段，以满足渴望秩序的行业的需求。软件工程新时代的曙光即将出现。
它确实出现了。自 OMG 采纳 UML 以来已经六年了，UML 继续被软件工程界广泛接受。软件开发组织继续投资于 UML 培训、支持 UML 的工具集以及将 UML 集成到其开发过程中。全球许多组织已成功地以创新的方式使用 UML 来改进他们设计和开发软件的方式。
然而，许多其他组织并没有享受到他们认为仅仅使用 UML 就能带来的成功。 UML 的成功需要思考和计划，并理解其目的、局限性和优势——就像任何技术的使用一样。只有通过这种意识，组织才能最有可能应用 UML 来解决其独特的需求，在其自身的背景下，并以增值的方式进行。为了技术而盲目采用和使用技术对于任何技术来说都是灾难的根源。
Alex 的“UML 热病致死”中描述的疾病通常表明组织对 UML 的误解，但更重要的是，在其中使用 UML 的系统性问题开发过程。例如，UML 并非旨在以完美无缺的细节对组织软件的每一行代码进行建模。它并非旨在成为定义全面模拟上下文的前端语法。它并非旨在绘制没有价值或不与软件开发过程相关的图表。最后，UML 当然不是要取代软件开发过程本身。相反，UML 过去是并且现在仍然是软件开发过程的重要组成部分，其目标包括规定价值意识地使用适用的技术。
UML 的下一个重大进化里程碑是计划于 2004 年发布的 2.0 版本。六年 UML 1.x 的行业经验暴露了几个值得升级的领域，包括行为规范的改进以及用户可扩展性。然而，令人期待已久的 UML 2.0 的改进并不能消除 UML 热病，也不能最大限度地减少对它的易感性。智能地使用技术、遵守良好的软件开发过程以及拥有具有适当技能组合的经验丰富的人员，对于现在的成功与 UML 出现之前的日子一样至关重要。
“UML 热病致死”的娱乐性基调不应被推断为暗示 UML 热病是一种虚构的疾病。它是真实存在的，它正在蓬勃发展，并且它的存在目前正在给许多软件程序造成成本和进度上的创伤。此外，这种热病的根本原因通常与 UML 本身无关：相反，这种热病及其各种表现形式在很大程度上是一个组织软件开发实践中更深层次弊病的症状。软件组织应考虑发起自我诊断活动，以评估其程序中 UML 热病的存在或程度，并根据需要计划康复策略。开发好的软件已经是一项足够困难的任务，而无需忍受可怕的 UML 热病带来的可预防且往往痛苦的并发症。
GRADY BOOCH 是 UML 的最初开发者之一，并因其在软件架构、建模和软件工程流程方面的创新工作而闻名。
最初发表于 Queue vol. 2, no. 1—
在 数字图书馆 中评论这篇文章
更多相关文章
Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
尽管加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。 针对各种安全需求，加密哈希存在许多标准，但在非加密方面，存在一定的传统认知，尽管哈希函数历史悠久，但尚未得到充分探索。 虽然针对真实世界数据集的均匀分布很有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 实践
DevEx（开发者体验）在许多软件组织中越来越受到关注，因为领导者们寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付。 直观上，技术领导者普遍认为，良好的开发者体验能够实现更有效的软件交付和开发者幸福感。 然而，在许多组织中，旨在改进 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发效率
本文旨在通过展示使用基于代码、低代码和超低代码技术进行的实验室实验结果，以研究生产力差异，从而为该主题提供新的见解。 低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。 本文报告了程序和协议、结果、局限性以及未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，新的工具、技术和技巧不断被开发出来以服务于商业和社会，但它也很健忘。 在它匆忙向前发展的过程中，它容易受到时尚潮流的影响，并且可能会忘记或忽略一些经过验证的解决方案，以解决它所面临的一些永恒的问题。 用例，最早于 1986 年引入并在后来普及，就是这些经过验证的解决方案之一。
© 版权所有。