Blog

Blog

PHODAL

元素建模:探索建模的要素

PS:本文有些杂乱无章,偏向于是个人的一些思考。

概括来讲,纵观各种语言,其语法成分汇总起来构成一个关键概念集合。 —— Leonard Talmy

在先前的一系列云研发体系的文章里,我们一直在对需求、代码等各种软件开发元素进行抽象、定义、建模。随着,这个抽象过程的一步步深入,便发现我们似乎也需要对于建模这一件事,做一层抽象。

建模是一件非常好玩的事情,我们总是在不断也抽象、抽象、抽象,还有定义、定义、定义。随着我们不断深入软件架构的设计里,我们也会不断也尝试着一系列不同的方法,诸如于我的同事 @少个分号 在那篇《建模方法元模型:如何设计一个建模方法》一文里,对于不同建模方式进行了简单的介绍,并进行了相关的拆解和分析。

每一种建模方法都有自己的优缺点,准确性-时间花费-维护成本之间的平衡,同时还依赖于不同的系统类型,依赖于我们的经验。因此,设计并实践一种新的建模方法,并不是一件容易的事 —— 需要经过大量地试验和验证。

回到这一篇文章来,我的意图是想寻找建模方法的一些共性。正好,结合一些最近对于模型与概念关系的一些思考。

从人类语言到编程语言

回到《认知语义学》对于语言的区分上来看,根据指代实体物和物质所用词汇化典型形式的不同,语言可以分成两种主要类型:

  • 事物主导型语言(object-dominant language),倾向于使用名词的语言,大多数语言属于这一类型
  • 行动主导型语言 (action-dominant language),倾向于使用动词的语言。

从这种定义来说,英语一种事物主导型语言,因为它倾向于使用名词来指称物理实体可触及的物质性。将上述的人类语言与编程语言进行映射,我们就会得到现今主流的编程范式:

  1. 面向对象编程。
  2. ~~函数式编程(待定)~~。

PS:从含义上来看,行动主导语言与函数式编程的对比并不是那么贴切,只是从书中 GET 到一些灵感。其中的准确性,有待于后续进行相关的验证。

从相似度来看,两种不同方式的主导型语言,更像是两种不同的驱动设计范式:模型驱动与事件驱动。

模型驱动 vs 事件驱动

从维基百科上的定义来看,事件驱动的定义是:

事件驱动编程(英语:Event-driven programming)是一种编程范式,其中程序的流程由诸如用户操作(鼠标单击、按键)、传感器输出或从其他程序或线程传递的消息等事件决定。

而对于模型驱动来说,它发展得相当的完善,以至于可以变成一个工程分支:

模型驱动工程(MDE, Model-Driven Engineering)是软件工程的一个分支,它将模型与建模拓展到软件开发的所有方面,形成一个多维建模空间,从而将工程活动建立在这些模型的映射和转换之上。MDE的基本原则是将模型视为第一实体,将所有软件产物当做模型或模型要素。

从软件工程的角度来看,模型驱动已经相当的成熟 —— 我们可以从模型作为出发点,进而构建出围绕于系统的分层架构、边界等。与此同时,在采用领域驱动设计的方式时,它还能将事件作为一种辅助的输入方式,来帮助完善整个系统的模型设计。

PS:从这一个角度来看的话,我们也可以围绕于事件驱动,构建出一套完整的软件开发模式。回到人类用来的语言沟通本身,我们记录的是动词、名词等一系列的内容构成的句子,如果将句子看成是一个个的用例,也是蛮有趣的。与此同时,既然我们可以存储模型,那么存储事件也是可以的,至于是代码还是其它形式就是另外一个故事了。

再回到面向对象这一点来看的话,建模就变成了一件非常有意思的事。

建模“建模”:从概念到模型

回到我们所开发的软件系统里,其系统的核心组成部分是由一个个的概念所组成。我们对于系统的理解程度,在认知的意义上来说,也取决于我们对于这些概念的理解和使用程度。在系统的设计初期,我们只有些许的概念。随着,系统的演进,我们引入了越来越多的概念,并以自己理解的方式,组织起这些概念的结构。受《认知语义学:概念构建系统》一书的启发,我尝试性去去探索它们之前的联系。

