UML软件建模

:beetle:软件开发的本质就是在计算机的虚拟空间中根据现实需求创建一个新世界。

软件建模

软件建模，为要开发的软件建造模型，模型是对客观存在的抽象。

通过软件建模，把握事物的本质规律和主要特征，抽象软件系统的主要特征和组成部分，梳理这些关键组成部分的关系。

在软件开发中，有两个客观存在：

• 要解决的领域问题
• 最终开发出来的软件系统

这两个方面客观存在的抽象，就是软件模型。

4+1 视图模型

这是建模方法论：

• 逻辑视图：描述软件的功能逻辑，由哪些模块组成，模块中包含哪些类，其依赖关系如何；
• 开发视图：包括系统架构层面的层次划分，包的管理，依赖的系统与第三方的程序包。开发视图某些方面和逻辑视图有一定重复性，不同视角看到的可能是同一个东西，开发视图中一个程序包，可能正好对应逻辑视图中的一个功能模块；
• 过程视图：描述程序运行期的进程、线程、对象实例，以及与此相关的并发、同步、通信等问题；
• 物理视图：描述软件如何安装并部署到物理的服务上，以及不同的服务器之间如何关联、通信；
• 场景视图：针对具体的用例场景，将上述 4 个视图关联起来，一方面从业务角度描述，功能流程如何完成，一方面从软件角度描述，相关组成部分如何互相依赖、调用。

软件建模与设计过程可以拆分成需求分析、概要设计和详细设计三个阶段。

UML 常用的有 7 种：类图、序列图、组件图、部署图、用例图、状态图和活动图。

类图

描述类的特性和类之间的静态关系，把相关的一组类及其关系用一张图画出来，主要是在详细设计阶段画。

一个类包含三个部分：

• 类的名字、
• 类的属性列表
• 类的方法列表

类之间有 6 种静态关系：

• 关联、
• 依赖、
• 组合、
• 聚合、
• 继承、
• 泛化

序列图

用来描述各种参与者之间的动态调用关系，可以是类对象，也可以是更大粒度的参与者，比如组件、服务器、子系统。可在软件设计的不同阶段使用。

组件图

组件是比类粒度更大的设计元素，可包含多个类，用途可与包图接近，进行模块设计的时候更多的是用组件图。

组件图描述组件之间的静态关系，主要是依赖关系，用在概要设计阶段。描述组件之间的动态调用关系，可以使用组件序列图，以组件作为参与者，描述组件之间的消息调用关系

部署图

软件系统的最终部署情况，属于宏观层面，软件系统最终物理呈现的蓝图，用在概要设计阶段。

用例图

反映用户和软件系统的交互，描述系统的功能需求，用在需求分析阶段。

• 角色：可以是人，也可以是其他的系统
• 系统：矩形框被称为用例的边界，框里的椭圆表示一个一个的功能，功能之间可以调用依赖，也可以进行功能扩展。

状态图

状态图用来展示单个对象生命周期的状态变迁。一张状态图描述一个对象生命周期的各种状态，及其变迁的关系：

• 在需求分析阶段：描述状态变迁的逻辑关系；

• 在详细设计阶段：状态要用枚举值表示，以指导具体的开发。

活动图

描述过程逻辑和业务流程：

实心圆代表流程开始，空心圆代表流程结束，圆角矩形表示活动，菱形表示分支判断。

活动图引入了一个重要的概念——泳道：将活动根据领域、系统和角色等划分到不同的泳道中，使流程边界更加清晰。

• 在需求分析阶段描述业务流程；

• 在概要设计阶段描述子系统和组件的交互；

• 在详细设计阶段描述一个类方法内部的计算流程。

使用合适的 UML 模型构建一个设计文档

• 在需求分析阶段：
  • 通过用例图来描述系统的功能与使用场景；
  • 通过活动图描述关键的业务流程；
  • 通过时序图描述新系统和原来的子系统的调用关系：在需求阶段就提出要和现有的某些子系统整合
  • 通过简化的类图进行领域模型抽象，并描述核心领域对象之间的关系；
  • 通过状态图描述某些对象内部会有复杂的状态变化。
• 在概要设计阶段：
  • 通过部署图描述系统最终的物理蓝图；
  • 通过组件图以及组件时序图设计软件主要模块及其关系；
  • 通过组件活动图描述组件间的流程逻辑；
• 在详细设计阶段：
  • 通过输出类图和类的时序图，指导最终的代码开发；
  • 通过画方法的活动图，描述方法内部比较复杂的逻辑。