用户向系统中输入课表模板、课程信息以及教师责任信息，系统以某种格式输出每个班级的课表。该用例中的主要参与者包括用户以及系统，除了上述两个主要参与者外，我们从该用例中抽取出可能有价值的名词：课表模板、课程、教师职责、班级以及课表。现在我们只知道下面图示的关系：
在上一篇的界面需求描述部分，我们已经确定了用户输入数据的媒介以及格式，课表模板描述了一个班级的课表中那些位置是固定不变的，那些是可以被分配的，不妨留意一下这里的位置这一名词，位置是由两个信息决定的，本别是星期以及节次，可以观察到，这样一个个位置是课表的基本组成元素，为了方便接下来的表述，我将这样一个个位置称作节点，每个节点都包含两个属性：星期和节次。联系现实生活，如果每个节点仅仅包含星期和节次这两个属性，该节点在某个具体的班级课表中将拥有唯一的位置，而当将该节点放在整个年级的课表中看，该节点就不再具有唯一性，其余的每个班级都会出现于此节点属性相同的节点，所以，如果我们要确定一个唯一的节点，就需要给每个节点添加一个班级属性。节点本身包含了时空两个维度的信息，在时间上包括星期和节次，在空间上是指班级。到此为止，我们发掘出一个可能具有极大价值的对象——节点。
用户输入的课程信息表包括课程名、周次（该课程每周的上课次数）以及优先级（该课程的排课优先级）这三个重要的信息，这样我们就可以初步确定了课程这一对象以及其属性。另外还有一些隐含信息。在课程集合里，所有课程对象的周次属性的值的累加和与前面提到的课表模板中可分配的节点的总数存在关系，即每个班级中可分配的节点的总数等于所有课程周次属性值的累加和。每个课程对象都包含优先级属性，这意味着这个课表集合可以根据某种方式变成有序集合，这与前文的分级填充功能需求息息相关。
接下来我们再看用户输入的第三张表——教师职责信息表。该表描述了每个教师应该在哪个班级中承担哪一个学科的教师身份，上过公立小学的都知道，几乎每个小学教师都承担着多重角色，比如教师A的主要教学科目是数学，但他同时也是这个班级的科学老师，甚至是体育老师。通过这张表我们可以抽离出教师这一对象，该对象拥有的属性包括两个集合，分别是班级集合以及科目集合，这代表每个教师教授多门科目同时在多个班级授课，这种结构不太讨人喜欢。
通过上面的分析，我们发掘出三个可能具有极大价值的对象：
除此以外还有一些不太被关注的名词，包括班级、课表、职责……另外在上文中并没有谈及对象之间的交互动作，自然也就无法形成用例图。当用户将以上数据输入系统后，用户就完全失去了系统的控制权，接下来的一切动作都是系统内的动作，具体是什么动作取决于排课的算法以及领域分析过程中确定的具有行为的对象。
为了发掘更多具有潜在价值的对象，我们将视角转向功能需求上。需求一（无时间冲突）描述了在某一时刻（同一天的同一节次）一个教师不能被分配到两个或两个以上不同的班级。该需求涉及到的对象包括节点和教师。这句话的含义是一个节点只能容纳一个教师，而不是容纳一个教师集合。我们可以把教师作为节点的其中一个属性。需求二（分级填充）主要强调课程的优先级这一属性在排课过程中的实际意义。需求三（完整性检测）强调课程的周次这一属性的实际意义。需求四（非连续性分配）强调同一天内、同一个班级中同一个课程的分配情况。需求五（均匀分配）强调同一周内、同一个班级中同一个课程的分配情况，这一需求似乎应该和上一个需求合并在一起。从以上需求中似乎没有发现什么有价值的对象。
分析到现在，我甚至有些怀疑采用面向对象的方式处理这个问题是否合适？到目前为止我都没有将上述对象有效的关联在一起，他们之间的关系依旧是模糊的。或许在接下来的设计阶段会发掘出更有价值的结构吧，到这里，我要结束这篇随笔了。
