用例模型部分
你没有对你所构建的系统进行一个全面的描述，而且每一个业务用例和用例除了名称以外都没有详细的说明。注意：Rose模型的每一个节点都有备注信息可以录入，这里需要你增加很多有助于你今后工作的描述性信息。关于这个问题的重要性，我上课的时候讲到过。不知道你是否还记得。
你的用例模型绘制得较少，可能和当时了解地不够多有关，不过，今后需要多多注意。同时应该输入一些信息。
你的用例图做了很多的分包，但是每个包下面都只有很少的用例，而且每个包内的用例图并没有绘制出来，所以，这也是一个比较大的问题，希望你能在今后的工作中多多注意。
你的理解的确有一些不太正确。业务用例模型组成的是完整的系统实现的业务层表现，而不是你所说的那种关联关系。所以，你的业务用例图也存在着类似的问题。你仔细参考一下我给大家的例子，思考一下我上课的时候所讲述的内容。
业务用例和用例都绘制的比较完整，但是，却没有看到业务用例图和用例图。
在用例图中，你没有绘制业务用例和业务用例图，有没有考虑过这方面的内容呢？不过没有绘制不要紧，一定要记得还有这么一个过程可以帮助你和用户来完整的获取业务需求。
在你的用例图中，所有用例的comment都没有填写，必要的内容描述是需要的，这样的描述也有助于你整理自己的思路，对系统有一个较为完整的把握。
你的图中出现了借书者与图书管理员之间的直接关联关系，你有没有考虑过这种关系是否应该这样绘制呢？我明白，你是想表达借书者与图书管理员之间的交互过程，但是，这种交互过程应该是一个借阅过程的体现，是一个实实在在的业务流程，你应该将它整理成一个用例，通过业务流程来描述，实现完全电子化的借书流程，不是么？
你的用例图中有一些直接从actor到用例的extend关系，要注意一点，我们这里的actor不是一个外部系统，而是一个人，他和用例之间是不可能存在任何这类关系的。
你的用例图放置在了Logical View中，应该放置在Use Case View中。
你的Use Case Diagram与实际的用例图之间没能关联起来。也就是说，从整个模型的基础图中不能直接一步一步进入你的完整的Use Case Diagram。
你的每一个Use Case都没有填写相应的comment这些说明，这在将来你会感到一些不方便的。填写了这些的内容有助于你进一步理解Use Case对应的业务实现。
在Use case图中，一般来说不需要对Actor划分包，至少在目前这个系统中是不需要的，因为你开发的对象是你的业务用例而不是你的外部系统（Actor）。另外，你的actor包其实没有起到作用，打开这个包后，里面没有任何内容。
用例图中你没有进行分包处理，比如，业务用例图你没有整体收集起来，其他人看到你的模型的时候就会感觉想我在上课的时候举出的那个反例那样，觉得太麻烦了，太复杂了。有可能就会有一种基础的心理来拒绝领会你的内容，一旦用户产生了这种心理，他们将会一直拒绝你给他的任何东西。这点一定要小心。其实任何人都会产生这种畏难心理的。
在Use case view中的Use case realize Model里面，最关键的是用例对业务用例的实现问题，而包对包的实现也不是很关键，因为有可能会存在业务用例绘制在同一个包中，而在用例包中却分开了的现象。在你的这个实现视图中，唯一没有绘制的就是用例与业务用例直接的实现关系。希望你今后能够多多注意。
Use case图中的Use case model里面的Use case图没有绘制出来，仅仅是有Use case的存在。请注意。
由于本系统的actor只能是人，实际过程中，人只能通过一些操作来出发类中的方法，而不是人直接来调用类。所以，你这个方法的调用应该修改成Message to self来表示，人到方法还是：“//选择打牌”之类的描述方式。除非你的系统中的actor是一个外部系统，这时候，才可能出现直接通过接口形成的方法调用。
用例图绘制得很完整。给你提一个醒（不是意见和问题）：在中国大陆做项目的话，无论你的英文多好，在业务用例图上最好都使用中文，也就是说，在任何一个国家开发系统的时候，业务用例图都要使用该国的第一语言来撰写，这样才能达到让用户理解清楚的最好的效果。
你的用例图没有绘制出来，只有业务用例，这说明你的需求部分没有做完。
分析模型时序图中没有从actor开始的动作启动，你的图中的第一个动作来自于entityanalysis类的readgamedata方法。这是不符合逻辑的。要知道任何类都属于被动触发的，没有前置条件他们是不可能自动运行的。所以，动作的起源一定是来源于外部的动作。这一点你在看看我在教学课件中给你们的例子。
在你的用例图中，大部分用例的comment都没有填写，虽然你选择的题目也是大家比较熟悉的内容，不过，必要的内容描述还是需要的，这样的描述也有助于你整理自己的思路，对系统有一个较为完整的把握。另外，你可以把这些说明内容放置在comment中而不是你现在放置的note中。
业务用例中没有actor的出现，这样你如何说明这些业务能给用户带来好处呢？业务必须和actor有关系才可能给actor带来好处。否则，用例图中的actor就是不可能存在的。注意：用例图中的任何东西都是从业务用例图中抽取出来的。
use case view中的所有内容你都绘制了，但是，却没有正确的将他们关联起来，也就是说，从启动图中无法一直索引到所有的相关视图。
在你的作业中，我只看到了业务用例图，却没有实际系统实现的用例图。
在你的usecaseview中，你对所有的用例都做了较为详细的描述，但是，对actor却没有任何描述。注意：Actor的确定也是非常重要的，希望你能考虑一下actor存在的合理性问题。
除了其他actor之外，有一个actor你没有填写注释，就是用户这个actor，除了学生和教师之外，用户是做什么的，那就需要你描述一下了。
你犯了我在课堂上提到过的一个错误：将业务用例与用例放置在同一张图上进行展示，却没有对他们进行区分。建议你回忆一下我课堂上将过的内容。
你的业务用例图中的用例全部都不是业务用例，这点不知道你注意到了没有？一定要注意细节。否则，容易出大问题的。
在业务用例图中仍然存在一些用例，估计你可能是没有讲她们的stereotype全部都设置为business use case造成的。
分析模型
返回值的表示没有采用return message，仍然使用的是Object message。我不记得是不是你用的版本较低的缘故。所以，如果我记错了，你就多包涵一下。
分析模型时序图没有放置在Analysis Model下面。
你的注释方法采用的是"\\"而不是我要求的"//"标示。这一点请注意。
你的分析模型和设计模型采用的方式不同，没有按照统一的方式进行逐层的深入分析并得到结果。不过，这也难怪，我们的课程时间太短，没有时间给你们做更详细深入的讲解。这一点只能让你们自己将来多多学习了。
你的分析类中出了边界类就只有实体类了，这样的话，你的流程控制和跳转就只能在实体类或者界面类中进行实现，这样的方式将会混乱业务层与数据和表现层之间的逻辑关系。希望你能在考虑考虑，尤其是在实际工作中，对比一下不同的方式各有哪些优点。
另外，分析模型中大多数你都直接增加了登陆请求并选择功能，这样的一个操作是否应该可以合并一下呢？放在一个登陆管理中，其他的时序图不就可以简单多了么？
分析模型没有按照我的要求放置在Analysis Model下面，仍然放置在use case view下了。
分析模型时序图没有按照我的要求进行分包处理，因为时间关系，业务流程我没有多做仔细的研究。
在这个模型中没有看到你的分析模型，但是从上次你发过来的作业中看到了你的分析模型时序图的内容，这里面存在着很多我在课堂上已经讲到的内容，你仔细回想一下我在课堂上提到的一些常见问题，自己再动手修改一下你的模型。
你的分析模型我没有找到。包括你的前一次发给我的作业中也没有。你是不是把它直接放置到设计模型中了呢？
你没有区分分析模型和设计模型，这就是你在模型中存在的最大的一个问题，这样会混淆概要设计和详细设计之间的关系的。
你没有很好的按照我所说的步骤绘制分析模型，然后再绘制设计模型。你没有导出代码的缘故是因为你在创建类之前，没有设定语言环境，你可以看一下你的模型的默认语言仍然是analysis language。所以，你自然无法导出代码了。
你的分析模型没有放置到统一的分析模型的目录下，显得有些零散；
分析模型中间出现了业务流的断层，这点需要特别注意。
时序图不要出现跳跃某个类进行返回的现象，实际逻辑/实现过程也都不是这样的。
部分时序图没有做返回。
你在开发分析模型前就选定了开发语言为Java，而不是按照规定在设计模型类开发前在设定开发语言，所以，你的分析模型类中会直接显示出Java方式的属性界面。这是违反常规的。原因我上课的时候讲过，你自己回忆一下。希望在今后的学习和工作中能够多多注意。
你的分析模型和设计模型没有分开来做。
分析模型时序图的柱状流程示意太乱了，应该调整一下。而且，部分返回不是从其方法的延长线上进行的。
你没有绘制业务用例图，这没什么关系，不过，一定要熟悉了解业务用例和用例的区别和用处。
你的分析模型中的方法没有使用我要求的"//"来进行标注。如果此时你选择了具体语言，那么这些就会直接形成类的方法，所以，这就是一种错误。
分析模型中你出现了actor到类的方法调用，这样的直接调用是存在问题的，要注意：由于本系统的actor只能是人，实际过程中，人只能通过一些操作来出发类中的方法，而不是人直接来调用类。所以，你这个方法的调用应该修改成Message to self来表示，人到方法还是：“//选择打牌”之类的描述方式。除非你的系统中的actor是一个外部系统，这时候，才可能出现直接通过接口形成的方法调用。
分析模型中出现了跨越类的返回，这种返回在实际过程中是不可能存在的，不要简化这些过程，还是应该一级一级的进行返回标示。
你在分析模型中没有进行分包处理，这会有一些不良的后果的，自己可以先考虑一下。
分析模型时序图的方法建议采用全中文的描述方式，你现在的做法属于过渡分析，这样会影响到设计时对问题的考虑和解析，不利于多人配合作业，不利于别人理解你对业务的描述。
你没有绘制分析模型。如果你没有听到那一堂课，希望你今后能好好看看我给你们的教学课件，还有一个我给你们做的例子。那里面有完整的分析模型实例。
我知道你希望绘制的是个设计模型，但是这样，我就无法看到你的分析模型了。也就是说，你没有按照我的要求将分析模型放置在应该放置的位置上。请回去再看看我给你们讲课的ppt，考虑一下我为什么要建议这样做。
在分析模型时序图中，有部分流程发生断流，部分方法没有返回。考虑一下，在实际业务过程中，是否可能出现这样的问题。
在分析模型中“//”是注释性的标示，带有这个符号的描述都是注释，不应该在分析类上形成这样的方法。
你构造了很多对象实体，但是，你有没有考虑过对象实体如何做返回呢？因为在对象实体中一般来说是没有获取信息的方法的。在oo的思想中，一般来说是要把对象和操作对象得类进行一下区分，这样才比较合理。你在思考一下，看看是否需要添加一些类。
你没有绘制分析模型时序图的返回内容，考虑一下如何绘制，这是很重要的点。
我没有找到你的分析模型时序图，不过，这不是很关键，但是，你应该了解他的重要性。尤其在一个循序渐进的过程中，应该如何让开发人员进入到最终的设计结果。
分析类应该和设计类分开。你现在这样是不太正确的一种方法。
设计模型
在设计模型中，你的所有的方法都不是从时序图中直接构建获得的，因为你的方法前面都加了“//”；
部分返回仍然使用的是Object Message，这标志着后面的类对前面的类有调用关系，而不是简单的返回关系；
对于多个返回值的方式，在Java中的确用的大都是list或者Arraylist，也可以使用Object Array，不过使用对象数组的方式并不是很方便。当然，具体如何用，还是和各人的习惯有关系。我也不能强求。在设计的时候需要明确指定。
设定成数组类型的时候，你的返回值类型是从你构建的Object中读取的。这个时候，就不能直接从Java常用类型中进行选择，需要从你的构造类型中进行选择。
你没有绘制设计模型时序图，直接导出了类。注意，分析模型时序图中的描述是不能直接用作设计模型中使用的，因为两者的层次不一样。数字化的深度也不同。
在类的comment上面你没有添加类似的说明文字，这都会影响你把东西交给其他人的时候，其他人的理解问题。具体的原因，上课的时候我都讲过了，这里也就不再罗嗦了。
诸如你的类中的方法checkMsg()的返回值设定为void，你考虑一下是否合适。你是通过引用调用呢，还是传值调用的方式来实现这种数据校验的？一般来说数据校验需要返回的是boolean或者int以便于标示出现了哪些数据的错误。
你的设计类划分的并不是过细，应该说划分得不错（当然，我没有时间很仔细得对你的设计模型进行推敲）。你的分析模型和设计模型跨度太大，这是你需要思考得一个问题。这一点比较重要。设计是对分析的细化，这一步细化非常重要，所以，你还需要更多的学习和实践。
你对我后面讲到的J2ee的模式还没有理解到位，不过，这也不能怪你，毕竟你们基本上都是第一次接触这方面的内容。
我知道，你希望形成com.…….……的类包的形式，所以，你重新构建了一个com。在这里实际上是我上课的时候没有讲到的一个点，不过，时间有点太紧，也是没有办法的，一般来说，在实际的工程中，我们都不直接采用Design Model作为包名，直接将之定义为com，以便于形成com.包名.用例名/子包名/类名的形式。
设计模型中我没有看到时序图的存在，所以，也不知道你的类的属性和方法是如何确定的？
你在创建类的时候没有设定语言，你的全过程内的语言都仍然是analysis language。
你在设计模型中直接绘制了类和方法，所有的内容都没有属性，你的思考方式还是完全的过程化的实现方式，没有采用到这门课所讲到的OO的思想，当然，也许是因为你接触这个思想还比较短，还不能真正体会到这个思想的作用。希望你今后能加强这方面的锻炼和实践。
设计模型中的问题较多，你没有开发设计模型时序图，就直接添加了类的属性和方法，加上你没有进行完整的语法检查，或者进行了语法检查也没有检查其中的警告信息，因为你很多类中的方法即没有输入也没有返回，这些都是方法中不允许出现的，这是严重的设计不足的现象。希望你今后能够多多注意。
你的设计模型绘制的过程没有采用这门课所讲述的OO的思想来分析，有时间的话希望你能用这种思想来分析一下。
在你的模型中，直接将数据库作为一个actor来使用了。但是，你有没有注意到：其实你在进行业务分析的过程中还是需要对Actor进行分析，在开发的过程中你还是把这个数据库作为一个对象来处理了，因为你需要在上面开发出一些方法来。所以，在这种情况下，你不能把数据库作为一个actor，而只能作为一个对象来处理。而且，你这里的数据库，实际上应该是一个操作数据库获取数据的类。
在你的设计模型中一些类的方法是必须有输入的，如果没有输入参数，只有输出，这个方法应该如何对外部的信息进行检查呢？
在设计模型中，你没有直接从分析模型获取设计模型的原型基础，而是完全重新绘制了一个。这样的方式，我不建议。详细看一下教案中，我给出的设计模型的绘制过程。
设计模型中你出现了actor到类的方法调用，这样的直接调用是存在问题的，要注意：由于本系统的actor只能是人，实际过程中，人只能通过一些操作来出发类中的方法，而不是人直接来调用类。所以，你这个方法的调用应该修改成Message to self来表示，人到方法还是：“//选择打牌”之类的描述方式。除非你的系统中的actor是一个外部系统，这时候，才可能出现直接通过接口形成的方法调用。
你的GTLoginEntity类不需要再定义为Business Entity类型，应该修改为：entity。
类中方法的返回值等信息也需要进行注明其意义。
设计模型时序图并没有完成，很多仍然带着“//”符号，这有可能是你误会了我当时作业的意思，也不能怨你。这里只是提醒你一下，至少要完成一个完整的时序图，而不是这种还带有注释方法的。
你没有采用这堂课上所学到的OO的思想来进行系统的分析，当然，你们接触这个思想的时间可能太短，这也不能怪你，只是希望你能在今后的工作中能够更多的试图来使用这种思想来分析这些问题。记住：工具的使用只要熟练即可，但是对方法的则必须是精通方可。掌握了方法，使用什么工具都不是大的问题。
你在标示方法的返回时存在问题，方法的返回不应该使用方法的名称来标示，应该实际注明该方法返回的是什么：对象、列表、还是哪一种标准类型……。只有这样才是你考虑完整了，才是你设计中真正需要做到的点。
对于设计模型，应该完成其所有的类、方法、属性的全部描述，包括comment的填写，否则，你的设计实际上就是没有完成。也就不可能拿出来进行实施。
设计模型时序图并没有开发，仍然保持着分析模型时序图的样子；
你在设计模型中也没有选择语言，你的开发语言仍然是analysis language，这是无法进行代码导出的。你导出了代码，你是否给我发错了模型文件？因为你的analysis model下面还应该有一个Control包的。
设计模型时序图很多仍然带着“//”符号，在做设计模型开发的时候基本上是除了返回信息和actor到边界类的引导方法外，其他的都需要去掉注释性符号“//”。
设计模型中部分类中方法的参数和返回值没有填写注释。
你的设计类的名称仍然是中文名称，一般情况下，不建议这样使用。不过，这也不能算错。
你没有开发出设计模型时序图，可能你上课的时候没有注意到我绘制的设计模型的过程。你去看一下我的教学课件中的相关内容。
在你的医院项目中，我没有看到实际的设计模型，我不太清楚你在你的模型中如何从业务流程变成实现模型的。注意，这很关键。否则，模型化开发过程的实现就成了一句空话。
你的有些类有输入没有输出，检查一下吧。这样可能么？这样得类有什么作用呢？
你的设计模型部分的构成情况有些问题不符合正常情况的结构，不过，这个部分的内容因为我课上也没有多做讲述，所以，也不能算作你的错误。
你的设计模型时序图中的各个方法调用有问题，你仍然使用的是中文加英文的方式进行描述，注意：这个时候应该是完全的方法关联，参考一下我的教学课件中的实例。
代码导出
你不是通过时序图来构建类的相关属性和方法的。你导出出错的原因是原来由一些模板提供的东西你没有删除掉，那些是带空格的名字会给导出造成相关的影响。这一点，我在上课的时候演示过。
你导出的类仍然存在警告，不知道你是否注意到了这一点。这是因为部分类中方法的返回值你没有设定。这样的设计是不合格的。导出了类，说明对工具的使用方面，你已经学到了一些内容，但是，如何真正让工具给你带来便利带来好处，这一点是你在今后学习和工作中需要注意的地方。
你的类没有进行语法检查，即使你导出成功了，但是，你的导出并不成功。所以，这一点在今后需要你多多注意。
由于你没有开发设计模型，也就没有能够在设计模型前选择开发语言，所以，你做了大量的方法和属性都无法导出形成代码。这段经历需要你自己今后来完成了。
