在编写任何代码之前，您如何规划应用程序的体系结构？

Question

我努力的一件事是在编写任何代码之前规划应用程序的架构。

我的意思并不是要收集需求来缩小应用程序需要做的事情，而是有效地思考一个很好的方法来布局整个类，数据和流程结构，并迭代这些想法以便我有一个在打开IDE之前，还记得可靠的行动计划。目前，只需打开IDE即可轻松创建一个空白项目，开始编写位和bob，让设计从那里“长出来”。

我收集UML是一种方法来做到这一点，但我没有经验，所以它似乎有点模糊。

你在编写任何代码之前如何规划应用程序的体系结构？如果UML是可行的方法，您能否为小型应用程序的开发人员推荐简明实用的介绍？

感谢您的意见。

Answer 1

我考虑以下事项：

1. 系统应该做什么，也就是说，系统试图解决的问题是什么
2. 谁是客户，他们的愿望是什么
3. 系统必须与
集成的内容
4. 是否有任何需要考虑的遗留方面
5. 用户交互是什么
6. 等...

然后我开始将系统视为一个黑盒子并且：

1. 黑盒子需要发生什么样的互动
2. 在黑匣子内需要发生什么行为，即黑盒子在较高水平上表现出所需行为的那些交互需要发生什么，例如：接收和处理来自预订系统的传入消息，更新数据库等。

然后，这将开始为您提供由各种内部黑匣子组成的系统视图，每个黑匣子都可以以相同的方式进一步细分。

UML非常适合表示此类行为。您可以使用UML的许多组件中的两个来描述大多数系统，即：

• 类图和
• 序列图。

如果需要描述的行为存在任何并行性，您可能还需要活动图。

学习UML的一个很好的资源是Martin Fowler出色的书“UML Distilled”（Amazon link - 为那里的脚本小子链接纳粹消毒（ - :)。这本书让你快速浏览一下基本部分UML的每个组件。

喔。我所描述的几乎是Ivar Jacobson的方法。雅各布森是OO的三个朋友之一。事实上，UML最初由另外两个人组成，他们组成了三个朋友，Grady Booch和Jim Rumbaugh

Answer 2

我真的发现在纸上或白板上写作的第一步真的很重要。如果你愿意的话，可以转移到UML，但是最初只需手动绘制它就不会有灵活性。

Answer 3

你一定要看看Steve McConnell的Code Complete- 特别是在他关于“建筑设计”的赠品章节中

您可以从他的网站下载：

http://cc2e.com/File.ashx?cid=336

Answer 4

