您多久会遇到所谓的“框架问题”？在描述应用程序时。领域？
您在现实任务中是否经历过这样的压力？您是如何摆脱它的？
我希望我的问题没问题，否则请关闭它。
Have you experienced such stress in a real-world task and how did you get rid of it?
I hope that my question is OK, otherwise feel free to close it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我对“框架问题”的理解是，它涉及消除对世界运作方式的隐含假设的需要。在此处给出的示例中，移动对象不会改变其颜色，绘制对象物体不会移动它。对于那些熟悉现实世界的人来说“显而易见”，但写下这样的假设却很乏味。 [然后我们将一个物体移入油漆罐，瞧！它的颜色发生了变化。]
我想说的是，就“显而易见的”内容达成一致的问题是每一次需求收集活动中都存在的问题。商人没有讲述特殊情况，因为很明显......他们甚至不知道这是一个特殊情况。
因此，作为软件生产者，我们的工作就是进入参考框架，真正理解问题领域。这很艰难。我想说，对于大部分项目来说，不正确地理解需求是一个非常严重的问题。伟大的分析师非常善于梳理细节。
My understanding of the "Frame Problem" is that it relates to the removing the need to state implicit assumptions about the way the world works. In the example given here Moving an object doesn't change its colour, painting an object doesn't move it. "Obvious" to those familiar with the real world, but tedious to write down such assumptions. [And then we move an object into the paintpot, and lo! Its colour changed.]
I would say that the problem of agreeing what is "obvious" is endemic to every requirements gathering exercise. The Business person does not tell of a special case, because it is obvious that ... they are not even aware of it being a special case.
Hence our job as producers of software is to get into that Frame of Reference, to really understand the problem domain. And it's tough. I would say that improperly understood requirements are a very serious problem for a high proportion of projects. Great analysts are very good at teasing out the detail.
我对应用程序的想法。域由术语“数据建模”“构建”。
数据建模鼓励从以数据为中心的框架查看问题域。我非常喜欢以数据为中心查看事物，但了解这种方法的局限性很重要。
问题域不仅包含数据，还包含针对该数据的操作。换句话说，它由状态和行为组成。在经典的数据库设计项目中，数据和操作在需求收集级别进行拆分。
数据分析产生数据的概念模型（通常以 ER 图和/或模型的形式表示）。操作分析会产生应用程序的功能规范。或应用程序的集合。将要使用这些数据的人。
应用程序和数据的逻辑设计通常是分开进行的。应用程序的逻辑设计。通常使用面向对象的设计，以某种方式构建事物。数据库的逻辑设计通常使用数据的关系模型，它以一种非常不同的方式构建事物。
后来，到了实现的时候，程序员就面临着“对象关系阻抗不匹配”的问题。关于这一点已经写了很多。看待这种不匹配的一种方法是，将两个不同的框架作为一个整体应用于需求。
上面的内容只是触及了您问题的表面，但这只是一个开始。
My thinking about the App. domain is "framed" by the term "data modeling".
Data modeling encourages viewing the problem domain from a data centered frame. I'm a big fan of looking at things data centrically, but it's important to understand the limitations of such an approach.
The problem domain consists not only of data, but also of actions on that data. Put another way, it consists of both state and behavior. In classical database design projects, data and actions get split at the requirements gathering level.
The data analysis results in a conceptual model of the data (often expressed in the form of an ER diagram and/or model). The actions analysis results in a functional spec for the App. or collection of Apps. that are going to use the data.
Logical design of the apps and the data often proceed separately. The logical design of the apps. often uses object oriented design, which frames things in a certain way. The logical design of the database often uses the relational model of data, which frames things in a very different way.
Later, when it comes time to implement, the programmers are faced with the "object-relational impedance mismatch". Much has been written about this. One way to look at this mismatch is that two different frames have been applied to the requirements as a whole.
The above just scratches the surface of your question, but it's a start.