我正在处理一个大型项目(对我来说)，它将有许多类，需要可扩展，但我不确定如何规划我的程序以及类需要如何交互。
几个学期前我上了一门OOD课程，从中学到了很多东西;比如编写UML，并将需求文档转换为对象和类。我们也学过序列图但不知怎么的我错过了这节课，我没能记住它们。
在之前的项目中，我尝试使用从课程中学到的方法，但通常在我说“是的，这看起来像我想要的东西”时，我就会以代码结束，我不想再挖掘出新的功能。
我有一本Steve McConnell的《Code Complete》，我经常在这里和其他地方听到它的神奇之处。我读了关于设计的章节，似乎没有得到我想要的信息。我知道他说这不是一个固定的过程，它主要是基于启发式，但我似乎不能把他所有的信息都应用到我的项目中。
那么，在高级设计阶段(在开始编程之前)，你要做些什么来确定你需要什么类(特别是那些不基于任何“现实世界对象”的类)以及它们如何相互交互?
我特别感兴趣的是你使用的方法是什么?你遵循什么样的过程，通常会产生一个良好的，干净的设计，将接近最终产品?
当前回答
学习和掌握设计模式。 接下来，学习领域驱动设计 之后，学习需求收集
我上了几个学期的OOD课程 回来后，我学到了很多;就像 编写UML和翻译 将需求文档转换为对象 和类。我们学过序列 图表也有，但不知怎么的，我错过了 讲座之类的，他们没有 跟紧我。
You know about the step 3. You need to master it. I mean, via a lot of practice to make it become your second nature. That's because the method you learn, is simply against the way we used to have. So you need to really master it. Otherwise, you will always find yourself go back to your original way of doing thing. This is somehow like Test Driven Process, where a lot of java developer give it up after a few tries. Unless they fully master it, otherwise it's just a burden to them Write use cases, especially for alternate course. Alternate course occupy more than 50% of our development time. Normally when your PM assign you a task, for instance, create a login system, he will think it's straight forward, you can take 1 day to finish it off. But he never take into account that you need to consider, 1. what if user key in wrong password, 2. what if user key in wrong password for 3 times, 3. what if user doesn't type in user name and etc. You need to list them out, and show it to your PM, ask him to reschedule the deadline.
其他回答
我认为这里的答案应该是非常不同的，这取决于这个人在现实世界中的经验。
如果你只有一两年的工作经验，那么你必须明白这一点:你如何才能真正了解你的数据，并确切地了解你要做的事情?
是的，如果您已经在现实世界中工作了5年以上，那么您可以在许多软件开发过程模型或技术中选择任何一种。
但是光靠读书是得不到经验的。你应该在一个好的领导下的好团队中学习。
如果这是不可能的，那么你应该自己做。从编写一段可能非常糟糕的代码开始迭代，学习错误，丢弃所有错误，编写更好的代码等等。
您将学到很多关于代码库的知识。工具就是工具，它们不会教你任何东西。
大型项目的问题在于您无法监督组件之间的所有交互。因此，降低项目的复杂性是很重要的。类图和序列图对于这个设计阶段来说太详细了。
首先试着从更高的抽象层次来思考。考虑主要组件及其职责(它们与其他组件的接口)，查看一些架构模式以获得灵感(不，不是设计模式，这些太低级了!MVC和多层是架构模式的例子)。 对于相当大的项目，这样的视图应该有大约3-5个组件。
只有这样，你才能放大到某个组件，并尝试设计它。现在我们到了设计模式和类图的层次。试着把注意力集中在项目的这一部分，如果你发现你需要向其他组件之一添加一个职责，就把它添加到你的文档/待办事项列表中。不要在这个时候浪费时间思考它们的含义，因为它们的变化太快了，当设计更加可靠时再进行检查。
此时您不需要完整地设计每个组件，尽管使用一段代码来实现未实现的组件接口并生成简单但有用的响应可能是明智的。这样，您就可以一次开始开发(和设计)一个组件，并对其进行合理的测试。
当然，当新组件完成后，您应该在继续之前测试它们如何(以及是否)相互集成。
简而言之: 采用面向对象和信息隐藏原理，并将其提升到另一个层次!
PS: 在设计的时候画很多草图，就像真正的建筑一样!
PPS:试着从不同的角度来看待这个问题，跳出固有的思维模式(尽管固有的思维模式可能是正确的)，与同行讨论可能会非常有用……午餐时你们有话可聊。
在你要写的软件设计中，你遵循的工作流程是什么?
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.
只是引用http://www.fysh.org/~katie/computing/methodologies.txt
并且RUP的核心是一个您必须使用面向对象设计的小区域 人才……如果你没有它们，就像有一个方法论 100米跑。
“第一步:写关于快跑的故事。 第二步:画一张赛马场平面图。 第三步:去买紧身的莱卡短裤。 第四步:跑得非常、非常、非常快。 第五步:先跨线
第四步才是最难的。但如果你特别强调 在第1 2 3 5次，有可能没有人会注意到，然后你就可以 卖这个方法可能会赚很多钱 那些认为成为百米运动员有什么“秘密”的运动员
