从任何一个环节我们都会看到用例，但是仅仅依靠用例本身的图来描述用例是不够的，为什么呢？因为用例它所要描述的是一个场景，换句话说，就是用例是描述了某件详细的事情。如果作为一个场景的话必然要考虑这么几个问题：
考虑这几个问题的话，那我们就可以开始描述我们的用例了，这步工作我们就称为用例描述。
好了，我们针对这几个问题一个个来给出它们的标准定名：
我们来描述“提取商品信息”这个用例（请注意这是系统用例 ）。
参与者：
商品管理员
参与者的意思是，谁在对这个用例进行使用
前置条件：
1. 商品管理员登陆 XXX 系统后拥有能够操作该用例的权限
2. 商品信息的名称、生产日期可以被商品管理员获取作为条件
前置条件的意思是，在怎样的前提下，该用例才有可能被使用。
基本操作流程：
商品管理员输入商品名称和信息-> 系统提取对应的商品并显示所有商品信息
可选操作流程：
商品管理员输入商品名称和信息-> 系统无法根据条件得到对应商品信息，系统提示商品管理员重新输入条件
基本操作流程和可选操作流程的意思是，描述用例中基本的操作步骤和系统的反应结果，以及针对同一操作步骤可能会出现的另一种可能性。
业务规则：
1.在提取商品信息的时候必须满足不能提取“安全锁”类型的商品
业务规则的意思是，在整个用例的场景中，无法在前置条件或后置条件以及基本操作流程和可选操作流程中描述的一些特殊业务规则。该业务规则是隐含的却是必须的。
后置条件：
1. 被提取的商品其状态全部变成“已查看”状态的商品
后置条件的意思是，在用例结束后会产生怎样的一个结果，而该结果可能会对今后的其他用例产生一定的影响。
相关用例：
扩展的用例：打印商品信息、更新商品信息
被包含的用例：获取商品单价
相关用例的意思是，能够在用例的描述中查看到当前用例与其他用例的关系，一般只有直接与当前用例相关的用例才会被作为相关用例，而且需要使用“扩展的用例”和“被包含的用例”来清晰的定义。
这样，我们的系统用例就完成了，虽然很烦琐，但是能够清晰的告之你的客户,你的系统将会做什么，不是一件令人很愉快的事吗？
完成了这一步后，我们接着的工作就需要进入逻辑模型了。逻辑模型对于我们来说，是为了展示这个系统是怎样做的。因此它牵涉到的内容就比较多了。而一般而言，对于逻辑模型，我们通常分为做三步：
Step-1 ：业务对象模型
业务对象模型描述的是现行的业务活动对象之间的关系，是通过从业务用例视图中调研描述的结果以及角色和客户交付的文档中的对象演化而来，通过对象合作来实现。
Step-2 ：分析模型
分析模型属于推进用例的实现，它是在系统用例模型和业务对象模型基础上更进一步的对一个用例的实现说明。它更多的是告诉了我们，针对某个用例，系统会怎样实现。而在这里我们就会引出一个新名词“用例实现”，也会看到“类”。
Step-3 ：设计模型
设计模型和分析模型一样，其实也是告诉了我们针对某个用例系统会怎样实现，只是设计模型更抽象，它已经要求带入了实现技术的概念。
联系客服
