1、可视化建模基础

​ 模型是对现实世界的简化。一个好的模型包含了人们需要关注的主要元素,而忽略那些不相关的次要特征。例如，一架飞机是由成千上万个部件组成的,我们很难一次性完整地描述这样的一个实物,为此设计师需要通过不同的视图（如主视图、俯视图、侧视图、仰视图等）表示该飞机不同的方面。而这些视图就是对飞机这个现实世界实物的简化,就是模型。

​ 在软件世界中,模型就是对目标系统进行简化,提供系统的蓝图。模型可以仅列出系统高层的组织结构,也可能包含各个组成部分的细节信息。每个系统都可以从不同的方面分析构建不同的模型,可能是静态的结构,也可能包含动态的信息。

建模的重要性

image-1673793828596

1.1 建模的目的

  • 建模的根本目的是为了更好地理解待开发的系统

    • 模型有助于按照所需的样式可视化(Visualize)目标系统
    • 模型能够描述(Specify)系统的结构和行为
    • 模型提供构造(Construct)系统的模板
    • 模型可以文档化(Document)设计决策

  • 建模过程需要遵循的原则

    • 选择合适的模型：所创建的模型对解决方案的形成具有重要的影响
    • 模型具有不同的精确程度：面向不同的用户提供不同抽象层次的模型
    • 好的模型是与现实相联系的：简化不能掩盖掉任何重要的细节
    • 单一的模型是不够的：需要从多个视角创建不同的模型

2、统一建模语言

  • UML — Unified Modeling Language

  • UML是一种标准的图形化建模语言，是面向对象分析与设计的标准表示，它：

    • 不是一种程序设计语言，而是一种可视化的建模语言(用于分析设计)
    • 不是工具或知识库的规格说明，而是一种建模语言规格说明，是一种模型表示的标准
    • 不是过程，也不是方法，但允许任何一种过程和方法使用它

  • Unified Modeling Language（统一建模语言）是对象管理组织（OMG）制定的一个通用的、可视化的建模语言标准，可以用来可视化（visualize） 、描述（specify）、**构造（construct）和文档化（document）**软件密集型系统的各种工件（artifacts，又译制品）

2.1 选择UML

使用UML

  • 1）OO（Object-Oriented）方法是项目决定采用的方法论，是整个项目或产品成功的关键
  • 2）开发人员感觉用源码说明不了真正的问题，希望提高交流效率
  • 3）系统的规模和设计都比较复杂，需要用图形抽象地表达复杂概念，降低开发风险
  • 4）组织希望记录已成功项目、产品的设计方案，在开发新项目时可以参考、复用过去的设计
  • 5）有必要采用一套通用的图形语言和符号体系描述组织的业务流程和软件需求，促进业务人员、开发人员之间一致、高效的交流

不适用UML

  • 1）传统的做法已完全适用，对面向对象技术的要求也不高，项目非常成功，无任何改进的必要
  • 2）开发的系统比较简单，直接用源码配上少量的文字就能解决问题，软件开发文档也无需添加图形来辅助说明
  • 3）开发的系统本身不属于OO方法、UML适用的范围

2.2 UML统一历程

  • 90年代：面向对象分析设计方法学之战

    • P. Coad和E.Yourdon提出OOA和OOD
    • G. Booch提出面向对象开发方法
    • Jacobson提出OOSE
    • Rumbaugh提出的OMT

  • UML的出现结束了这场方法学战争

image-1673795412960

统一了什么？

  • 开发生命周期

    • UML对于开发的要求具有无缝性,即在软件开发生命周期的各个阶段都可以采用UML。开发过程的不同阶段可以采用相同的一套概念和表示法,在同一个模型中它们可以混合使用。在开发的不同阶段,不必转换概念和表示法。这种无缝性对迭代的增量式软件开发至关重要。这个过程会增强用户对概念及其适用性的理解。这不是统一各种标准的初衷,却是统一各种标准所得到的最重要的结果之一。

  • 应用领域

    • UML适用于各种应用领域的建模,包括大型复杂分布式系统、实时嵌入式系统、集中式数据或计算系统等。当然,也许用某种专用语言来描述一些专门领域更有用,但在大部分应用领域中,UML不比其他的专用语言逊色,甚至更好。

  • 实现语言和平台

    • UML可应用于各种不同的编程实现语言和开发平台系统。无论是采用Java,C++,C#等程序设计语言和开发工具,还是使用Windows,Linux等不同的操作系统,均可以采用UML进行建模。

  • 开发过程

    • 在构建UML元模型的过程中,特别注意揭示和表达各种概念之间的内在联系,并试图用多种适用于已知和未知情况的办法去把握建模中的概念.这个过程会增强用户对概念及其适用性的理解。这不是统一各种标准的初衷,却是统一各种标准所得到的最重要的结果之一。

  • 自身的内部概念

    • 在构建UML元模型的过程中,特别注意揭示和表达各种概念之间的内在联系,并试图用多种适用于已知和未知情况的办法去把握建模中的概念。这个过程会增强用户对概念及其适用性的理解。这不是统一各种标准的初衷,却是统一各种标准所得到的最重要的结果之一。

