UML里用例图（User Case）和类图（Class）的关系

Question

我现在碰到一个问题不是太明白，比如系统里有两类角色，操作人员和管理员，管理员可以增加修改删除操作人员，在用例图里，管理员有个行为是“添加一个操作人员”，但这个方法如果反应在类里的话，是在操作员类里的。
简单地说，是A操作B，是A的行为，但是归于B类，这应该怎么解释？

Answer 1

A的行为，B的状态改变。B要写服务让A调用

Answer 2

https://quanke.gitbooks.io/design-pattern-java/%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1%E8%AE%BE%E8%AE%A1%E5%8E%9F%E5%88%99.html单一职责原则 (Single Responsibility Principle, SRP) 一个类只负责一个功能领域中的相应职责
开闭原则 (Open-Closed Principle, OCP) 软件实体应对扩展开放，而对修改封闭B 的状态改变，应该在自己内部解决；增加操作员是对操作员的修改，对修改要封闭

Answer 3

用例图（User Case）主要用于需求分析阶段做用户需求分析的，主要是已角色actor为主，阐述其应具备的功能use case。
类图（Class）主要用于涉及（概要、详细设计）阶段，主要阐述了程序的结构。
也就是说 用例图 对 类图 的设计具有指导意义，但是注意并没有严格的规则说用例图可以和类图中的元素一一对应。
----------------------------
例子中：A操作B对象的用例，实际在实施过程中往往会建立两个实体类A和B，然后再建一个Service类，这个用例使用这个Service类的具体方法来实现。
具体这个Service类叫AService还是BService就需要根据具体业务来定了

Answer 4

我自己的原则是，如果A的用例不涉及其他角色，那么就把他设计为A的public的方法，如果涉及到其他类的话，新建一个Service类来实现。

Answer 5

针对数据库的编程不需要在类图上面花功夫。
因为你设计的类越复杂，持久化的成本就越高。
所以直接考虑用例和E-R图更简单实用。
类的话按数据结构和页面结构设计即可，不要把业务操作绑定到类上。
针对不用的业务设计service和dao接口，完成对DTO对象的持久化即可。所以管理员的行为添加一个操作人员，设计成一个Service即可，在service中考虑业务。
你纠结的问题根本就不应该存在。