从语义学的角度来考虑,如果概念在特定的概念范畴内形成模式,这些概念范畴可称为图式范畴(schematics categories)。图式范畴在更为广泛、完整的概念结构系统中类聚,这些系统就可称为图式系统(schematics systems)。顺便一提,从分类上来说,常见的图式系统有:

  • 构型结构(configurational structure)。包括了可以由封闭类(可以代指为实体)形式表达的空间、时间以其他定性域内的图式结构或几何轮廓。
  • 视角(perspectivs)。用于观察这一类实体的视角,它们也可以由封闭类形式来表达。
  • 注意分布(distribution of attension)。由分配在所指对象或场景上的不同强度的注意模式组成。

在以模型为主导的软件开发系统里,它们多数是可以归属于构型结构的图式系统。如在实现软件系统时,会使用实体的方式来表示这些概念,其对应到代码上的实现方式是:模型。通过结合多种不同的图式范畴,可以有多中不同的软件建模方式,如领域驱动设计里,便结合了领域(domain)、界态(state of boundedness)等。

建模的方式:基于“事实”的软件建模

PS:对于事实,从语言的角度,可能使用纪实、叙实会比较合适。

所有的软件开发都是由朝着满足用户关注点的方向而驱动的:捕获用户的关注点,设计系统来实现这些关注点,以及测试系统是否滿足这些关注点。

再次的,我们再将镜头拉回,回到软件开发中,初步的看一看现今的一些软件建模方式。它们为了“标准化”,需要围绕于这些“事实”来构建出模型。

PS:这里的“事实”指的是客观信息,诸如于事件、用例、凭证等一系列不依赖于人经验的要素。起初,我尝试使用表征一词,它的定义是一种将客观信息进行转换后得到的符号系统。在某种意义上来看,使用“事实”一词也显得不是那么准确。

基于用例的建模:用例驱动设计

用例驱动设计是一种“古老”的软件工程设计方法。其中,用例(UseCase)是对一个活动者使用系统的一项功能时,所进行的交互过程的一个文字描述。用例分析法会通过如下的方式来设计系统:

  1. 寻找用例并详细说明它们。
  2. 设计每个用例。
  3. 设计并实现每个类。
  4. 测试每个用例。

在这个过程中,用例便是这里的“事实”,围绕于这个已知的“事实”,有经验的开发人员,也可以凭借于此来进行规范化的开发。

基于事件的建模:事件风暴与领域驱动设计

在领域驱动设计中,采用事件风暴来进行系统的设计是一种较为模式化的工程方法。其中思想的一个核心要素是:事件是系统状态变化的关键帧。事件风暴由三个主要的步骤构成:

  1. 头脑风暴,以识别领域事件。
  2. 识别事件触发器(决策命令)。
  3. 识别聚合(业务承载物)。

在这个过程中,事件便是这里的“事实”,围绕于这个已知的“事实”。有经验的开发人员,也能通过此来构建出合理的系统架构。

基于凭证的建模:履约建模

履约建模是一个比较新的建模方法,它基于凭证的方式来设计系统。其核心要素是:作为业务凭证,只存在创建,不存在修改和删除。关键步骤如下:

  1. 寻找合约上下文,明确合同的参与方;
  2. 寻找合同约的主要履约项,按四色建模寻找凭证;
  3. 对于主要履约项,寻找违约情况,设立新履约项,按四色建模寻找凭证;

在这个过程中,凭证便是这里的“事实”,围绕于这个已知的“事实”。有经验的开发人员,也能通过此来构建出合理的系统架构。

建模建模

从某种意义上来说,寻找这些“事实”的过程,便是系统状态的表征过程。

表征,是信息在头脑中的呈现方式,是信息记载或表达的方式,能把某些实体或某类信息表达清楚的形式化系统,以及说明该系统如何行使其职能的若干规则。

所以,围绕于这些“事实”的建模方式的步骤,可以抽象为:

  1. 基于可确定的 “事实” 确定状态(or 数据)。
  2. 借助模式来编排状态。
  3. 映射与过滤去除影响因子。分离变化要素,得到基本的概念。
  4. 精炼概念,得到模型元素与行为。
  5. 概念类聚。上下文边界划分

这个过程,类似于对数据的处理流程:collect-map-filter-reduce 等。

其它

模型,只是我们对于事物的一种映射与理解。本文只是初步对于建模的一些思考~,有待后续进一步完善。


或许您还需要下面的文章:

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签