UML学习总结

顺序图包括四个元素：对象、生命线、激活、消息。如果说分为两部分那就是对象和消息。
​
    顺序图作用：细化用例的表达、有效的描述类职责的分配方式、丰富系统的使用语境的逻辑表达。
​
从左至右对象位置：主要参与者、边界、控制对象、实体对象、其他参与者。
​
表示方式：
在这里插入图片描述
被置于顶端的对象意味着在开始交互之前就存在了，不在顶端的对象意味着中间过程中创建出来的，可以被接下来对象的消息激活也可以被销毁。
​
生命线：在生命线代表的时间内，对象一直是可以被访问的。显示为一条垂直的虚线，与时间轴平行。
​
激活：又叫做控制焦点，表示一个对象执行一个动作所经历的时间段。在uml中用细长的矩形表示，显示在生命线上。
​
消息：最常见的是简单消息，对消息的接收往往产生一个动作，动作有调用、发送、返回、创建、销毁。
​
调用（call）：属于同步机制，表示为实心三角箭头
​
返回：虚线箭头
​
创建：使用具有<>构造型的消息表示
​
销毁：使用具有<>构造型的消息表示
​
消息可分为：同步消息、异步消息，同步指事物之间非并发执行的状态，一般需要一个事物停止工作等待另外一个事物工作的完成。
​
片段：
​
        可选片段：opt，单条件分支：满足条件则执行。
​
        条件片段：alt，多条件分支：根据是否满足条件而做出不同的决策时，可以在条件执行的片段内部使用虚线隔开不同区域。
​
        并行片段：par，每一个子片段并行执行，消息顺序不确定。
​
        循环片段：loop，只要条件满足就一直循环，直到循环条件为假，跳出循环。
​
        交互片段：ref，引用其他交互图

thinking uml大象
​
1 聚焦问题领域。
2 从问题领域中找好抽象角度。用例
​
问题领域 = ∑上n下1抽象角度
抽象角度 = 问题领域边界之外的参与者的业务目标 = 业务用例
业务用例 = ∑上n下1特定场景
用例=n*特定场景(用例)=事务+动作+人物 
​
抽象层次：
在软件开发过程中，主体上应当采用自顶向下的方法，用少量的概念覆盖系统需求，再逐步降低抽象层次，直到代码编写。同时应当辅以自底向上的方法，通过总结在较低抽象层次的实践经验来改进较高层次的概念以提升软件质量。现在请读者回忆一下建模公式，公式中所表达的也是一个自顶向下的方法。如果你在做设计或分析的时候总是觉得信息之间的关系太复杂，总是难以理清头绪，你需要思考一下是否不适当地采用了自底向上的分析方法。
​
​
参与者 对系统有着明确的目标并主动发出动作。
    系统功能为参与者服务。

OOA/D
​
ooa 分析阶段主要解决以下问题
-- 建立针对业务问题域的清晰视图
-- 列出系统必须要完成的核心任务
-- 针对问题域建立公共词汇表
-- 列出针对此问题域的最佳解决方案
这个阶段要解决的核心问题是“what to do?”
​
ood
设计阶段主要解决以下问题
-- 如何解决具体的业务问题
-- 引入系统工作所需的支持元素
-- 定义系统的实现策略
此阶段要解决的核心问题是 "how to do?"
​
需求分析与用例
需求：就是系统（或者说项目）必须提供的能力和必须遵从的条件。
需求分析的一种重要手段是：确定和编写用例。 （需求分析从用户角度看待问题）
​
面对需求常常发生变化我们应该如何面对？
    变化的原因：开发软件的人不是系统的最终用户，开发人员不具备业务知识。
    解决方案：从用户角度思考用户的需求（这也是用例中参与者存在的原因），不断尝试修改。
用例的定义：
    用例是文本形式的情节描述（这些情节描述就是场景），用于需求的发现和记录，用例会影响后续的OOA/D工作。（对功能性需求的描述）
    场景：主成功场景  成功的情况下达到什么效果
         交替场景   成功情况下达到什么效果，失败情况下达到什么效果。
    详细的描述用例应包括这两种场景。     
    
    用例，强调用户的目标和观点。
    谁使用系统？(参与者)使用的典型场景是什么？要达成什么目的？
    用例的编写形式
          摘要 - 需求分析早期使用，通常用于主成功场景。
         非正式 - 需求分析早期使用，可覆盖不同的场景。
         详述 - 详细编写所有步骤以及各种变化。
     用例的名称要用动词开头。
    编写用例的时候应尽量使用行业的专业名称，而不是计算机专业术语。
