UML分析

UML

UML图

目的

• 表达静态概念，以及它们之间的关系

  • 结构图

• 表达动态内容

  • 行为图三剑客

• 表达能为用户做什么

  • 用例图

分类

• 结构型-静态

  • 类图

    • 用来分析业务概念及他们的关系

    • 需求分析阶段

      • 只管属性，不管方法，属性也不用管public或者private
      • 只需要标注关键的属性
      • 组合和聚合，可以这样记忆：实心菱形显得更强壮，是强包含。但是一般需求分析时，不用太纠结他两，统一用弱包含
      • 如果你发现两个类有关系，就先连上一根线。如果你在写两个类的属性时，发现有些属性需要协商才能确定、或者是通过一个记录（比如合同、订单）来管理，则说明他们中间会有一个关联类。
      • 需要抓住原生属性，就是不能由其他属性导出的属性
      • 重要的类别或者状态，既可以是作为属性，也可以作为一个枚举类，主要还是看起重要程度，在需求描述的时候，类图不一定要完全和数据库设计一样，重要的是表达清楚。

  • 部件图+部署图

    • 用来描述基础架构

• 行为型-动态

  • 状态机图

    • 围绕一个事物的状态变化来考虑

    • 状态的变化的写法：主动宾

    • 合适的状态划分，是状态机的难点

      • 只有抛开其他外力，仍能持续存在的，才能称为状态
      • 有时候我们通过认知觉得有两个名词，但是他们内部之间没有动作，后续流程也是一样的，就可以把它们当做一个状态。比如当前领导已审批和等待下一级领导审批，就可以合并成一个状态

  • 顺序图

    • 强调先后顺序，相对活动图而言，适合表达高层次、不复杂的概念性交互

    • 动作的标准写法有两种

      • 发起线一般是动宾。注意，因为顺序图中一定有发起方和接收方的生命线，所以一定是由主语和宾语的。而此处动作里面的宾语，其实起到双宾语的作用。比如：A送B花。
      • 返回线一般只要宾语就可以了

    • 顺序图中不适合一板一眼用方框表达分支和循环，最好在旁边用注解来表达。所以如果一般分支比较重要，适合用活动图而不是顺序图

  • 通信图

    • 顺序图的另一种画法，强调相互之间的关系

  • 活动图

    • 每一个步骤的标准写法是：主动宾
    • 只要表达准确，不太好画的地方可以用注解来写，不一定要一板一眼
    • 活动（方框左右是半圆）可以再细分、动作（方框只是倒了圆角）不能细分。一般只用活动就行。而标准的矩形是交付件。一般核心的原则就是，活动图中的活动，尽量属于同一个层次
    • 画图顺序是先画出正常流程，然后逐步增加分支流程以及异常流程。
    • 核心是提炼流程，而不仅是把现实情况表达出来就可以了。需要在图中提炼出你的想法、你的解决方案。比如：XX流程是由XX人签发、不允许XX流程和XX流程一起进行等。
    • 不要想一个活动图表达很多流程，可以考虑画多个活动图

  • 用例图

    • 标准写法：动宾

    • 画好用例图的关键，是从角色入手，思考他们需要什么

    • 系统中的CRUD用例，如果没有特殊要求，可以统一使用”管理XXX“来替代，避免每次画4个用例。

    • 关联关系

      • include

        • 被include的相当于一个可复用的单元

      • entend

        • 被extend的相当于是include的基础上，必须要执行的前提条件

      • 继承

        • 被继承的是一个抽象名词，并不真正存在该用例，只是为了表达一种同类关系，一般很少使用

需求分析

什么是需求

• 给客户带来真正的价值才是我们的任务，而不是盲听客户的要求
• xxx系统本身并不是需求，只是一种解决方案

需求的层次

• 需要

  • 不太会变
  • 包括：背景、待解决的问题、关键涉众、目标、项目的成功标准、范围

• 需求规格

  • 经常会变
  • 包括：功能性需求、非功能性需求

需求分析

• 如果从管理上解决不了的问题，是没法通过IT化解决问题的。

• 信息系统一个大弊端是不够灵活，很难应对各种突发情况。而处理各种突发情况的办法不是让系统更强大，而是说提供一些预案，方便手工处理

• 整个需求分析的流程是螺旋上升的

  • 1、画系统级别的涉众的顺序图
  • 2、涉众顺序图中的每一次交互，都可以拆出一个用例需求
  • 3、单个用例需求可以画出模块级别的顺序图
  • 4、模块级别顺序图中的每一次交互，又可以拆出一个模块需求。

• 需求分析时，先用流程三剑客将最长路径打通，是非常重要的分析方法。后面再考虑分支流程。

一些坑

• 但凡涉及导入数据的，都会涉及新数据和旧数据的冲突，需要妥善处理这些数据会很麻烦。
• 进行需求变更时，一定要分析清楚变更的层次，是需要级别，还是需求规格级别。然后再分析出涉及的依赖关系，才好判断。
• 需求需要持续地与客户确认，而且要签字，签字不代表不变了，而是说到这个节点，大家达成了一致

与敏捷的关系

UML中的产品愿景，就相当于敏捷中的用户画像

用户故事地图的横向是软件功能的分类，纵向是功能的情况。本质上是相当于版本计划。版本计划的核心是每次都形成最小可用产品，而不需要把每个模块都做完。

UML系统顺序图中的每一条交互，可以提炼出一个或多个用例或者用户故事。用例图和用户故事基本是等价的，只是表现方式不同。