UML分析

最新推荐文章于 2024-02-19 08:00:00 发布

原创最新推荐文章于 2024-02-19 08:00:00 发布

· 471 阅读

0 ·

版权

文章标签：

#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、模块级别顺序图中的每一次交互，又可以拆出一个模块需求。
需求分析时，先用流程三剑客将最长路径打通，是非常重要的分析方法。后面再考虑分支流程。