如果您正在为.NET开发，Microsoft已经发布了{作为免费电子书！）Application Architecture Guide 2.0b1。在编写任何代码之前，它提供了大量关于规划架构的非常好的信息。

如果你是绝望的，我希望你可以在非基于.NET的架构中使用大块的。

Answer 5

我将在前言中说我主要进行Web开发，其中大部分架构已经提前决定（WebForms，现在是MVC），而且我的大多数项目都相当小，一个人的工作量少于一个年。我也知道，我将分别使用ORM和DAL来处理业务对象和数据交互。最近，我已经转而使用LINQ，因此很多“设计”通过DBML设计器成为数据库设计和映射。

通常，我以TDD（测试驱动开发）的方式工作。我不会花很多时间在建筑或设计细节上工作。我通过故事收集用户与应用程序的整体交互。我使用这些故事来制定交互设计并发现应用程序的主要组件。我在这个过程中与客户做了很多白板 - 有时用数码相机拍摄细节，如果它们看起来足够重要，可以保持图表形式。主要是我的故事在维基中以故事形式被捕获。最终，这些故事被组织成版本和迭代。

此时我通常对架构非常了解。如果它很复杂或有不寻常的位 - 与我的正常做法不同的东西 - 或者我正在与其他人（不典型）合作，我将绘制事物（再次在白板上）。复杂的交互也是如此 - 我可以在白板上设计页面布局和流程，保留它（或通过相机捕获）直到我完成该部分。一旦我对我要去哪里以及首先需要做什么有了一个大概的了解，我就会开始为第一个故事编写测试。通常，这就像是：“好的，要做到这一点，我需要这些课程。我将从这个开始，它需要这样做。”然后我开始快乐TDDing，架构/设计从应用程序的需求增长。

我会发现自己想要再次编写一些代码或者认为“这真的很有气味”，我会重构我的设计以消除重复或用更优雅的东西替换臭味。大多数情况下，我关注的是在遵循良好的设计原则的同时降低功能。我发现使用已知的模式并在你进行时注意良好的原则非常好。

Answer 6

http://dn.codegear.com/article/31863

我使用UML，并发现该指南非常有用且易于阅读。如果您需要不同的东西，请告诉我。

Answer 7

我不够聪明，不能提前做好计划。当我提前做好计划时，我的计划总是出错，但现在我已经花费了很多时间来制定糟糕的计划。我的限制似乎是在白板上约15分钟。

基本上，我尽我所能去找出自己是否朝着正确的方向前进。

我看一下我的设计中的关键问题：当A做B到C时，它对D来说是否足够快？如果没有，我们需要一个不同的设计。这些问题中的每一个都可以通过尖峰来回答。如果尖峰看起来很好，那么我们就有了设计，是时候进行扩展了。

我的代码是为了尽快获得真正的客户价值，所以客户可以告诉我应该去哪里。

因为我总是弄错了，我依靠重构来帮助我把它弄好。重构是有风险的，所以我必须在我去的时候编写单元测试。由于耦合，事后很难写单元测试，所以我先写测试。对这些东西保持纪律是很难的，不同的大脑会以不同的方式看待事物，所以我喜欢和我一起编写好友。我的编码伙伴有鼻子，所以我经常淋浴。

我们称之为“极限编程”。

Answer 8

“白板，草图和便利贴都是出色的设计 工具。复杂的建模工具有更多的趋势 分散注意力而非照亮。“来自Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt。

Answer 9

UML是一种表示法。这是一种记录您的设计的方式，但不是（在我看来）做设计的方式。如果你需要写下来，我会推荐UML，不是因为它是“最好的”，而是因为它是其他人可能已经知道如何阅读的标准，并且它创造了你自己​​的“标准”。

我认为UML的最佳介绍仍然是UML Distilled，作者Martin Fowler，因为它简洁明了，给出了在何处使用它的实用指导，并明确表示您不必购买整个UML / RUP的故事是有用的

做设计很难。在一个StackOverflow答案中无法真正捕获。不幸的是，我的设计技能，例如它们，已经发展了多年，所以我没有一个我可以推荐你的来源。

然而，我发现有用的一个模型是健壮性分析（谷歌为它，但有一个介绍here）。如果你有一个系统应该做的用例，一个涉及内容的领域模型，那么我发现鲁棒性分析是连接两者的有用工具，并确定系统的关键组件需要是什么

但最好的建议是广泛阅读，认真思考和练习。这不是一种纯粹的可教授技能，你必须真正做到这一点。

Answer 10

我不相信任何可以在实施前提前计划好。我有10年的经验，但这只是在4家公司（包括一家公司的2个站点，几乎是两极的对立面），而且几乎所有的经验都是关于观看庞大的群集****** **发生了。我开始认为像重构这样的东西真的是最好的做事方式，但与此同时我意识到我的经验是有限的，我可能只是对我所看到的做出反应。我真正想知道的是如何获得最好的体验，这样我才能得出正确的结论，但似乎没有捷径，而且只是花了很多时间才看到人们做错事:(。我我真的很喜欢在人们正确行事的公司工作（正如成功的产品部署所证明的那样），知道我是否只是一个逆向的混蛋，或者我是否真的像我想的那样聪明我是。

Answer 11

我不同意：UML可用于应用程序架构，但更常用于技术架构（框架，类或序列图......），因为这是最容易保持这些图表同步的地方随着发展。

Application Architecture 在您采用某些功能规范（描述操作的性质和流程而不对未来的实现做出任何假设）时发生，并将它们转换为技术规范。< / p>

这些规范代表实施某些业务和功能需求所需的应用程序。

因此，如果您需要处理多个大型金融投资组合（功能规范），您可能会确定需要将该大规格划分为：

• 将重度计算分配给不同服务器的调度程序
• 启动程序，以确保所有计算服务器在开始处理这些投资组合之前已启动并运行。
• 一个能够显示正在发生的事情的GUI。
• 开发特定投资组合算法的“通用”组件，独立于应用程序架构的其余部分，以便于单元测试，还有一些功能和回归测试。

所以基本上，考虑 应用程序架构 就是决定你需要以一致的方式开发什么样的“文件组”（你不能在同一个版本中开发）一组文件，一个启动器，一个GUI，一个调度员，......：他们无法以相同的速度进化）

当应用程序体系结构定义良好时，它的每个组件通常都是配置组件的良好候选者，这是一组文件，可以作为一个整体版本化为VCS（版本）控制系统），意味着所有其文件将在每次需要记录该应用程序的快照时被标记在一起（同样，很难标记 all 您的系统，每个应用程序不能同时处于稳定状态）

Answer 12

我一直在做建筑。我使用BPML首先优化业务流程，然后使用UML捕获各种细节！第三步一般是ERD！当你完成BPML和UML时，你的ERD会相当稳定！没有计划是完美的，没有抽象是100％。重构计划，目标是尽可能减少重构！

Answer 13

我试图将我的想法分解为两个方面：表达我想要操纵的事物，以及我打算用它们做些什么。

当我试图模拟我想要操作的东西时，我想出了一系列离散的项目定义 - 电子商务网站将有一个SKU，一个产品，一个客户等等。我还会有一些我正在使用的非物质的东西 - 订单或类别。一旦我拥有系统中的所有“名词”，我将制作一个域模型，显示这些对象如何相互关联 - 订单有一个客户和多个SKU，许多skus被分组到一个产品中，所以上。

这些域模型可以表示为UML域模型，类图和SQL ERD。

一旦我找到系统的名词，我就会继续动词 - 例如，每个项目通过命令执行的操作。这些通常很好地映射到我的功能需求中的用例 - 我发现的最简单的表达方式是UML序列，活动或协作图或泳道图。

将此视为一个迭代过程非常重要;我会做域的一个小角落，然后处理动作，然后回去。理想情况下，我将有时间编写代码来尝试填充 - 因为我一直在进行 - 您永远不希望设计在应用程序之前走得太远。如果你认为你正在构建一切完整的最终架构，那么这个过程通常很糟糕;实际上，你所要做的就是建立团队在开发过程中共享的基本基础。您主要是为团队成员创建共享词汇表，以便在他们描述系统时使用，而不是为如何完成系统制定法律。

Answer 14

在编码之前，我发现自己无法完全考虑系统。只是粗略地看一些你后来才意识到的比你想象的要复杂得多的组件太容易了。

一个解决方案就是努力尝试。到处写UML。通过每节课。想想它将如何与您的其他课程互动。这很难做到。

我喜欢做的是首先概述一下。我不喜欢UML，但我确实喜欢绘制图表来解决问题。然后我开始实现它。即使我只是用空方法写出类结构，我经常看到我之前错过的东西，然后我更新我的设计。当我编码时，我会意识到我需要做一些不同的事情，所以我会更新我的设计。这是一个迭代过程。 “先设计一切，然后全部实现”的概念被称为瀑布模型，我认为其他人已经证明这是一种做软件的坏方法。

Answer 15

尝试Archimate。