参与者
    在系统之外与系统交互的某人或某事物.
    找出参与者需要先明确系统边界，参与者只存在于系统边界之外。
■ 谁对系统有着明确的目标和要求并且主动发出动作？■ 系统是为谁服务的？
​
代表了功能性需求的用例有一个特征是“不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例”。这说明没有人参与的需求一定有别的事物在发出启动的动作，应当找到这个事物，这个事物就是一个参与者，它可能是另一个计算机系统、一个计时器、一个传感器或者一个JMS消息。总之，任何需求都必须至少有一个启动者，如果找不到启动者，那么可以肯定地说这不是一个功能性需求
​
场景 参与者和系统之间的一些列特定的活动和交互。
用例 就是一组相关的成功和失败场景的集合。
    （英语：use case），或译使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。
用例驱动  分析实现部署都要依据用例来进行
​
用例图 概要请阅读 https://www.cnblogs.com/gd-luojialin/p/10356704.html博客
用例的编写
​
1 用例编号
2 用例名
3 用例描述
4 参与者
5 前置条件
6 后置条件 （主成功场景）
7 基本路径 （交替场景）
8 扩展点
9 补充说明
​
如何寻找用例
1 选择系统边界，从不同角度具体事情具体分析。
2 确定主要参与者
3 确定每个主要参与者目标
4 定义满足用户目标的用例，根据其目标对用例命名
​
状态图 用来描述一个特定对象所有可能的状态，以及由于各种事件的发生而引起的状态之间的转移和变化

影响系统开发进度的原因
 需求缺乏，需求不明确，理解需求有偏差，需求不断变化都是影响系统开发的原因。也是我们工作无限返工的原因。
 
 需求的重要性
    在需求不明确，或理解需求有偏差的情况下进行开发开发出来的功能有可能不是客户想要的这时候客户会无限·的去修改导致工期拖延反复反攻。所以说在开发之前一定要理解需求。有了需求，我们才有目标，才能根据需求对软件进行测试，才能向客户证明我们已经达到了这个目标。
    使用用例图是从用户角度了解需求的一种重要工具，是需求建模的常见工具。
