我对这个序列图有一些疑问,我在网上没有找到类似的例子,所以我无法比较我的解决方案。
本练习需要使用序列图对
listAllFiles
类的 Directory
方法的调用进行建模。
这是Java代码:
public class Directory {
public List<File> listAllFiles(String path) {
List<File> all = newArrayList<File>();
File[] list = new File(path).listFiles();
if(list != null) {
for (File f:list) {
if(f.isDirectory()) {
all.addAll(listAllFiles(f.getAbsolutePath()));
} else {
all.add(f.getAbsoluteFile());
}
}
}
return all;
}
}
这是我的序列图:
制作有用的序列图的第一个建议是选择“正确的抽象级别”。事实上,该图的价值在于以简单的方式展示一些仅阅读代码时难以理解的复杂交互。 不幸的是,情况恰恰相反:我们在阅读代码时立即理解了代码。所有这些主要是关于一个类的方法,使用标准库元素,例如
File
或
List
。但将其显示为序列图使其看起来非常复杂。此外,想象一下维护代码时的挑战:您的图表很快就会不同步,变得毫无用处。简而言之:不要使用 UML 进行图形编程。 UML 规范并未禁止这样做,但确实不值得付出努力。 为了练习,尽管有上述建议
File
数组和您正在循环的单个
File
。尝试使用以下生命线::Directory
(即类Directory
的匿名对象)、all:List<File>
、list:File[]
、f:File
。如果您想显示与对象无关的静态操作的使用,也可以使用 File
和
ArrayList<File>
,但这会使图表比创建对象所需的更复杂。相反,我建议以图形方式显示每个本地对象的“创建消息”,直接从创建者到生命线的头部,将对象直观地分配到正确的范围。为了避免歧义,您还应该显示 删除消息(或至少是 X),特别是对于范围有限的对象,例如
f
。
带有从消息开始的生命线头的创建消息,您将特别清楚地表明某些对象仅在迭代期间存在。这将极大地提高对您意图的理解。事实上,如果我们看不到代码,我们就无法理解它。小改进
在
alt
else
,但切勿输入
if
。你可以很好地显示消息的参数,以及返回结果的名称,但这不是强制性的,并且不会显着提高这里的可理解性。