我周一有一个小的UML作业;它似乎并不太复杂，我不是要求这个网站为我解决它 - 我只是要求澄清我的一些疑问。
我只是告诉部分作业，因为它的内容可能不太相关。
我们提供了一个基本用例，演员“官员”（例如警察）与演员“通讯员”进行沟通，以报告紧急情况。用例以以下形式表示：
用例名称：报告紧急情况
参与演员：官员，通讯员
事件流程：......
先决条件：......
后置条件：......
然后我们给出了三个“细化”用例的场景。我说“精炼”是因为它们颠倒过来：它们涉及团队领导者，受访者，事件处理 - 在最基本的用例所描述的事件流中甚至没有提到任何内容。
除了这些场景之外，我们还给了10个“事件”（即他们基本上将这三个场景分成十个容易识别的句子）。作业要求我们为每个事件制作一个协作图。
我知道协作图描述了系统的行为，即系统的不同部分如何相互作用。所以我认为，即使有这些“创造性”的情景，我也可以用它们做出一些东西。但接下来是这部分：
“协作图应该使用控制器，边界，域对象和完全处理每个事件所必需的其他新制造的软件对象（例如数据结构组件）。”
然后：
“您的作业将根据您的设计质量进行评估（即模块化：低耦合，高内聚）”
我的问题是：
1）与基本用例相比，场景应该提供如此多的新信息吗？
2）我是否只需绘制十个简单的协作图？使用哪些类？
3）为什么会提到低耦合，高内聚，域对象之类的东西？他们与所有这些有什么关系？
答案 0 :(得分：0)
1）场景是用例的详细描述。可以有几种基于约束的场景。用例本身只是以浓缩格式描述晴天场景。肉是在场景中。
2）在完成场景时，可以提取与UC相关的类。您将找到指示需要执行某些功能的文本部分。获取这些类并将它们放在协作图中，并使用正确的消息将它们连接起来。
3）这些是一般设计规则。低耦合/高内聚意味着良好的设计（反之亦然）。域对象是系统中心的对象，所有用例的总和将处理所有域对象的总和。