我正在处理一个大型项目(对我来说)，它将有许多类，需要可扩展，但我不确定如何规划我的程序以及类需要如何交互。
几个学期前我上了一门OOD课程，从中学到了很多东西;比如编写UML，并将需求文档转换为对象和类。我们也学过序列图但不知怎么的我错过了这节课，我没能记住它们。
在之前的项目中，我尝试使用从课程中学到的方法，但通常在我说“是的，这看起来像我想要的东西”时，我就会以代码结束，我不想再挖掘出新的功能。
我有一本Steve McConnell的《Code Complete》，我经常在这里和其他地方听到它的神奇之处。我读了关于设计的章节，似乎没有得到我想要的信息。我知道他说这不是一个固定的过程，它主要是基于启发式，但我似乎不能把他所有的信息都应用到我的项目中。
那么，在高级设计阶段(在开始编程之前)，你要做些什么来确定你需要什么类(特别是那些不基于任何“现实世界对象”的类)以及它们如何相互交互?
我特别感兴趣的是你使用的方法是什么?你遵循什么样的过程，通常会产生一个良好的，干净的设计，将接近最终产品?
当前回答
我在实际项目中使用的成功的技术是责任驱动设计，灵感来自Wirfs-Brock的书。
从最顶层的用户故事开始，与同事一起，在白板上勾勒出它们所暗示的高级交互。这让你对大模块有了初步的了解;重复一两次高级CRC-card(游戏邦注:如play)，你应该已经稳定了一个主要组件列表，它们的作用以及它们如何相互作用。
然后，如果任何职责很大或很复杂，那么细化这些模块，直到有足够小且简单的东西成为对象，方法是在模块内执行由更高级别交互确定的每个主要操作的交互。
知道什么时候该停下来是一个判断问题(只有经验才能决定)。
其他回答
首先，设计应该来自你的灵魂。你必须用每一根纤维去感受它。在我开始做任何事情之前，我通常会走两三个月，只是在街上走(真的)。和思考。你知道，散步是一种很好的冥想。所以它能让你更好地集中注意力。
其次，只在存在自然对象层次结构的地方使用OOP和类。不要人为地把它“拧”进去。如果没有严格的层次结构存在(就像在大多数业务应用程序中一样)-选择过程式/函数式，或者至少只将对象用作具有隔离访问器的数据容器。
最后一本——试着读一下:《创造性思维的算法》
大型项目的问题在于您无法监督组件之间的所有交互。因此，降低项目的复杂性是很重要的。类图和序列图对于这个设计阶段来说太详细了。
首先试着从更高的抽象层次来思考。考虑主要组件及其职责(它们与其他组件的接口)，查看一些架构模式以获得灵感(不，不是设计模式，这些太低级了!MVC和多层是架构模式的例子)。 对于相当大的项目，这样的视图应该有大约3-5个组件。
只有这样，你才能放大到某个组件，并尝试设计它。现在我们到了设计模式和类图的层次。试着把注意力集中在项目的这一部分，如果你发现你需要向其他组件之一添加一个职责，就把它添加到你的文档/待办事项列表中。不要在这个时候浪费时间思考它们的含义，因为它们的变化太快了，当设计更加可靠时再进行检查。
此时您不需要完整地设计每个组件，尽管使用一段代码来实现未实现的组件接口并生成简单但有用的响应可能是明智的。这样，您就可以一次开始开发(和设计)一个组件，并对其进行合理的测试。
当然，当新组件完成后，您应该在继续之前测试它们如何(以及是否)相互集成。
简而言之: 采用面向对象和信息隐藏原理，并将其提升到另一个层次!
PS: 在设计的时候画很多草图，就像真正的建筑一样!
PPS:试着从不同的角度来看待这个问题，跳出固有的思维模式(尽管固有的思维模式可能是正确的)，与同行讨论可能会非常有用……午餐时你们有话可聊。
关于这一点，我所知道的最有趣的来源是Bertrand Meyer所著的《面向对象软件构建》第二版的D部分。
第四部分:面向对象的方法论:很好地应用该方法
19:关于方法论， 20:设计 模式:多面板交互 系统中, 21:传承案例研究: 交互系统中的“undo”，22: 如何找到课程，23: 课程设计原则，24:使用 继承好，25:有用 技巧，26分:风格感，27分: 面向对象分析，28:The 软件构建过程，29: 教学方法
有趣的是，第22章。如何在网上找到课程。
During my adventures of designing class structures, I’ve noticed that it’s very helpful to start with writing some pseudo-code. That means: I start with “writing” some general fragments of application’s code on a highest level, play with it, and discover the elements that are appearing – in fact, the elements that I – as a programmer – would like to use. It’s a very good starting point for designing general structure of modules and their interactions. After few iterations the whole structure starts to look more like a full system of classes. It’s a very flexible way to design parts of code. You can call it a programmer-oriented design.
一个有用的技巧是将你独特的问题描述与你在现实世界中可以找到的东西联系起来。例如，你正在为一个将席卷全球的复杂医疗保健系统建模。有什么例子你可以随时调用建模吗?
确实。观察旁边的药房是如何运作的，或者医生的房间。
把你的领域问题归结为你能理解的问题;一些你能联想到的东西。
然后，一旦领域内的“玩家”开始出现，你开始对你的代码建模，选择“提供者-消费者”建模方法，即你的代码是模型的“提供者”，而你是“消费者”。
与领域相关并在较高层次上理解它是任何设计的关键部分。
