UML各种图在系统分析设计中使用，并没有非常精准的要求。
一般都是根据项目情况和分析设计要求而定，比如在系统分析中，最常用的就是以用例图为主，辅助说明需要活动图，类图等。在设计时候以类图为主，辅助以用例图、活动图、序列图、状态图等。
每一种UML图的绘制程度也根据你的业务要求和项目设计程度有所区别。
不一定面面俱到，但是最好能将业务细节设计深入。这样有助于后面工作减少偏差。
设计几个类，用UML类图说明一个 学生借阅图书 系统
原文地址: https://www.cnblogs.com/wolf-sun/p/3413072.html
一、参与者与用例间的关联关系
参与者与用例之间的通信，也成为关联或通信关系。
包含关系（include）
扩展关系（extend）
(1) 概念
包含关系描述的是一个用例需要某种功能，而该功能被另外一个用例定义，那么在用例的执行过程中，就可以调用已经定义好的用例。
(2)表示符号<<include>>
控制台程序
用例图
图书管理员处理借书或者还书时的用例图，借书与还书都要考虑是否有overtime的书。
a.如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用例可以和这个用例建立包含关系（如之前介绍的饮料自动售货机）。
b.一个用例的功能太多时，可以使用包含关系建立若干个更小的用例。（如学生管理系统的用例图）
实例：学生管理系统
注意 ：执行基用例时，每次都必须调用被包含用例。
（1）概念
用一个用例（可选）扩展另一个用例（基本例）的功能。
（2）符号表示<<extend>>
控制台程序
用例图
（3）使用场合
对扩展用例的限制规则：将一些常规的动作放在一个基本用例中，将可选的或只在特定条件下才执行的动作放在它的扩展用例中。
通过上面的例子，怎么区分它们，你心里也有数了，其实在扩展关系中的使用场合也说明了，扩展关系的限制规则：将一些常规的动作放在一个基本用例中，将可选的或只在特定条件下才执行的动作放在它的扩展用例中。在使用的时候，你考虑这点就可以区分它们。
1.包含关系
a.如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用例可以和这个用例建立包含关系（如之前介绍的饮料自动售货机）。
b.一个用例的功能太多时，可以使用包含关系建立若干个更小的用例。（如学生管理系统的用例图）
2.扩展关系
对扩展用例的限制规则：将一些常规的动作放在一个基本用例中，将可选的或只在特定条件下才执行的动作放在它的扩展用例中。
在分析的时候，参考他们的使用场合，你就会豁然开朗......
系列文章
[UML]UML系列——用例图Use Case
基于UML的图书馆借阅管理系统设计（1）系统分析（包括系统描述（问题域描述）、用例模型、分析类图）。
（2）系统设计（包括系统的逻辑模型如设计类图、顺序图、状态图及组件图等）。
（3）系统实施（包括信息代码设计、数据库设计、输入设计、输出设计、用户界面设计和处理过程的设计以及最终的程序设计）。
（4）编制好程序后，设计若干测试用例，上机测试并通过所设计的程序系统。
（5）设计报告格式按附件要求书写。课程设计报告书正文的内容应包括： 1．问题描述； 2．用例模型及分析类图的描述； 3．设计类图、核心用例的顺序图与状态图、组件图等的描述； 4．信息代码设计、数据库设计、输入设计、输出设计的描述； 5．用户界面设计和处理过程的设计的描述； 6．给出软件的测试方法和测试结果。 7．设计的特点、不足、收获与体会。
以上就是关于UML的各种图应该在系统分析，设计的哪个阶段应用全部的内容，如果了解更多相关内容，可以关注醉学网，你们的支持是我们更新的动力！
