请大家帮忙提提意见
http://www.cjsdn.net/upload/2004/10/09/76254214.jpg
修改入库单的操作
在入库的主窗口中，如果选择修改入库单的操作，先弹出一个模式窗口，输入查询条件，然后查询某一个入库单，查到后，操作者开始修改入库单，最后保存。

思路、流程比较清晰。如果你是做业务分析，有把简单东西复杂化的趋向，建议少用软件行业用语；如果是给开发人员用，你又显得不专业。
个人意见，供参考。

由于有窗体/数据库这些概念出现，我认为你应该是在为程序设计做时序图。

但这样的类设计实在比较罕见，特别是现在大家都愿意把表现层和业务逻辑层分开。在你的图里面也没有业务逻辑方面的任何概念或类，似乎窗体本身就可以承担业务逻辑方面的职责，我认为这不是一种好的设计思想或者思路。

数据库作为一个类出现更是比较难得，因为即使打定主意把所有的SQL都写成存储过程，这么表现也相当古怪。

我似乎见过你的名字，而且给你写过回复，如果我没记错的话。
综合看前面你的问题，我个人的看法是，你对面向对象、OOAD、OOP的概念并没有正确的建立起来，虽然你知道如何用ROSE画各种diagram。

我曾经见过一种更极端的做法，一个刚刚学习OO编程不久的程序员在讲解自己的设计的时候说到，他设计了一个公共类叫做Tools，这个类中所有行为都是Public Static，这样大家都可以自由的调用这些方法——这样的最终结果是达到了类似结构化编程时子程序的功能，他用的一切工具都是OO的，唯独思想不是。
　

你好，这个图是我在做需求分析阶段时设计的，看了你的回复后，我觉得这个图可能还有大的问题。但是在需求分析阶段时，就要有表现层和逻辑层吗，因为这个需求分析一般情况下是给客户看的，我想如果在系统设计时再体现出这种关系应该没有问题吧。
另外我希望您能就我的这个流程给我画一下这个时序图。谢谢。

这个图是需求分析阶段的产物，主要是给客户看的。谢谢回复。

1、如果你和客户都认为不需要实现三层结构，那你这么设计的主要思想并没有错误，C/S模式是可以这样实现的，当然你的“数据库”那个类，要改成数据库接口或数据库操作类。

2、“需求分析阶段”这个词：如果你用典型的OO方法，比如RUP、XP等，那么这个阶段本身就不存在，初始、细化、构造这些阶段和传统的需求分析、系统分析、设计并不是一一对应的关系，只能说在一个迭代周期中存在相似的这些过程。
这样就会存在一个问题：你希望使用OO作为分析设计的主导思想，但并不希望用经过实践证明可行的OO实现方法，不使用迭代开发的理念，那么OOAD在你的开发过程中就不会给你带来什么实际的帮助，这是我个人的看法。

3、当然存在一种可能，即客户要求你用OO的表达方式，同时要求你按照类似瀑布式的方法去开发，也就是说，要求你有明确的需求分析、系统分析等阶段，但在这些阶段中，必须提供相应的OO文档。
这种情况，我想你应该已经和客户达成某种协议，包括在各个阶段使用什么文档产品进行沟通，目前我感觉似乎需求分析阶段，对方要求有用例模型和顺序图，但不知道是否正确？
如果确实如此的话，用例模型应该包括用例图和完整的用例文档。顺序图可以作为辅助，且在图中只要两个对象就可以了，一个是Actor,一个是你要设计的系统，你没有概念视图也没有类图，顺序图中的那些类就不该凭空产生。
以我个人的经验，需求分析基本上只需要用例，有时会需要活动图（活动图表现需求比顺序图更方便一些，且更容易理解），前提是你要表达客户的需求，而不是进行设计。

4、当你已经做出了顺序图，而且其中已经有了很多类和对象，那么你实际上是在做设计了，你是在用顺序图作为工具，分析你定义的类所拥有的职责。当然如果客户认为这就是需求的一部分也没有什么不可以，毕竟他是客户。
不过，这种顺序图，特别是你做的顺序图本身虽然没有问题，但顺序图中的各个类是在什么阶段、什么时候抽象出来的呢？你的类图又在什么地方呢？

5、你可以将以下OOAD的过程作为参考：
a、完成用例模型，包括图和文档
b、对于过程比较复杂的用例，用活动图辅助描述
c、根据用例文档和活动图，分析领域概念，做成概念模型
d、分析概念模型，抽象出类
e、分析类的基本职责，做出初始的类图
f、根据类图，制作顺序图/协作图/状态图等等
g、重复e-f两个步骤，完善类的行为和属性，以完善类设计
h、实现类的代码，完成程序设计
i、测试并修改程序
j、实施部署，并和客户一起测试
k、以实施和测试的反馈推动下一个迭代

最后一步完成后，可以说完成了一次迭代内的全过程，如果你不用迭代开发，那么项目完成了。
　

十分感谢。我以前一直都是做编码的，这是第一次用UML做分析设计，感觉还有很多地方不是很明白，不过你的贴子对我的启发很大，再次感谢。

但也有人告诉我也可以直接设计时序图。

兄弟，还是要自信点。其实，好与不好，要具体情况具体处理。如果你的图是需求分析用的，也还基本可以，尤其是客户是计算机“专家”时。在最新的UML版本中，也支持在需求分析阶段用时序图。
研究技术可以讲完美，但实际工作要讲效果。如果是做商业项目，一般要求要把需求界定清晰。那么，这时是不是就不能用OO喃？非也，在瀑布模型的思想中，一样可以叠代，但配置管理就很重要了。
另外，学习OO时，可以严格区分其与结构化的差异。个人认为，在实际工作中，他们可以集合的。如果你研究以下EJB的思路，可能会发现他们的结合是那么的美丽。
总之，实际工作不同于理论研究，能做好工作就好，千万不要为了OO而UML啊，那样，你才可能用好UML。
个人意见