3、UML组成结构

  • 从UML2开始，整个UML规范被划分成基础结构和上层结构两个相对独立的部分
    • 基础结构（Infrastructure）是UML的元模型，它定义了构造UML模型的各种基本元素
    • 上层结构（Superstructure）则定义了面向建模用户的各种UML模型的语法、语义和表示
  • 从UML2.5开始，为了消除冗余并简化UML规范，基础结构部分不再作为UML规范的一部分，UML元类在UML规范相应的章节中被完整地定义

3.1 语法结构

  • UML的抽象语法使用UML元模型来定义
    • 这个元模型本身也是用UML来定义（准确来说是一个受限的UML子集，这个子集符合OMG的MOF规范）
    • 在UML规范中，主要采用UML类图来描述各元素的抽象语法，采用约束机制和自然语言（文本）来描述模型语义

类的元模型（语法结构）

下图清晰地描述了一个类的组成结构，还通过端点名(关联关系两端的文字)和约束规则(大括号中的文字)限定语法和语义。通过该图,可以看出类(Class)是 EncapsulatedClassifier和 BehavioredClassifier两个抽象分类器的具体实现。类的目的是描述对象的分类,并定义了那些刻画对象结构和行为的特征。类由内部分类器(nestedClassifier)、属性(ownedAttribute),操作(ownedOperation)和响应(ownedReception)四部分组成;此外,可以指定其父类(superClass),定义其扩展(extension) ，还可以指定其是否为抽象类(isAbstract)、是否为主动类(isActive)。

image-1673796599416

响应（异步建模 例如图形化界面开发中的鼠标单击事件）

3.2 UML语义结构

  • UML自身的语义与被建模系统的UML模型上所声明的标准含义有关，这有时被称为UML运行时语义
  • UML模型划分为两类语义域。
    • 结构语义：定义了在建模域中关于个体的UML结构化模型元素的含义，也称为静态语义
    • 行为语义：定义了在建模域中关于个体如何随着时间变化而做出不同行为的UML行为模型元素，也称为动态语义。

UML语义域

image-1673797586925

补充模型 行为语义 结构语义