用例图包括以下3方面的内容。（1）参与者。（2）用例。（3）依赖、泛化和关联关系。
在获取用例前首先要确定系统的参与者，可以根据下面的一些问题来寻找系统的参与者。（1）谁使用系统？（2）谁安装系统，维护系统？（3）谁启动系统，关闭系统？（4）谁从系统中获取信息，谁提供信息给系统？（5）在系统交互中，谁扮演了什么角色？（6）系统会与哪些其他系统相关联？
​
【用例是对一组序列动作的描述，系统执行这些动作将对用例的角色产生可以观察的结果】。在图形上，用例用实线的椭圆表示，如图2.1.4所示。角色和用例分别描述了“谁来做”和“做什么”这两个问题。识别用例的最好办法就是从分析系统的角色开始，考虑每个角色是怎样使用系统。在这个分析过程中，可能会找出一个新的角色，这对完善整个系统的需求建模很有帮助。用例建模的过程就是迭代和逐步求精的过程：从确定用例的名称开始，然后添加用例细节信息，最后完成完整的用例规格说明。
​
那么，如何从系统需求分析中提取出用例呢？可以根据下面的一些问题来识别用例。（1）角色希望系统提供什么功能。（2）系统是否存储和检索信息。（3）当系统改变状态时，是否通知角色。（4）是否存在影响系统的外部事件，是哪个角色通知系统这些外部事件。
​
​
根据需求分析作出用例后，并不是一切就万事大吉了，还需要对用例的正确性进行分析。错误的或描述不清的用例可能会导致错误的需求分析，并把我们的设计实现工作带入歧途。如何判断一个用例是否是一个优秀的用例呢
​
（1）用例是否描述了应该做什么，而不是如何做？用例应该描述系统做什么，但不应该描述系统是如何被实现的。（2）用例的描述是否采取了角色的视点？在确定用例的关键特征时，应该依据角色的视点。也就是说，应该从角色如何使用系统的角度出发定义用例，而不是从系统自身的角度。（3）用例是否对角色有价值？用例不是动作步骤的任意集合，它必须为角色提供可辨识的价值。（4）用例描述的时间流是否是一个完整场景？每一个用例必须描述出在一个给定场景下角色将如何使用系统的完整事件流。这有助于避免产生单步用例、部分用例或者功能分解用例。（5）是否所有的角色、用例都有相应的关联用例或关联角色？每个用例都需要明确地解决角色相关的问题，这个原则对于检查用例的合理性很有用。每个用例都必须至少有一个角色与之相关联，否则就新增加一个角色，或者删除该用例。某些用例间是否有相似性，如果有引入包含关系；某些用例间是否有特殊情况，如果有引入扩展关系。最后，评价用例的划分是否适当的一个方法是计算用例的数量。识别用例一方面要从系统的功能需要中抽象出用例，同时还要控制用例的数目。用例数目过多则造成用例模型过大，同时设计系统的难度也加大了，用例数目过少则造成用例描述得太粗犷或不充分，不便于进一步分析。
​
用例图 ： 用例图的主要作用是描述角色和用例之间的关系，简单的系统中只需要有一个用例图就可以把所有的关系都描述清楚，复杂的系统中可以有多个用例图。
如果想要强调某一个角色和多个用例的关系，就可以以该角色为中心，用一个用例图表述出该角色和多个用例之间的关系。在这个用例图中，我们强调的是该角色会使用系统所提供的哪些服务。
​
用例图与事件流 ： 用例图使我们对系统的功能有了一个整体的认知，我们可以知道有哪些角色会与系统发生交互，每一个角色需要系统为它提供什么样的服务。用例描述的是角色与系统之间的对话，但是这个对话的细节并没有在用例图中表述出来，针对每一个用例我们可以用事件流来描述这一对话的细节内容。
这样描述一个用例就可以
1 用例编号
2 用例名
3 用例描述
4 参与者
5 前置条件
6 后置条件 
7 基本路径 （主成功场景）基础事件流
8 扩展点  （交替场景）  备选事件流
9 补充说明
​
【用例：用例是对一组序列动作的描述，系统执行这些动作将对用例的角色产生可以观察的结果。】
用例描述的是系统外部可见的行为。从原则上来讲，用例之间都是并列的，它们之间并不存在着包含从属关系。但是从保证用例模型的可维护性和一致性角度来看，我们可以在用例之间抽象出包含（include）、扩展（extend）和泛化（generalization）这几种关系。这几种关系都是从现有的用例中抽取出公共的那部分信息，然后通后过不同的方法来重用这部分公共信息，以减少模型维护的工作量。
​
用例关系的作用就是，将现有用例中的公共部分抽取出来然后通过不同的方法来重用这部分公共信息，以减少模型维护的工作量。
泛化关系：泛化关系在图形上使用带空心箭头的实线表示，箭头由子用例指向父用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系，还可以添加自己的行为或覆盖已继承的行为
​
包含关系：包含是指基础用例（base use case）会用到被包含用例（inclusion），具体地讲，就是将被包含用例的事件流插入到基础用例的事件流中。被包含用例是可重用的用例──多个用例的公共用例。包含关系在图形上使用带箭头的虚线表示，箭头由基础用例指向包含用例。
    例 ： 删除订单用例 包含查找订单用例  再删除时会直接调用查找不存在条件的引用。  被包含的拓展流直接插入到基础流中。
    有时当某一个用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
    
拓展关系
扩展关系也是关联关系的一种。假设基础用例中定义有一至多个已命名的扩展点，扩展关系是指将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。如果基础用例是一个很复杂的用例，选用扩展关系将某些业务抽象成为单独的用例可以降低基础用例的复杂性。扩展关系在图形上也是使用带箭头的虚线表示，只是箭头由扩展用例指向基础用例。基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。事实上，基础用例没有扩展也是完整的，一个扩展用例反而改变了基础用例的事件流。扩展用例的行为是否被执行要取决于主事件流中的判定点。如果特定条件发生，扩展用例的行为才被执行。值得注意的是扩展用例的事件流往往也可以抽象为基础用例的备选流。
    （1）相对于基础用例，扩展用例是可选的，而包含用例则不是。（2）如果缺少扩展用例，基础用例还是完整的，而缺少包含用例，则基础用例就不完整了。（3）扩展用例的执行需要满足某种条件，而包含用例不需要。（4）扩展用例的执行会改变基础用例的行为，而包含用例不会。
    总结起来就是说：相对于基础用力来说拓展用力是可选的当条件成功时拓展用例的事件流会插入到基本用例中基本用例中的行为会因为插入的这段事件流改变而包含关系不会它本身就是基本用例的一部分。缺少拓展用例基本用力可以单独存在，缺少包含用例基础用例也不完整。  
    需求分析
    1 确定边界划分系统的参与者
    如何找参与者就是上述的几个问题
    2 确定用例
    如何找用例就是上述的几个问题
    3 确定用例的正确性。
    4 对用力功能做出总结 给功能划分分类  如客户端功能，服务端功能...
    5 根据分类按照分类划分去编写用例描述
    6 画出用例图可以与5同步进行
    这样可以明确的描述出各个功能分类包括什么个个分类的作用。

活动图：
​