问题标签 [rational-unified-process]

RUP 与 Scrum 的对话

敏捷与 RUP 之间存在关系。实际上，我认为敏捷开发是一种 RUP。在上面来自 IBM 的文章中，您可以看到他们正在将模型拟合到 RUP。

有人对这三个有趣概念之间的关系有任何实际的解释吗？

我有点不确定统一建模语言 (UML) 与 (R)UP 在其他 OOA/D 方法中认可的不同建模视角（概念、规范和实施）之间的关系。

据我了解，使用相同符号的相同类型的图表可能具有不同的含义，具体取决于所使用的透视*。例如，类图可以从概念的角度表示现实世界系统/现象的抽象，当后来将透视图更改为规范/实现时，类图用于抽象计算机程序的构造。

问题：

1) 据我了解，UML 类图通常存在某些规则。例如，一个类可以扩展另一个类，但不能扩展关联。类图的实体以及它们如何关联的规则在哪里定义？这一切是否都发生在 UML 元模型架构的 M2 层 （参见元模型架构的维基百科插图）？

2）一个相关的问题。在我看来，特定图表的一般规则跨越了建模视角（同样，类扩展关联是荒谬的），但不同的建模视角会将某些含义叠加到特定类型的图表上。例如，域模型（概念视角）类图中的关联本质上是双向的，而在设计模型（规范/实现视角）的类图中，它可以是双向的或单向的。

在刚刚描述的场景中，规则叠加限制了关联的属性。由透视叠加的规则将始终是 uml 元模型定义的规则的子集/限制，而不是超集，这是一个正确的假设吗？

这些规则/限制是由形式化的观点定义的（以类似于元模型的方式）还是仅仅是 OOA/D 文献中描述的约定？

*第 10.8 段解释了观点：http: //books.google.co.uk/books ?id=r8i-4En_aa4C&printsec=frontcover&hl=da&source=gbs_v2_summary_r&cad=0

用例图include中和extend有什么区别？

我想学习RUP...

你有什么建议？如何开始？哪些资源？......

我在乞求一个新项目（哦，我多么喜欢一个新项目的新鲜味道！）我们才刚刚开始设计它。简而言之：应用程序是一个 UI，使用户能够对执行流程进行建模（类似于 Visio 的拖放界面）。所以我们最关心的是可用性和特性，它们将帮助用户快速清晰地建模执行流程。

我们建立的方法广泛使用用例，以便在程序员和用户之间创建和谐的应用程序视图。这是一个商业问题，真的：我更喜欢使用带有用户故事而不是用户案例的敏捷方法，但我们需要定义一个明确的范围来向我们的客户销售产品。

但是，用例有许多缺陷，其中大部分与它们包含技术细节（如 UI 等）这一事实有关，如这里所示。但是，由于我们不能使用用户故事和完全交互的设计，我决定妥协：我将使用基本用例来隐藏这些细节。

现在我有另一个问题：对 UI 交互有一个清晰的描述是必不可少的（不是双关语），那么，我应该如何记录它？换句话说，我如何通过使用 UI 交互对其至关重要的基本用例来指定应用程序？

我可以看到一些替代方案：

• 放弃使用用例，因为它们不能正确地代表问题
• 不要在用例中包含接口描述，而是创建另一个文档（故事板）并链接到基本用例
• 在基本用例中包含 UI 交互描述，因为从用户和应用程序本身的角度来看，它们是业务规则的一部分

我可能在这里非常天真，但我想澄清一些事情。RUP 似乎是 IBM 拥有的专有过程。这对任何想要实施它的项目有什么影响？

从逻辑上讲，我很难看到如何将任何“流程”设为专有 - 您只是按照规定的顺序执行一系列任务。除此之外，似乎有类似的方法，如 AUP 和 OpenUP，它们以非常相似的方式工作，但都是开源的。

我能得出的唯一结论是，专有方面是指可用于帮助实现这些的工具和图表。

正如我所说，我可能非常天真，但我想消除混乱。

我想知道 RUP 方法的足够影响的范围。我知道它在诸如 MIS 和 HIS 等 IS 系统上会非常有效，但是当您想设计和开发诸如 Control Monitoring System 之类的系统时，它是否与 IS 系统一样好。我的意思是，当此类系统上的大多数挑战是技术上的而非理性的时，RUP 所关注的关系性和信息性，是否仍然如此有效。如果不是，你建议用什么方法来代替？

我最近读了一本关于设计模式的书：我在每一页都多次看到 Artifacts 这个词！它们实际上是什么？应该用在什么地方？

在 UP 中，工件非常重要，它们在面向对象分析中发挥着重要作用。. . .

为什么要采用 UP 流程而不是其他流程？相对优势是什么？我知道它与 UML 紧密结合，但显然这不是唯一的优势？为什么选择这种方法而不是其他方法？

我已经搜索过这样的问题，但我认为没有。

正如标题所说...我知道如何在 (R)UP 和 XP 中作为一种开发系统的方式做事之间存在巨大差异，但真正的区别是什么？我正在尝试写一个很好的解释，我可以给其他人，这样他们希望很容易理解这些差异。

我想比较以下主题：

• 设计
• 文档
• 原型制作
• 用户参与
• 可用性
• 技术质量
• 测试

我不是想开始讨论，只是想知道您是否知道任何可以包含我正在寻找的信息的好网站，或者您是否对其中一个主题有答案。我自己已经写了一些，但由于我不希望这是一个主观的比较，所以我问你。