UML结构语义为行为语义提供基础,通过结构化建模所规定的模型元素的状态变化而形成行为语义的概念。UML结构模型建立在一个通用的基础结构(Common Structure)之上,包括类型、命名空间、关系和依赖等概念。Common Structure具体的建模元素包括不同的分类器(Classifiers),这包括数据类型、类、信号、接口和构件等;此外还包括简单的值类型(Values)和包(Packages)等。 构建在基础结构之上的UML基本行为语义为行为的执行提供了一个基本框架,通用行为(Common Behavior)语义还定义了结构化对象之间通过相关行为产生的通信。动作(Actions)是 UML中的基本行为单元,用于定义细粒度的行为;在此基础上形成高层次的行为机制,包括状态机(State Machines)、活动(Activities)和交互(Interactions)等。 此外,还提供了一些既有结构化又有行为的辅助建模结构,包括用例(Use Cases),部署(Deployments)和信息流(Information Flows）。

4、UML2概念模型

UML概念模型主要由三部分组成:基本的构造块、运用于这些构造块的通用机制和组织UML视图的架构。每个部分又包含不同的子部分。

image-1673880388557

4.1 构造块

1）事物

在UML中,事物代表了基本的面向对象构造块,主要包括以下4种类型的事物。

  • **结构事物(Structural Thing)**是UML模型中的名词。它们通常是模型的静态部分,用于描述概念元素或物理元素。常见的结构事物包括类、接口,用例、协作.构件、工件、节点等。
  • **行为事物(Behavioral Thing)**是UML模型中的动词。它们是模型的动态部分,代表了跨越时间和空间的行为。常见的行为事物包括交互,状态机、活动等。
  • 分组事物(Grouping Thing)是UML模型的组织部分,用于将模型元素组织在一起。主要的分组事物是包,还有其他的诸如子系统、层等基于包的扩展事物。
  • **注释事物(Annotational Thing)**是UML模型的解释部分,用来描述、说明和标注模型的任何元素。最重要的注释事物就是注解(Note),它是依附于一个元素或一组元素之上对元素进行约束或解释的简单符号,所有的UML图形元素均可以用注解来说明。
2）关系

关系将UML的事物连接起来,构造出结构良好的UML模型。在UML中有4种基本关系:依赖、关联、泛化和实现。

  • **依赖(Dependency)**是两个事物间的弱语义关系,表明两个事物之间存在着一种使用关系,其中一个事物(独立事物)发生变化会影响另一个事物(依赖事物)的语义。依赖关系的箭头表明了依赖的方向,即没有箭头端的事物依赖于有箭头端的事物。

  • **关联(Association)**是一种强语义联系的结构关系,表明两个事物之间存在着明确的,稳定的语义联系。它描述了一组链接(link),链接是事物的具体实例之间的关联(如类之间的关联,则意味着类的对象之间存在链接)。聚合(Aggregation)是一种特殊类型的关联,它表明关联的两个事物之间还存在一种整体和部分的语义联系。图2-5中的关联关系两端都没有标注箭头,这并不意味着关联关系没有方向,默认情况下关联的方向是双向的，也就是说,两个关联的事物之间互相依赖。如果要标注单方向的依赖,则需要在关联的一端标注箭头。

  • **泛化(Generalization)**是一种特殊—一般关系,特殊元素(子元素)的对象可替代一般元素(父元素)的对象。通过这种关系，子元素共享了父元素的结构和行为。

  • **实现(Realization)**是两个事物之间的一种契约关系,其中的一个事物(箭头指向的事物)描述了另一个事物必须实现的契约。在两种位置会遇到实现关系:一种是在接口和实现它们的类或构件之间;另一种是在用例和实现它们的协作之间。

这4种元素是UML模型中可以包含的基本关系事物。它们也有扩展和变体,例如,依赖关系就可以扩展为包含、扩展、精化、跟踪等关系,而关联关系还有聚合、组合等变体的形式。

3）图

image-1673881169428

针对这14种图,按照UML2.5的分类方法可以划分成两类:一类描述系统的静态结构模型;另一类描述系统的动态行为模型。结构模型捕获事物及事物之间的静态关系,而行为模型则捕获事物是如何交互以产生软件系统所需的行为。

4.2 通用机制

1）规格说明(Specifications)：文本维度的模型描述
  • UML模型至少具有两种维度：
    • 图形维度：使用图和图标可视化模型
    • 文本维度：各种建模元素的规格说明
  • 规格说明
    • 模型元素的特征和语义的文本描述
    • 形成了承载模型的语义背板（semantic backplane），赋予模型意义，各种图仅仅是该背板的视图或者可视化投影
    • death by diagram(由于图形而死亡)
2）修饰(Adornments)：描述建模元素的细节信息

  • UML表示法中的每一个元素都有一个基本符号，可以把各种修饰细节添加到这些符号上

    • 只有在修饰增强了图的整体清晰性和可读性或者突出模型的某些重要特征时，才应该表示那些修饰

    image-1673883011027

3）通用划分(Common Divisions)：建模时对事物的划分方法

  • 在对面向对象系统建模中,通常有以下3种对元素进行分类的通用方法。

    • 第一种是类元(Classifier)和实例的划分。
      • 类元表示一种抽象
      • 实例则是这种抽象的一个具体表现。在UML中,很多概念都是基于这种划分方法建立的,例如,类和对象、用例和场景﹑构件和构件实例等。
    • 第二种是接口和实现的分离。
      • 接口声明行为的契约(做什么),
      • 实现表示对该契约的具体实现细节(如何做)。例如,接口和子系统、用例和用例实现、操作和方法等。
    • 第三种是类型和角色的分离,这是UML2新增的划分方法。
      • 类型声明实体的种类(如对象、属性、参数)
      • 角色描述实体在语境(如类,构件、协作、组合结构)中的含义。
      • 任何作为其他实体结构的一部分实体(如属性)都具有两个方面的特性:
        • 从固有类型派生出来的含义
        • 在语境中的角色派生出来的含义。

图2-7展示了组合结构中的customer对象,作为Person类，customer对象具有Person类所提供的属性和行为﹔同时,作为组合结构TickOrder(订票系统)中的角色,customer是一个订票的顾客。

​ image-1673882756679

4）扩展机制(Extensibility Mechanisms)
  • 构造型(Stereotype)：基于已有的建模元素引入新的建模元素。
  • 标记值(Tagged Value)：扩展UML构造型的特性,可以用来创建构造型的详细信息。
  • 约束(Constraint)：扩展UML构造块语义,可以用来增加新的规则或修改现有规则。
  • 外廓(profile)：提供了一组预定义的构造型、标记值、约束和基类，以用于特定领域的建模

图2-8展示了在类EventQueue上添加这3种扩展机制。其中类名前面的“<>”是构造型(名称被放在“<<>>”里面),表明该类不同于其他的类,它具有版权信息(具体的含义在扩展时定义)﹔信息的细节通过注解框中的标记值来表示;该类的add()操作添加了{ordered)约束(名称被放在“{ }”里面),表明在插入数据时需要排序。

image-1673883903082

构造型(stereotypes，衍型)

  • 根据已有的模型元素定义一个新元素
  • 建立在UML已定义的模型元素基础上
  • 可以用于所有的UML模型元素，如类、关联、用例、构件等
  • UML规范提供了一些预定义的构造型

构造型可能的3种表现形式。其中第一种是标准表示(在类名前面用“<<、>>”表示),第二种是在类的右上角用特殊的图标表示,第三种是直接采用全新的图形符号表示。

image-1673883955256

5）外廓和外廓图

外廓(Profile)

  • 基于UML元素的子集为特定领域定义了UML的一个特定版本，即定义了一组对UML已有模型的扩展和限定机制，以用于某个特定领域
  • 这些扩展和限定机制包括：预定义的构造型、标记值、约束和基类
  • 建立在普通的UML元素基础上，并不代表一种新的语言

外廓图

image-1673884821116

  • UML2.3新增的Profile Diagram专门用于可视化描述外廓以及构造型、标记值、约束等
  • 主要概念
    • Profile: 一个包，代表一个外廓
    • Stereotype: 定义一种针对元类的扩展
    • Metaclass: 可被扩展的元素
    • Extension: 构造型和元类之间的关系
    • ProfileApplication: Profile和应用模型之间的关系

数据库建模的核心概念是表、字段和关系等,这些概念在UML标准规范中并没有定义,无法直接利用UML建模。为此,我们需要通过扩展UML类图中的相关概念,如可以利用UML类建模表,利用类的属性建模表的字段,利用类之间的关联关系来建模实体间的关系。这里,我们利用外廓图定义了3个构造型MyTable ,MyColumn和 MyRelationship,分别表示数据库表、字段和关系,它们各自从UML元类中的类(Class),属性(Attribute)和关联关系(Association)上扩展而来﹔此外,对于MyColumn构造型,我们还添加了两个布尔类型的标记值PK和IsNULL,分别表示该字段是否为主键(默认值为false),是否可以为空(默认值为true)。定义这套扩展机制的外廓图如图2-10所示。需要说明的是,该图采用Enterprise Architect绘制,图中3个扩展的构造型没有采用表2-1中的标准表示形式(即名称前面加“<< stereotype >>”的方式),而是采用右上角添加“《》”的方式表示,这是该建模工具所提供的特定图形符号。

用于数据库建模的外廓图

image-1673885628900

4.3 架构

​ UMI提供了丰富的模型图来表达系统的各个方面,这些图形之间并不是完全独立的，它们之间存在着千丝万缕的联系。在软件开发的各个阶段,每种图形都有不同的用法和侧重点,这就给普通用户的使用带来了很大的困扰。 ​ UML标准只是提出了这些图形的语法模型和语义模型,并没有针对这些图形的使用提供很好的支持。为了有效地利用这些模型,我们就需要结合不同的软件工程过程,定义组织图形的架构。 ​ 一种被大家广泛接受的UML架构是源自统一过程中所提供的“4＋1”架构模型,该架构如图2-13所示。

image-1673886897292

  • 用例视图（Use Case View）
    • End-user: Functionality
    • 这些视图由用例视图所统一，它描述项目干系人（stakeholder）的需求；所有其他视图都是从用例视图派生而来，该视图把系统的基本需求捕获为用例并提供构造其他视图的基础
  • 逻辑视图（Logical View ）
    • Analysts/Designers: Structure
    • 系统功能和词汇；描述问题域的词汇，作为类和对象的集合。重点是展示对象和类是如何组成系统、实现所需系统行为的
  • 进程视图（Process View ）
    • System integrators: Performance, Scalability, Throughput
    • 系统性能、可伸缩性和吞吐量；建模在我们系统中的可执行线程和进程作为活动类。其实，它是逻辑视图面向进程的变体，包含所有相同的制品
  • 实现视图（Implementation View）
    • Programmers: Software Management
    • 系统组装和配置管理；对组成基于系统的物理代码的文件和组件进行建模。它同样展示出组件之间的依赖，展示一组组件的配置管理以定义系统的版本
  • 部署视图（Deployment View ）
    • System engineering: System Topology, Delivery, Installation, Communication
    • 系统的拓扑结构、分布、移交和安装；建模把组件物理地部署到一组物理的、可计算节点上，如计算机和外设上。它允许你建模横跨分布式系统节点上的组件的分布

有时候,甚至可以按照系统的开发阶段或活动来组织模型。

image-1673887220701