设计也可以按图索骥

0. 前言

  我们小组的项目是Java程序的知识提取，我们的小组评审时的问题是类图绘制的不够完善，以及核心功能的实现没有讲清楚。课下，我们进行进一步的讨论，解决相应问题并对系统进行进一步的完善。

1. 系统设计的重点

  把所有的都忘掉，还能记住的就是我所掌握的东西。我所记住的重点是要把握系统的动态变化，比如说我们制定的规则的扩展性、用户输入可能产生的变化，系统的核心功能如何在各种变化下实现。重要的不是展示的形式，而是系统为了实现自己的核心功能如何去应对变化。
  我理解的需求分析是分析软件能告诉用户how to do，而设计分析就是在此基础上告诉用户how to do it better，给用户更大的自主权，也可以说是让系统的功能更加具有泛化能力。

2. 算法原理以及实现的详细说明

  我们希望能做到，在已知用户输入的类库后，哪些类库用户可能会使用。可以当成一种条件概率 $$max Pr(L_p|L_0)$$ ，即在已知输入的类库后，哪一个类库会出现的概率最大。 这与经典的N-gram算法十分类似，都是采用统计的方法，以频数代替概率，我们相当于是一种1-gram的方式进行预测。
  获取一个类库名与哪些类库名经常一起绑定出现。比如，一段代码中导入了库A、B、C，另一段代码中导入了库B、C、D，我们就在字典中put(<A,B>:1,<A,C>:1,<B,C>:2,<B,D>:2,<C,D>:1)。以一种字典的形式存储，键为一个pair对，排后序存入，值为这个pair对出现的次数。当用户输入代码，调用某个类库时，我们在字典中寻找这个类库出现的pair中出现次数最多的几个pair对，并显示该类库的主要函数，以及其可以实现哪些功能，方便用户了解。

3. 我们项目的设计

  基于我们的项目而言，我们的核心功能是提供用户可能会需要的类库，给予推荐，以及对于用户符号名以及注释的更改意见。相比于另一个组调用接口的方式实现大而全的功能，我们的实现方式更偏向于底层，粒度更细，所以可扩展性会更强。
  我们的扩展方式是提供一个配置文件让用户可以自定义一些功能。以符号命名为例，我们提供的默认的配置文件的规则是大家所公认。比如，包名全小写、类名采用UpperCamelCase；在类定义前要有javadoc格式的注释，代码中不能有孤立注释和行尾注释。但难免有些用户有自己的个性化需求，所以我们提供了配置文件的方式，可以让用户自定义地更改规则。可以选择关闭这个检查功能，或者更改检查的规则。
  对于类库推荐而言，当需要爬虫时，我们也会让用户自己选择爬虫策略，是选择代码量大的项目，或是star数多的项目、或者是最新post的项目。
  此外，我们对于类库推荐还采取了一个两级缓存的机制。因为每输入一个类库都要爬虫然后处理，效率太低。所以我们将一些常用的类库组成的pair对缓存在数据库中，当用户输入的类库在数据库中能够匹配时，直接输出即可。而当用户输入类库不在数据库中，我们再进行爬虫，并将结果存储在txt文本当中，再使用Java读取。同时，还有一个日志文件，存储用户的输入类库，当某些不在数据库中的类库出现次数频繁时，可以将其从txt文件中读取到数据库中，加快访问效率。
  针对一些异常情况的处理：当用户更改后的配置文件的某些字段不是合法值时，我们输出提示信息，看用户是否输入错误，并利用默认的配置规则进行处理。

4. 心得体会

  之前，我们没有想到这么多的动态变化，即系统没有良好的可拓展性。符号命名的规则是死的，推荐的类库是死的，这限制了用户的使用的自由，就像之前的需求分析我们学习到了不能只把东西展示给用户，而且要告诉用户如何使用我们的东西。而设计分析，就像是在用户使用我们的东西时，我们要告诉用户如何能更好地使用我们的东西，这是我在这两个阶段中系统思维上的很大收获。
  这需要在设计上给予用户很大的自主性，毕竟一千个人中有一千个哈姆雷特，我们不能强迫用户喜欢哪一种，而应该给用户较大的自主选择权，让他自己挑喜欢的功能。这就需要配置文件。并且多级缓存的机制源于计算机操作系统，但如今也随处可见。这些系统设计的小trick为今后的开发也算是积累了经验。
  完善是无止境的，正如达芬奇所说，“没有已经画完的画，只是有的画停止修改”。我想在软件开发领域更是如此，没有已经开发好了的软件，只是有的软件停止更新。