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

Question

我挣扎的一件事是在编写任何代码之前规划应用程序的架构.

我并不是说收集需求来缩小应用程序需要做什么,而是有效地思考一个好的方法来布置整体类,数据和流程结构,并迭代这些想法,以便我有一个可靠的计划甚至在打开IDE之前的行动.目前,只需打开IDE即可轻松创建一个空白项目,开始编写位和bob,让设计从那里"长出来".

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

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

我很感激你的意见.

Answer 1

我考虑以下几点:

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

然后我开始将系统看作黑盒子并且:

1. 黑盒子需要发生什么样的互动
2. 什么是黑盒子内部需要发生的行为,即黑盒子在更高层次上展示所需行为的那些交互需要发生什么,例如接收和处理来自预订系统的传入消息,更新数据库等.

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

UML非常适合表示这种行为.您可以使用UML的许多组件中的两个来描述大多数系统,即:

• 类图,和
• 序列图.

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

学习UML的一个很好的资源是Martin Fowler出色的书"UML Distilled"(亚马逊链接 - 为那里的脚本小子链接纳粹消毒( - :)).本书让你快速浏览每个组件的基本部分. UML.

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

Answer 2

我真的发现在纸上或白板上写作的第一步非常重要.然后根据需要转移到UML,但没有什么能比起手工绘制它的灵活性.

Answer 3

你一定要看看史蒂夫麦康奈尔的代码完整 - 尤其是他在"建筑设计"的赠品章节

你可以从他的网站下载:

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

Answer 4

如果您正在为.NET开发,Microsoft已经发布了(作为免费的电子书!)应用程序架构指南2.0b1.在编写任何代码之前,它提供了大量有关规划架构的非常好的信息.

如果你绝望,我希望你可以使用大块的非基于.NET的架构.

Answer 5

我要说的是,我主要进行Web开发,其中大部分架构已经提前决定(WebForms,现在是MVC),而且我的大多数项目都是相当小的,单人工作需要不到一年的时间.我也知道,我将分别使用ORM和DAL来处理业务对象和数据交互.最近,我已经转而使用LINQ,因此很多"设计"通过DBML设计器成为数据库设计和映射.

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

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

我会发现自己想要再次编写一些代码,或者认为"这真的很有气味",我会重构我的设计以消除重复或用更优雅的东西取代臭味.大多数情况下,我关注的是在遵循良好的设计原则的同时降低功能.我发现使用已知的模式并注意良好的原则,你可以很好地解决问题.

Answer 6

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

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