我正在处理一个大型项目(对我来说)，它将有许多类，需要可扩展，但我不确定如何规划我的程序以及类需要如何交互。
几个学期前我上了一门OOD课程，从中学到了很多东西;比如编写UML，并将需求文档转换为对象和类。我们也学过序列图但不知怎么的我错过了这节课，我没能记住它们。
在之前的项目中，我尝试使用从课程中学到的方法，但通常在我说“是的，这看起来像我想要的东西”时，我就会以代码结束，我不想再挖掘出新的功能。
我有一本Steve McConnell的《Code Complete》，我经常在这里和其他地方听到它的神奇之处。我读了关于设计的章节，似乎没有得到我想要的信息。我知道他说这不是一个固定的过程，它主要是基于启发式，但我似乎不能把他所有的信息都应用到我的项目中。
那么，在高级设计阶段(在开始编程之前)，你要做些什么来确定你需要什么类(特别是那些不基于任何“现实世界对象”的类)以及它们如何相互交互?
我特别感兴趣的是你使用的方法是什么?你遵循什么样的过程，通常会产生一个良好的，干净的设计，将接近最终产品?
当前回答
在你要写的软件设计中，你遵循的工作流程是什么?
其他回答
当我有机会时，我通常会使用我所谓的“三次迭代规则”。
In the first iteration (or startup), I devise the general layout of the application according to the model objects, the algorithms, and the expected (really expected, not maybe expected) future directions. I don't write design documents, but if I have to coordinate multiple people, a rough sketch of the procedure is of course needed, together with an analysis of dependencies and guesstimate of the time needed. Try to keep this phase to a minimum if, like me, you prefer a more agile method. There are cases where a strong design phase is needed, in particular when everything is known and true about the logic of your program, and if you plan to have a lot of interactions between features in your code. In this case, use cases or user stories provide are a good high level idea, in particular for GUI apps. For command line apps, and in particular libraries, try to write "program stories" in which you code against the library you have to develop and check how it looks. These programs will become functional tests of your library when completed.
After this first iteration, you will have a better understanding on how things interact, got out the details and the rough spots, solved issues with a slapped duct tape patch. You are ready to make use of this experience to improve, clean, polish, divide what was too large, coalesce what was too fragmented, define and use design patterns, analyze performance bottlenecks and nontrivial security issues. In general, all these changes will have a huge impact on the unit tests you wrote, but not on the functional tests.
当您完成第二次迭代时，您将拥有一个经过良好测试、良好记录和良好设计的小珍宝。现在您已经有了进行第三次迭代(扩展)的经验和代码。您将添加新的特性和用例来改进应用程序。你会发现一些粗糙的地方，最终你会进入与第二次类似的第四次迭代。清洗并重复。
这是我软件设计的一般方法。它类似于螺旋设计，具有简短的，三个月的迭代，以及敏捷开发的元素，允许您了解问题并了解您的软件及其应用领域。当然，这是一个可伸缩性的问题，所以如果应用程序非常大，涉及到数百名开发人员，事情就会比这复杂一些，但最终我想想法总是一样的，分门别类。
总结一下:
在第一次迭代中，您将体验并学习它 在迭代2中，您将清理产品并为未来做好准备 在迭代3中，您添加了新特性并了解了更多 转到2
在你要写的软件设计中，你遵循的工作流程是什么?
老实说，最好是回头看看流程图和序列图。有大量的好网站告诉你如何做到这一点。当我考虑如何将程序分解为类时，我发现这是非常宝贵的，因为我确切地知道程序需要输入、计算和输出什么，并且每一步都可以分解为程序的一个部分。
尝试使用行为驱动开发。要打破你的旧习惯很难，但我发现BDD确实是你在现实世界中开发的最佳选择。
http://behaviour-driven.org/
首先，设计应该来自你的灵魂。你必须用每一根纤维去感受它。在我开始做任何事情之前，我通常会走两三个月，只是在街上走(真的)。和思考。你知道，散步是一种很好的冥想。所以它能让你更好地集中注意力。
其次，只在存在自然对象层次结构的地方使用OOP和类。不要人为地把它“拧”进去。如果没有严格的层次结构存在(就像在大多数业务应用程序中一样)-选择过程式/函数式，或者至少只将对象用作具有隔离访问器的数据容器。
最后一本——试着读一下:《创造性思维的算法》
