Please enable JavaScript.

Coggle requires JavaScript to display documents.

Thinking in UML - Coggle Diagram

- - - - 怎么建？
        
        抽象的角度不同决定了建模方向的不同，抽象角度即建立这个模型的目的是什么。如果把抽象的角度找全了，并且这些角度都分析清楚了，问题领域也就解决了。
      - 模是什么？
        
        书中有点模糊，也可能是我没有理解
- - - - 特点：
        
        过程稳定是分析的基础
        
        每一部都是预设好的，由严谨的因果关系
        
        无法轻易应付复杂性和频繁变化
        
        数据的完备性和正确性对系统成功至关重要
      - 困难：
        
        如何抽象？为什么要这样抽象，而不是那样？
        
        对象可以任意组合，怎么知道某个组合满足现实世界的需求？如何评价组合的好坏
        
        抽象是面向对象的精髓，也是面向对象的困难所在
      - 认为世界是由一个相互联系的小系统组成的，每个小系统都有着明确的开始和明确的结束，开始和结束之间有着严谨的因果关系
    - - 认为世界是一个独立的对象，相互之间并无因果关系，在某个外力的驱动下，对象之间才会依据某种规律相互传递信息
      - 特征：封装、聚合、继承、接口、多态、依赖、耦合、属性、实例化
      - 困难：当需求变成一个随需应变的商务，这个过程的复杂性已经超出了我们用一个完整过程来模拟的程度
  - - - 现实世界到业务模型
      - 业务模型到概念模型
      - 概念模型到设计模型
  - - - 先启、精化、构建、产品化
      - 工作流程、业务建模、需求、分析设计、实施、测试、部署、配置与变更管理、项目管理、环境
    - - 提高软件成熟度
      - 提高软件技术水平
      - 开发稳定架构，适合长期战略的软件产品
- - - - Actor 还有另一个叫法：主角，系统是以参与者的观点来决定的，参与者对系统的要求，对系统的表述完全决定了系统的功能性
      - Actor 可以非人，可以是另一个计算机系统、一个计时器、一个传感器、或者一个JMS消息
      - Actor 可以非人，可以是另一个计算机系统、一个计时器、一个传感器、或者一个JMS消息
      - Actor 是系统之外与系统交互的某人或某事物，参与者只可能存在于边界之外，边界之内的所有人和事物都不是参与者
    - - 业务主角
        
        业务主角的特殊性在于，他针对的是业务人员而非计算机用户
        
        是参与者的一个版型，所以业务主角必须遵守参与者的所有定义
      - 业务工人
        
        业务工人是被动参与业务的，Actor必须要在边界之外，而业务工人在边界之内
    - - 参与者与涉众
        
        只要和这个系统有利益关系的，都是这个项目的涉众，参与者是涉众的代表，参与者的来源是涉众
      - 参与者与用户
        
        用户是参与者的代表，一个用户可以代理多个参与者，一个用户可以拥有多个职责，可以被指定多个角色
      - 参与者与角色
        
        角色是参与者的指责，角色是一个抽象概念，代表了系统中的一类职责，比如命名一个文件审批者来代表审批文件这一职责