UML建模与架构文档化

Posted 2021-04-17 IT 侯

UML（统一建模语言） 是用元模型描述的，元模型是4层元模型体系结构模式中的一层。此模式的其他层次分别是元-元模型层、模型层和用户对象层。

在原模型层，UML元模型 又被分解为三个子逻辑包：基础包（核心、扩展机制和数据模型）、行为元素包（描述模型动态行为的语言上层结构，支持不同的行为图）、模型管理包(定义了对模型元素进行分组和管理的语义)。

UML 通过图形化的表示机制从多个侧面对系统的分析和设计模型进行刻画。它定型了10种视图，并将其分为以下4类：

①、用例图。从外部用户的角度描述系统的功能，并指出功能的执行者。

②、静态图。包括类图（class diagram），对象图（object diagram）和包图（package diagram）

③、行为图。包括交互图（interactive diagram）、状态图（statechart diagram）与活动图（artive diagram）

④、实现图（implementation ）。包括构件图（component diagram）与部署图（deployment diagram）

定义一：用例是对一个活动者（actor）使用系统的一项功能时所进行的交互过程的一个文字描述序列。

定义二：用例是系统、子系统或类和外部的参与者（actor）交互的动作序列的说明。

编写用例必须包含以下元素：

一：角色 - 指系统以外的，需要使用系统或与系统交互的东西，包括人、设备、外部系统等。

二：用例间的关系

用例除了与参与者有关联（association）关系外，之间的关系 - 关系（relationship），如泛化（generalization）关系、包含（include）关系、扩展（extend）关系等

交互图（interaction diagram）

用来描述对象之间以及对象与参与者（actor）之间的动态写作关系以及协作过程中行为次序的图形文档。

1、顺序图 （时序图）：显示对象直接按交互的图，这些对象是按时间排序的。是一个二维图形，以水平方向为对象维。

2、协作图  ：用于描述系统的行为是如何由系统的成分协作实现的图。

类图和对象图

类是具有相似结构、及行为和关系的一组对象的抽象。

一般来说，类之间的关系又关联、聚集（一种特殊形式的关联）、组合（是特殊形式的聚集）、泛化（定义了一半和特殊元素之间的关系）和依赖（假设由两个元素X、Y，如果修改元素X的定义可能会导致对另一个元素Y的修改，则称元素Y依赖于元素X），类图（以直观、抽象形式展示了不同对象之间的关系）

状态图和活动图

1、状态图  UML中的状态图（state chart diagram）主要用于描述一个对象在其生存期间的动态行为。

2、活动图 是对系统的动态行为建模的5个之一，用于描述系统的工作流程和并发行为。可看作状态图的特殊形式。包含几个基本概念：

①、活动 （表示的是某流程中的任务执行，可以表示某算法过程中语句的执行）   ②、泳道（是活动图中的区域划分，根据每个活动的职责对多有活动进行划分，每个用到代表一个责任区）   ③、分支（每个可能的转移是一个分支（branch））   ④、分叉和汇合   ⑤、对象流（可作为活动的输出或输入）  

构件图

构件（componet）：是系统中遵从一组接口且提供其实现的无力的、可替换的部门。

构件图（componentdiagram）则显示一组构件以及他们之间的相互关系、包括编译、链接或执行时构件之间的依赖关系

构件就是一个实际文件，包含（1）部署构件  （2）工作产品构件（deploymentcomponet），如dll文件、exe文件 （3）执行构件，也就是系统执行后得到的构件

部署图

部署图也称配置图、实施图，它可以用来显示系统中计算节点的拓扑结构和通信路径与节点上运行的软构件等。

基于UML的软件开发过程

1、初启  （软件发起项目人确定项目的主要目标和范围）

2、细化 （标志项目的正式确立）

    1）、初步的需求分析

    2）、初步的高层设计

    3）、部分的详细设计

    4）、部分的原型构造

    在细化阶段可能需要使用UML语言机制包括描述用户需求的用例及用例图、表示灵魂与概念模型的类图、表示业务流程处理的活动图、表示系统搞成结构的包图和表示用例内部实现过程的交互图。

3、构建 （开发人员通过一系列的迭代完成所有用例的软件实现工作）

    软件迭代计划用遵循：①、用户认为业务价值较大的用例应优先安排。②、开发人员评估后认为开发风险较高的的用例应优先安排。

4、部署

基于UML的需求分析

• 利用用例及用例图表示需求。

• 利用包图及表示目标软件系统的总体框架结构。

1、生成用例 （从外部用户的视角看，一个 用例 是执行者（actor）与目标软件系统直之间的一次典型的交互作用；从软件系统内部的视角出发，一个用例代表系统执行的一系列动作，动作执行的结果能够被外部的执行者所察觉）

2、用活动图表示用例

3、生成用例图 （执行者与用例之间的关系有两种：触发执行与信息交换）

4、建立顶层架构 （顶层架构的目的主要是为后续的分析和设计活动建立一种结构和划分，以便开发人员在不同的开发阶段，以及同一开发阶段的不同开发人员，能够聚焦于系统的不同部分）

   1）、UML 包图  （包是UML对类进行分组的一种机制，包之间存在两种依赖关系：依赖和构成）

    2）、顶层架构设计

    目前主要的架构模式：（1）、流程处理模式。（2）、客户/服务模式  （3）、分成模式  （4）、架构中包的数量  （5）、架构中包之间的耦合度  （6）、软件系统的稳定性  （7）软件系统的必然性  （8）、作为软件系统运行环境的物理网络拓扑  （9）、开发团队的技术专长

5、建立概念模型

面向对象的设计方法

一、设计用例实现方法

1、设计用例实现方案 （1）、界面控制  （2）、外部接口  （3）、环境隔离

2、构造交互图 （在UML顺序图中：用例的主动执行者在最左侧，紧邻其右的类是作为用户界面的边界类，再往右是控制类，控制类的右侧应防止辅助类和实体类）

3、根据交互图精化类图

二、设计技术支撑方案

三、设计用户界面 （1、熟悉用户并对用户分类 2、按用户类别分析用户的工作流程与习惯 3、设计命令系统并进行优化  4、设计用户界面的各种细节 5、增加用户界面专用的类与对象）

四、计划设计模型（分精化和设计模型）

系统架构文档化

1、“4+1”视图包括：逻辑视图（logical view）、过程视图（process view）、物理视图（physical view）、开发视图（development view）、场景。

2、逻辑架构：设计的对象模型（使用面对对象的设计方法时）。支持功能性需求，采用抽象、封装或继承的原理，用来识别遍布系统各个部分的通用机制和设计元素。

3、进程架构：捕捉设计的并发和同步特征。考虑一些非功能性的需求，如性能和可用性。在几种层次的抽象上进行描述，每个层次针对不同问题。

4、开发架构：描述了开发环境中软件的静态组织结构。用模块和子系统来表达，显示了“输出”和“输入”关系。

5、物理架构：描述了软件到硬件的映射，反映了分布式特性。主要关注系统非功能性需求，如可用性、可靠性、性能和可伸缩性。

6、场景：架构的描述，及所做的各种决定，可以围绕着这四个视图来组织，然后由一些用例(use cases)或场景（scenarios）来说明，从而形成了第五个视图。

我是小侯，我想和大家一起变厉害