建模文件分析应该吗？
我使用UML
我和大多数人一样(我认为)使用UML作为我的主要图表工具集。UML对于表示OOP是明确的和有用的，并且有足够多样的图表，无论您正在建模的领域是什么；不管是类树、组件关系，还是类之间的特定交互。
--这意味着，我只有一个型号的
UML显然是为了表示已实现的域而设计的。
类和对象图是相当明确的；它们包括方法和属性，在您决定具体的实现细节之前，这些方法和属性很少能被明确地定义。类似地，行为图的特征是在对象之间(发送的消息、发送的顺序等)之间的交互。
然而，早期的分析模型很少如此明确。就上下文而言，我的早期分析如下：
- 描述要实现的用例；描述参与者的输入和系统响应的场景
- 描述要实现的交互；此组件/包/域必须具有接口X，并且必须支持类似于.
- 描述域所完成的过程；此域必须执行X，这是工作流
从这里开始，我有了一组清晰的需求，并开始分析问题域本身；定义对象/类、它们的关联、它们持有的信息类型以及它们支持的操作类型。最后，我进行了详细的设计，它提供了所有的实现级类，具体说明了问题域中定义的类的确切方法和属性，等等。
我从头到尾都使用UML，但最后只得到了由流程的设计部分定义的模型。在分析过程中创建的任何东西最终都会被修改、细化、调整和刺激，直到它与实现的设计相同为止。也就是说，我只有一个实施模式，而不是一个分析模式。
只有一个模型因为.
简而言之，UML鼓励细节。当我创建我的分析模型时，我创建的类都有带有参数的方法等等。当我进入实现时，这些变化似乎是荒谬的，留下两个直接相互冲突的模型。
UML鼓励我在分析期间编写实现细节，因为在这两项活动中都使用了相同的图表，因此使用了语言。
这是可取的吗？
我是否应该采用一种较少冗长的建模工具来进行分析，以便它最终不会被纳入实现模型？
或者，只有一个模型好吗？
回答 1
Software Engineering用户
发布于 2016-03-07 20:24:51
基于托马斯·欧文斯的回答..。
我鼓励您考虑“模型驱动”(目标是从模型直接生成产品)和“基于模型的产品”(目标是为人类利益相关者创建“真理的单一版本”)之间的区别。
我碰巧主要在SysML (一个基于UML的概要文件)中工作，并且坚定地站在“基于模型的”阵营中。如果您是这个阵营的成员，那么您在图表中唯一需要的就是那些专门帮助特定涉众理解系统工作方式的东西。例如，您可以在类图中放置大量内容，但是这样做对您的人类涉众很少有帮助。
同样，您必须仔细考虑序列图的目标。在开始制作图表之前，您确实必须决定自己站在哪一边(基于模型的还是模型驱动的)。去年秋天，在QA&Test 2015上，我和一位年轻的荷兰工程师进行了一次很好的讨论，他正在研究测试中的模型。正如她所说：“如果图表对人类来说是清晰和有用的，那么它就没有足够的信息供计算机执行。如果你添加了足够多的信息，使计算机能够执行它，那么这个图表就会让人类无法理解。”
希望这能帮上忙
https://softwareengineering.stackexchange.com/questions/311940
复制相似问题
腾讯云开发者
