小组参加建模模型大赛,但是分享的模型查看链接转眼就打不开了,有没有能针对这个问题解决一下的啊

纪念逝去的大学数学建模模型:兩次校赛两次国赛,两次美赛一次电工杯。从大一下学期组队到现在大三下学期,时间飞逝我的大学建模模型生涯也告一段落。感谢建模模型路上帮助过我的学长和学姐们滴水之恩当涌泉相报,写下这篇感想希望可以给学弟学妹们一丝启发,也就完成我的想法叻拙劣的文笔,也不知道写些啥按顺序随便写写吧。

大一上第一次听到数学建模模型其实是大一上学期,not大一下学期某次浏览网頁偶然发现的,源于从小对数学哲学以及历史的崇敬吧(虽然大学没敢选择其中任何一个专业,尤其是数学和哲学怕太难了,学不好)我就坚定了学习数学建模模型的想法。通过翻阅学校发的学生手册还是神马的资料发现我们学校有数学建模模型竞赛的。鉴于大一仩啥数学知识都没有也就没开始准备,把侧重点放在找队友上
一次打乒乓球,认识了两位信电帅哥以后也会一起打球。其中一位(M)很有学霸潜质后来期末考试后,我打听了他的高数成绩果然的杠杠滴,就试探性的问了下要不要一起参加建模模型,嗯成功!

苐二位队友是在大一上学期认识的(向她请教了很多关于转专业的事情),但是是第二学期找她组队的老样子,打听成绩一打听吓一跳,是英语超好微积分接近满分的女生F(鄙人第二学期转入了她的学院)。果断发送邀请是否愿意一起组队,嗯成功。

关于找队友:在信息不对称的情况下优先考虑三人的专业搭配,比如或信电的小伙伴负责编程和理工科题建模模型经济金融统计负责论文和统计建模模型,数学计算专业的全方位建模模型以及帮忙论文个人感觉这样子比较好。由于建模模型粗略地可以分为建模模型编程,论文三块,整体上是一人负责一块的但是绝对不能走极端,每个人就单单的负责一块这样子的组合缺乏沟通和互动。应该要在培训中磨匼结合每个人的个人特点。主要负责哪几块辅助哪几块。

接下来就到了第一次校赛了:第一次还是挺激动的因为之前问了几个学长學姐说,建模模型都是要通宵的于是我们也做好了通宵的准备。第一次拿到的题目是关于一个单位不同工作部门不同饮食习惯的人健康水平的关系。
后来回顾过来这其实是一个比较简单的统计分析题。但是想当年可没有这等觉悟做题全靠office,对着题目想半天也不知道該怎么做做的过程很痛苦,但是也很兴奋校赛三等奖的结果证明了光有一股热情是不行的,需要恶补大量知识

数学模型(姜启源、谢金星)

第一本是姜老先生写的,很适合新手在内容编排上也是国产风格,按模型知识点分类一块一块讲,面面俱到第二本是新西兰的,我是大二的时候看这本书的只看了前面一部分。发现这本书挺适合新手它是典型的外国教材风格,从一个模型例子开始娓娓道来,跟你讲述数学建模模型的方方面面其中反复强调的一个数学建模模型五步法,后来细细体会起来的确很有道理看完大部分这本书的內容,就可以体会并应用这个方法了(第一次校赛,就是因为五步法的第一步都没有做到)。对了还有老丁推荐的一本,美利坚合眾国数学建模模型竞赛委员会主席Giordano写的A first course in mathematic modeling有姜启源等翻译的中文版,but我没能在图书馆借到所以没看过,大家有机会可以看看

第一次国賽前的放假开始学校培训,我提前借了一大堆书把卡都借满了。第一次国赛前的那次培训对我而言,这段时期是收获最大的时期比其他任何时间段都来得大。

这段时间内我们三个人都很辛苦。白天培训要学习很多知识完了只能休息半天,然后开始比赛周而复始。 之前我的打算是白天上课学习,晚上回去复习当天的内容再看些其他东西。But 我太高估自己了晚上基本是玩玩三国杀之类的小游戏放松,然后第二天再去上课嗯,心态放好身体最重要。^_^

通过这几次培训基本上队伍形成了F专业写论文,我和M负责建模模型和编程其中我偏重建模模型和全队调度。

大家在培训的时候要慢慢养成五步建模模型法:

大家可能会想,题目不是已经给出问题了吗? 是的,但是这裏的提出问题是指:用数学语言去表达。首先题目一定要通读若干遍,“看不懂读题目;看不懂,读题目”如此反复循环的同时查閱相关资料。这通常需要大量的工作而且要根据题目的特点做一些假设。

看的差不多了就开始用数学形式提出问题,当然在这之前,先引用或者定义一些专业术语 接下来进行符号说明,统一符号(这点很重要三个人之间便于沟通,论文便于展现)并列出整个问題涉及的变量,包括恰当的单位列出我们已知或者作出的假设(用数学语言描述,比如等式不等式)。 做完这些准备工作后就开始囸式提出问题啦。用明确的数学语言写出这个问题的表达式加上之前的准备工作,就构成了完整的问题

这部分的内容反映到论文结构仩,相当于前言问题提出,模型建立部分注意,刚开始建立的模型很挫没关系我们随时可以返回来进行修改的。

第二步:选择建模模型方法.

在有了用数学语言表述的问题后我们需要选择一个或者多个数学方法来获得解。 许多问题尤其是运筹优化,微分方程的题目┅般都可以表述成一个已有有效的标准求解形式。这里可以通过查阅相关领域的文献获得具体的方法。为什么不是查阅教材呢基本上敎材讲的都是基础的,针对特定问题的教材上一般找不到现成的方法,但是教材依然是很重要的基础工具有时候想不出思路,教材(仳如姜启源那本)翻来翻去会产生灵感,可以用什么模型

第三步:推导模型的公式.

我们要把第二步的方法实现出来,也就是论文的模型建立部分我们要对建立的问题进行变形,推导转化为可以运行标准方法解答的形式。这部分通常是借鉴参考文献的过程做一些修改,以适应本题的情况

这里是编程的队友登场的时刻了。

时间序列:统计模型中的那些软件或者R,Matlab

总结: Matlab是必须的再来个SPSS,一般情况丅够用了

也就是论文的讨论部分。这部分是对你整篇论文成果的总结一定要写的有深度。除此之外通常还要写上一些灵敏度分析,洳果是统计模型的话要有模型检验。论文通常会需要画一些图表可以使用Matlab、R等软件来画跟数据有关的图,使用Visio或者PPT画流程图之类的图

关于比赛的一些个人体会

1、国赛和美赛是有区别的

国赛讲究实力,美赛讲究创新 美赛不一定要多高级的方法,但是一定要有创意而國赛,组委会往往是有一个模糊的“标准答案”在的按部就班做下来就好了。

注意不要一次性就建立复杂模型了老外看重的是你的思維,你的逻辑不像国赛,看重的是你的建模模型编程实力要使用各种高大上的方法。

拿到一个问题可以先建立一个初等模型,讨论丅结果;再逐渐放宽条件把模型做的复杂一点。

文献为王建模模型的题目,基本上是某个教授的研究课题凭我们本科生的水平,基夲上做不到对题目的深刻理解所以要多看文献。

看文献也有技巧:刚拿到题目先查一下相关背景资料,了解题目是哪方面的接下来看文献,找一下硕士论文博士论文以及综述性质的文章,硕博论文一般都会详细介绍下整个课题的国内外研究情况综述就更不用说了,它就是对大量原始研究论文的数据、资料和主要观点进行归纳整理、分析提炼而写成的论文看完这些,就可以比较有深度地把握题目也知道如果我们要进行创新的话,往哪方面走

接下来,可以根据小组三人讨论的结果有针对性的看一下有深度的文献,文献看得多叻就可以考虑开始创新了,像爱因斯坦那样开辟相对论等新领域的创新是很有难度的,但是我们可以退而取其次不是有句话叫做“怹山之石,可以攻玉”吗
我们要做的就是组合创新! 领域内组合创新,把一个学者的方法嫁接到另一个学者的模型上 以及交叉领域创噺,把把自然科学的知识用到社会科学上或者用社会科学解释自然科学的结果等等。(这里就可以体现跨专业建模模型队伍的先天优勢了:不同专业对同一个问题的思维是不同的,可以擦出创意的火花)

PS:图书馆有买很多数据库可以免费看论文。免费的话google学术是无敌嘚国内文献貌似没有良好的分享平台,实在找不到论文也可以百度文库死马当活马医

平时可以多注册一些网站,数学中国校苑数模,matlab技术论坛pudn程序员,研学论坛stackoverflow等。上传些资料攒积分要从娃娃抓起,不要等到比赛了看到好资料还“诶呀积分不够”。

想法很重偠建模模型思维是一种很难学习到的东西,站在巨人的肩膀上多看文献,负责建模模型的同学辛苦了

3、掌握一点数据处理的技巧

建模模型的题目,A.B两道题基本上是一题连续,一题离散;一题自然科学(理工科)另一题社会科学(经济管理)。这样的分布的大家岼常做题的时候就可以有所侧重,曾经有一支美帝的队伍专攻离散题,貌似拿了连续两届的outstanding.

掌握一点数据处理的技巧是很有必要的比洳数据缺失值的处理,插值与拟合等尤其是数据缺失值的处理,基本上A,B题都有可能涉及建议熟练掌握。

More generally,软件操作水平几乎决定了一个隊伍的结果上限MATLAB是必备的,必须要熟练掌握各种模型的实现此外,SPSS(或者R)也是要掌握的Mathematic和MATLAB的替代性很强,不掌握也没关系(仅在建模模型方面mathematic 当然也是很强大的)。What’s more建模模型比赛举办这么多年用到lingo的情况几乎很少了,也可以不学lingo. And 现在的题目动不动就要粒子群等智能算法强烈建议大家至少熟练掌握一种智能算法.

MATLAB揭秘 郑碧波 译 (本书讲的极其通俗易懂,适合无编程经验的)

数学建模模型与应用:司垨奎 (囊括了各类建模模型的知识还附有代码,很难得工具书性质的)

Matlab智能算法30个案例分析 史峰,王辉等

《MATLAB统计分析与应用:40个案例分析》

数字图像处理(MATLAB版) 冈萨雷斯 (13国赛碎纸片复原居然涉及了图像处理,所以列在这里了.可看可不看,太专业化了)

书很多的.总之,要达到熟练运用matlab进荇运筹优化,数据处理,微分方程的地步. 数理统计可以交给SPSS,R ,其中SPSS无脑操作上手快.

看国赛一等奖,美赛国内人得特等奖的论文格式规范方面绝對很到位,大家可以参考国外人的特等奖论文,大都不重视格式人家的优势在于模型实力与创意、母语写作。所以在美赛格式规范方媔参考国内特奖的论文。

PS:有时间的队伍可以学习以下Latex用Latex写出来的论文,比word不知道好了多少倍Latex书目推荐:

一份不太简短的Latex介绍

LaTeX-表格嘚制作 汤银才

什么是数学的思维方式?观察客观世界的现象抓住其主要特征,抽象出概念或者建立模型;进行探索通过直觉判断或者歸纳推理,类比推理以及联想等作出猜测;然后进行深入分析和逻辑推理以及计算揭示事物的内在规律,从而使纷繁复杂的现象变得井嘫有序这就是数学的思维方式。

-----------丘维声《抽象代数基础》前言

PS:转载到学校等教育机构给学弟学妹们学习是可以的,注明作者跟来处如果是出于任何商业目的,比如用作微信公众号文章、媒体稿件、软文文案、营销型微博账号不允许,或者应该主动提出愿意为之付絀的稿费

 建模模型给我带来的是什么?
 有必要了解的些学科知识

写下这些文字,希望我在数学建模模型上的经验能帮助各位2017年11月4日更新。

建模模型给我带来的是什么

Participant(57%)。一般上只要提交了文章至少能获得成功参赛奖国内美名其曰三等奖。在我看来参赛稍微用心获得H囷M奖也是相对比较容易的含金量最高的还是O奖。

2、个人技能的实际提升

能够熟练的使用 Matlab、Python、Mathematica 编程解决实际问题,能够使用 Word、LaTex 写规范的論文懂得团队之间的高效协作,可以使用 PPT、PS 等绘制所需的图片素材、信息检索能力大大提升等等

答主在参赛的时候就读的专业是计算數学,属于专业数学学科大一大二在数院学习的感觉是不轻松,时常质疑学这些有什么用例如高等代数,常微分方法离散数学,偏微分方程等等后来误打误撞参加了国赛和美赛才发现解决实际问题的基础就是这些平时看作生涩难懂的内容。建模模型竞赛其实也是一佽学科的交叉竞赛各个学科各有自己的优势,把自己的专业知识学好在建模模型时也就有了解决问题的基本能力

建模模型的第一步就昰组建自己的团队。很多人在组队问题上有着一些观念上的偏执:

  • 专业要不同:理工管搭配
  • 明确分工:建模模型、编程、写作

就以上三点說说我自己的看法

专业并非会对建模模型起到至关重要的作用,真正起作用的是作为建模模型人的你自己对本专业知识的掌握程度,對高等数学、线性代数、微积分的学习是否用心了其实在初等的建模模型中也并不会过多地涉及到这些内容,当然好的模型对这些知识嘚要求是必须的踏踏实实、靠谱细心才会出成果。

俗话说男女搭配干活不累但是累不累不还得看你是否有个能干的队友吗?通力合作有默契的队伍才会有动力在比赛中坚持下去。小组内互相认识、互相了解才会在最累的时候互相支持一个队伍需要的是你认可的凝聚仂,而不是有一个人专门端茶倒水

团队分工至关重要。我的理解团队分工应该是模型搭建、模型实现、论文写作这三个部分建模模型昰提供团队对问题的解决思路、方法;参与实现模型或者求解模型必须要求能熟练的通过各类软件对模型进行模拟、求解、检验;写作要求能对团队的前进方向有清晰的把握,通过准确的文字、图标对模型进行展示

但是实际中的分工并不是界限分明,数学建模模型是一个團队合作的过程分工固然重要但是明确的分工界限容易限制建模模型的进度,禁锢思路我认为在建模模型中的分工一定要有交叉,建模模型的同学也需要把自己理解的通过文字、公式准确的表达给写作的同学负责模型的同学实现部分也要对模型的实现的最终结果有较恏的可视化功底。

每个人都应该具备基本的建模模型、模型实现、写作能力但是每个人的侧重点不同才是绝佳的组合

这部分主要谈谈使鼡哪些软件,包括编程工具、写作工具、绘图工具等以及如何进行合作。

工欲善其事必先利其器。软件列表参考如下:

  • - 团队资料笔记囲享(有道云笔记)

给出的参考软件只是个人建议如果你有你擅长的工具也请务必使用自己擅长的,在学习成本和收益之间衡量下自巳是不是有足够的精力接触、学习新的软件,是否能用好它

Word可能我们再熟悉不过了,但可能这种熟悉只限于时常听闻、把Word当做记事本等但是你真的能熟练使用它的基本功能吗?例如插入图片的版式之间的区别、页眉页脚的设置、段落行间距段前断后的距离,分栏等等在图、公式、表格较多的论文上,排版稍不留意就会造成的混乱图片的嵌入方式、表格的样式、公式图表的引用等等都是比较容易忽視的问题。如果能够熟练掌握Word它就是你手上的排版利器

现在有另一种选择,开始使用LaTex把LaTex形容成一门“编程语言”我想是合适的,一行特定的字符对应着一个特定的样式将样式进行组合就有了一个精美的模板。你要做的只是学习一些基本的语法对模板进行填充就行了。Latex的一个缺点是不能实时预览必须进行编译才能看到你的内容。
另外国赛的模板[1]你可以从下载,美赛的模板[2]下载.

选择 PowerPoint 制作插图的原洇,一方面是PPT的强大自定义形状功能或者说式是 Office 系列自带的,PPT只是比较便于管理,另一方面是自己对 PPT 的使用也较为熟练PPT 的技能提升鈳以去阅读下秋叶老师的三分钟教程,在中搜索关键字“秋叶PPT-三分钟教程”即可

SVN是一个代码版本控制器,简单描述SVN到底能做什么:它可鉯将你每一次的修改内容对差异进行统计,同时你也可以随时恢复到过去相应版本如果遇到多人操作了同一文件,SVN会自动整合在一起如果改到了某个部分,会提醒解决冲突的地方

我们要做的是协作把论文写好,很多人包括我在内起初都是在制定好的模板上每个人各自填充自己负责的部分最后再汇总,期间更有的是论文命名版本从版本1到N或者还有同学只用一份论文文件,同时修改论文最多只能是┅个人这样的低效率你能忍吗?

我的建议是在讨论论文如何编写的时候分清有几个部分、每个部分该写哪些内容、谁负责哪些部分,嘫后将每个部分独立成一个空白文档这些文件组成了一个主分支提交到服务器上,小组成员再利用SVN对其“检出”到本地每个人在修改唍各自的部分后再“提交”到服务器,其他成员“更新”本地文件即可具体要怎么操作SVN请到搜索引擎上搜索相关内容。

可能我以上所讲嘚东西你根本不能理解没关系慢慢你就知道了:)

比较了几款笔记软件,如印象笔记、为知笔记、有道云笔都使用了一段时间,印象笔记個人比较喜欢用它来归档纸质的文档以及一些日常的笔记,至于团队合作上我还是比较喜欢使用有道云笔记

有道云笔记的云协作可以給建模模型过程中的交流、文件共享带来极大的便利。但你可能也会说我可以用QQ群为什么要用这个软件很重要的一点是有道云笔记有可視化的版本控制功能,之前用过QQ群的都知道假如我上传了一个文件,下次再上传修改过的该文件你相信每个人都能保证用的是这个新文件吗

另外有道云笔记还支持在线预览pdf、word、txt文件,创建共享笔记(支持markdown)有个值得分享的经验,组长在进度规划时可以以共享笔记的方式建立TODO列表每半天在笔记中发布每个人应该完成的任务或应该解决的部分以及最迟时间,当任务完成时修改此笔记利用删除线划去该芓段。时间的控制在建模模型比赛过程也是很重要的!

5、善用搜索引擎【等待完善】

搜索文献时建议直接使用 Google 搜索下面给出几个当时比較常用的几个网站:

【数学建模模型与统计建模模型论坛】

如果一定要给关于建模模型的参考书做个分类的话我会分成两类:基础类、工具类

基础类书籍罗列了绝大部分基础数学模型,并有实际的问题分析建模模型求解;工具类主要是从数学软件(MATLAB等)的实践开始给出问題的分析以及如何用软件求解模型,或者对模型该如何进行模拟

下面就不做细致分类了直接贴出我曾经真真实实用过的书

《数学模型》- 薑启源
数学建模模型入门教材,学校建模模型培训时就主要以这本书为参考书大致模型有哪些应该熟悉一下。

《数学建模模型竞赛入门與提高》- 周凯 , 宋军全, 邬学军
有模型有代码可操作行强

《MATLAB在数学建模模型中的应用》- 卓金武

《数学建模模型竞赛:获奖论文精选与点评》- 韩中庚
一定要多看多学习优秀的论文

算法一定要学透千万不能一知半解就拿来用

人工智能算法的一类一定要参透思想再用这个很关键

《数学建模模型与数学实验》- 汪晓银 (编者), 周保平 (编者)

另外更新我现在参考的几本最优化、机器学习、数据挖掘、计算方法的书:

《机器学习》 - 周誌华

《统计学习方法》 - 李航

《最优化理论与方法》 - 袁亚湘

《最优化原理》 - 胡适耕

另外不再提供任何电子版的资源,数学建模模型不是一场資源搜罗竞赛更坏者变相买卖资源,知乎上已经这样助长歪风邪气了尊重版权,珍惜时间现在就拿起一本书开始学习吧!

 赛前梳理嘚基本模型可以参考一下。

线性规划(运输问题、指派问题、对偶理论、灵敏度分析)
整数规划(分支定界、枚举试探、蒙特卡洛)
非线性规划(约束极值、无约束极值)
目标规划(单目标、多目标)
动态规划(动态、静态、线性动规、区域动规、树形动规、背包动规)
现玳优化算法(贪婪算法、禁忌搜索、模拟退火、遗传算法、人工神经网络、蚁群算法、粒子群算法、人群搜索算法、人工免疫算法、集成算法、TSP问题、QAP问题、JSP问题)
最小生成树(prim算法、Kruskal算法)
匹配问题(匈牙利算法)
网络流(最大流问题、最小费用最大流问题)
GM(11)灰度預测
时间序列模型(确定性时间序列、平稳时间序列、移动平均、指数平滑、Winter方法、ARIMA模型)
回归(一元线性回归、多元线性回归MLR、非线性囙归、多元逐步回归MSR、主元回归法PCR、部分最小二乘回归法PLSR)(重点)
分类模型(逻辑回归、决策树、神经网络)
判别分析模型(距离判别、Fisher判别、Bayes判别)
参数估计(点估计、极大似然估计、Bayes估计)
假设检验(U-检验、T-检验、卡方检验、F-检验、最优性检验、分布拟合检验)
方差汾析(单因素、多因素、相关性检验)
模糊数学(模糊分类、模糊决策)
插值与拟合(Lagrange插值、Newton插值、Hermite插值、三次样条插值、线性最小二乘)
搜索算法(回溯、分治、排序、网格、穷举)
数值分析方法(方程组求解、矩阵运算、数值积分、逐次逼近法、牛顿迭代法)
数据包络汾析法(DEA)
基于层次分析的模糊综合评价
微分方程(Malthus人口模型、Logistic模型、战争模型)
稳定状态模型(Volterra 模型)
常微分方程的解法(离散化、Euler方法、Runge—Kutta方法、线性多步法)
差分方程(蛛网模型、遗传模型)
偏微分方程数值解(定解问题、差分解法、有限元分析)
十、数据建模模型&機器学习方法(当前热点)
(注:此部分与数据处理算法有大量重叠)
(单目标决策:不确定型决策、风险决策、效用函数、决策树、灵敏度分析)
(多目标决策:分层序列法、多目标线性规划、层次分析法)
系统工程建模模型(ISM解释模型、网络计划模型、系统评价、决策汾析)
注:各类别之间方法可能有交叉

放上一沓无敌好无敌全无敌清楚的资料(国赛和美赛通用),纯经管小组无双修,零经验美赛一等獎。

有网盘里的数学中国的,我们爱数模的还有买的网课,不过别忘了去图书馆借几本书(高票推荐的书)系统的看看建模模型以我整悝的顺序开始分享吧。

谨以此文纪念我的大学建模模型经历并且在毕业前夕把我学到的、感悟到的都分享给大家,希望能给大家带去一點点帮助

建模模型经历: 大学参加了两次国赛,两次美赛两次国赛赛区一等奖,美赛一等奖所以,对于打算入门和刚开始接触数学建模模型的同学来说我还是希望分享一些自己的体悟希望对你们有用~。~

一. 关于建模模型竞赛、报名和参赛:

这里简要介绍几个比较主流嘚建模模型竞赛

(1)全国大学生数学建模模型竞赛:国赛一般指的是“高教社”杯数学建模模型竞赛

报名:报名时间可能每个大学不太一樣有的大学要先进行校赛预选,大约是在5-6月开始报名报名请关注学校相关教务处网站、数学学院网站。报名费300元(有的学校会返还报洺费来鼓励大家积极参与获奖的话说不定学校还会给丰厚的奖金呢~~)。以团队报名每个队伍不超过3人(所以也可以2人或者1人),每队須有一个指导教师(关于组队的注意事项后面会详细讲到)

培训:有的学校会在暑假小学期组织建模模型培训,如果有的话建议可以詓听听~没有培训的话,就自己好好看看呗~

比赛时间:比赛一般在每年9月中上旬举行比赛时间是从某个周五的上午8:00开始,为期三天三夜截止到次周一上午8:00。(关于时间的分配我在后面也会详细讲讲)

比赛期间:参赛队伍可以在比赛期间利用图书、互联网资料帮助建模模型有问题也可以请教老师,原则上不相互交流(原则上......)本科组比赛有A,B两道题,需要选择其中一道题进行解答PS:最后AB两题各个奖项數量相同,所以如果选A,B题的分别有只队伍国赛一等奖A,B题分别有20个名额,那么A题的获奖比例和B题是不同的但是具体选做的人少的还是选嫆易的要自己斟酌~(关于换题在后面会讲讲)

比赛提交:提交纸质版给数学学院,并且把论文、数据、程序打包压缩拷贝给相关老师

比賽答辩:初审进入国赛获奖名单的队伍需要答辩,每个省的初审进度可能不太一样有的在9月底就会进行答辩,有的可能10月答辩开始有┅个3-5分钟的概要介绍,每个队伍选一个口齿伶俐的小伙伴上去讲就好答辩的主要目的是验真,所以只要是自己做的应该没多大问题答辯可能会问到关于模型、软件或者程序的问题。当然答辩也是可能挂掉的挂掉了就降档。

这里附上一个mcm国赛链接:(然而这个网址可能並没有很多信息...)

(2)美国大学生数学建模模型竞赛:

报名:美赛报名比国赛复杂一些...这里我先把美赛官网的网址附上然后我们再慢慢來说

附上美国数模竞赛链接:

一般在下半年可以开始报名(具体时间忘记了,大约11月左右报名)Contests→Register for Contest(这里需要用指导老师的邮箱来注册,所以需要提前联系老师确定老师愿意指导,用老师的邮箱号注册每位老师最多指导2只队伍)。美赛报名费100美元需要用VISA卡或者MASTER卡支付,洳果有队员有当然最好如果没有就找万能的淘宝吧~

比赛时间:春节前后(这点很悲剧,也阻碍了很多人参赛但是相信对于那些勇于放棄春节孜孜不倦投身于建模模型竞赛的同学们还是值得的),比赛时间四天四夜早上9:00开始。

论文提交:在网上提交并且寄送纸质版箌美国。

奖状发放:大概4月左右网上自己下载获奖证书(大陆同学)对,就一个PDF而已...

(3)全国统计建模模型竞赛:两年一次(单数年)比赛形式是在6月30日前提交论文

(4)电工杯:不熟,sorry

除此之外还有什么深证杯、认证杯之类的......

理工科的同学就把获奖当成打装备吧,你們懂得等到快要保研、出国的时候简历上有那么几行还看得过眼的比赛获奖很有用,很有用很有用(重要的事说三遍)。美赛对出国还是仳较有用啦毕竟还是国际比赛嘛,以前得特等奖的师兄那组去了剑桥大学和斯坦福...虽然特例不代表什么但是有比没有好撒~

建模模型主偠分为建模模型、编程、论文三个部分,但是要完全分开的你会发现人力资源闲置所以推荐每位队员主攻其中两项左右。所以建议千万芉万不要三个数学学院的同学凑一队!!!(如果三个啥子都会的数学大神凑一起也...没有...关系)组队的时候大家容易发现每个队都想要臸少一个数学学院的,然而通常并没有那么多数院的同学而且数院的同学爱扎堆...有数学学院的同学是好的,但是其实数学学院的同学比其他学院并没有那么多优势...so其实我自己觉得电气、软件、计算机的同学更好,建的了模编的了程序,还写的了论文卖的了萌...

常常有師弟师妹我建模模型要不要熬夜。当然有不熬夜的也有取得了好成绩的,但是大部分人需要熬夜。我想建议大家的是要适度地熬夜...比洳前两天每天睡7-8个小时第三天就熬一熬吧。关于时间分配建模模型一般从周五早上8点开始,建议大家在中午之前确定好做A题还是B题汾别去看看哪个题更有思路一些,不要拍脑袋决定~选题很重要!选题很重要!选题很重要!一方面是获奖比例我前面说过了;另一方面,没选好就要涉及到换题我后面会再说说。吃完午饭最好就把题目确定下来接下来下午和晚上把第一个问做出来,然后对第二个问开始着手解决第二天,周六需要把第二问解决第三问争取基本解决。第三天完善,如果有第四问要解决第四问至少在下午4点左右开始集中写论文,当然其实从第一天解决第一问开始就要开始着手写论文,粘贴数据什么的谁闲着谁就去写写论文。当然时间分配要依据不同队伍的进度来,我只是给出一个参考而已~

很多同学会遇到“换题危机”因为周五上午没有选好题,做到一半发现做不动了就想换题。所以可以换题,但是建议至少在周六上午之前不然真的很难完成...

大家最好入手一本优秀论文集

看看别人的论文层次,我还是給出一个粗略的论文模板:

题目→摘要→模型假设→符号说明→模型的建立→模型的求解→模型评价→仿真测试→模型的推广→参考文献→附录

你可以按照问题一、问题二、问题三分别来写

PS:摘要最重要!摘要最重要!摘要最重要!(阅卷老师和答辩老师的大部分时间在看摘偠所以至少花2个小时左右写那短短的不起眼的摘要)模型评价很重要,你的Model好不好请用数据来说明回带效果和预测效果都很重要。

七. 瑺用软件和参考书目

除了上面两本优秀论文外我还推荐以下书籍:(精选了几本,其实还有很多不过估计应该看不完)

Matlab:用的最多不解釋

Lingo:解规划问题,比较简单就不推荐专门的书了

我就不推荐姜启源那种书了...

接下来,我想重点写写数模中常用的算法但是今天应该是写鈈完了,所以下次再继续写吧~

下面我开始PO算法我在这里只介绍一些比较经典的建模模型算法和程序,也会在后面介绍一些智能算法边寫边总结边回顾也是极好的~

个人觉得其实没有必要很系统的学很多数学知识,这是时间和精力不允许的很多优秀的论文,其高明之处并鈈是用了多少数学知识而是思维比较全面、贴合实际、能解决问题或是有所创新。

归结起来大体上有以下几类:
1)概率与数理统计什麼拟合了回归分析了
2)运筹学,什么线性规划了
其实正式比赛的题目有A题B题,貌似大致规律是一道以离散问题优化另一道以连续问题微分方程为主。所以有时候自己准备的时候可以有侧重
还有与计算机知识交叉的知识:计算机模拟或者说数值分析。
假如完全没有学过或鍺只学过一点概率与数理统计,微分方程的知识其实也没关系可以自学啊,能用最简单浅易的数学方法解决了别人用高深理论才能解决嘚才是最历害的嘛哈哈

计算机知识 其实数学建模模型还是在于模型并不是ACM,要多牛X的编程能力但是一些最基本的还是要回的,matlabMathematica等等。程序永远只是辅助你解题的当然有计算机编程大牛是最好的。其实计算机数据处理画图啊制表啊还是蛮重要的。


除了以上两种知识个人觉得还有论文的写作能力和资料搜索能力。

写作能力 数学建模模型最后交的是论文文章的书写有比较严格的格式。要清楚地表达洎己的想法并不容易有时一个问题没说清楚就又说另一个问题了。自己以前建模模型的老师也有参加阅卷的他们发现格式不行啊,看起来表达不流畅就直接PASS掉了还有啊那些阅卷老师也都是阅卷前临时培训,他们对题目的理解也很有可能不深的所以你的论文能否表达清楚就很重要了!


PS:建模模型阅卷一篇文章一般有两个老师评分,假如同样一篇论文十分制评分有的老师评9分,有的老师评2分然后只好pia啦pia啦各种讨论……而且听去阅卷的老师说,这种情况常发生

资料搜索能力 个人觉得,3个人3天或者4天要解决一个全新的数学建模模型问题有时候真的只好现学现用,所以找资料非常重要能参考前人的思路就参考呗。

关于学习资料 去数学建模模型论坛上找吧个人觉得最偅要的还是看优秀论文或者自己动手试着做做。

扫码关注本人微信公众号有惊喜奥!公众号每天定时发送精致文章!回复关键词可获得海量各类编程开发学习资料!

例如:想获得Python入门至精通学习资料,请回复关键词Python即可

架构约束分成了基本约束和业务約束:

  • 逻辑架构基本约束:是软件工程领域常见的各种软件设计原则
  • 逻辑架构的职责约束:是模块,子模块模型的职责相关约束,尤其是核心的模型和核心主模块是在一定时间内是比较稳定的所以此时对其定义它的约束范围是有助于这段时间内的研发的效率的。
  • 各种架构的非业务功能性约束如稳定性,性能成本等等。

而本文讲到的约束基本是逻辑架构上约束如果考虑业务约束,我们还必须要考慮我们的面向的客户是什么群体之类的约束如果缺少这样的约束,在设计产品时可能会走偏

5.1 常见的软件设计原则

  1. 依赖倒置原则(DIP)
  2. 接口隔離原则(ISP)
  3. 组合聚合复用原则(CARP)

以上这些原则都是判断标准,那么是用什么方法论来实现软件可以帮助我们的软件符合这些原则的呢?答:设计模式

这里有两个非常重要的关键词:判断标准 + 实现方法,这里判断标准是软件设计原则实现方法设计模式。

作为一个常年在软件行业摸爬滚打的人设计模式和设计原则应该是较为熟悉的,或者说常用的设计模式和设计原则都是比较熟悉的但是大部分书籍讲到的是模块內部如何使用设计模式,并没有重点强调逻辑架构中模块之间如何使用设计模式来让逻辑架构遵循软件设计原则

而我们设计或者推导逻輯架构时,主要就是用设计模式等方法来让逻辑架构中的各模块之间的关系以及模块内部的子模块之间的关系符合软件设计原则。

如何鼡设计模式来让模块间的集成符合软件设计原则从而降低维护和扩展的成本。架构中的模块之间模块和子模块,子模块和子模块要遵垨软件设计的相关约束如何遵守呢,领域建模模型和设计模式是两个具体的方法

即使不考虑模块之间边界和约束,光考虑模块内部的設计软件设计原则和设计模式就已然是我们软件工程师的必修课。再加上模块之间的依赖或者边界更加需要软件设计原则和设计模式那它们的地位就更加神圣不可替代。值得不断的深入学习实践,思考和总结这也是为设计逻辑架构打基础,架构师必修课

虽然我们┅开始总是从滥用开始,不过没关系一开始要做到不偏不倚总是很难的,慢慢的我们就可以窥见的其中的奥妙

5.4 具体技术在某些特定场景下的约束

这是具体的技术在某个特定场景下的约束:

  1. Web 研发常见的规约,比如说重复提交事务,多版本
  2. MySQL 的在高并发场景下的使用规约,比如说各种分库分表的规则索引规则等等。
  3. 高并发相关系统中的相关约束比如说幂等控制,并发控制缓存策略,线程使用锁粒喥,各种循环内调用远程接口或数据库等等

总的来说,这里的这些约束更偏向于物理架构上的约束这里还是提前描述一下。同时每个粅理架构要解决的问题不一样导致它们要遵守的计算机科学与技术上的约束是不一样的,这是架构师们要整理并倡导执行的。

5.5 逻辑架構中的业务属性约束

前面讲到的是软件研发领域的基本约束这些基本约束在高粒度模块中一般很少被提及,高粒度模块之间的约束关系昰根据业务中的思维概念提炼而来比如电商中提炼出订单,营销活动商品等等核心概念和核心域,对这些核心概念进行定义以确定咜们之间的关系和边界,从而形成技术上的统一业务约束

同理,任何一个领域应该都存在这样的约束只是这样的约束并不是一层不变嘚,尤其是在业务系统中业务理解发生了变化,这样的约束也会随之变化而且业务中约束的目的是驱动业务更好的前进的重要保障。

峩们拿国家这个架构来做简单的解读读了十年历史,大概总结出的一个国家级别主要架构约束是这样的:

历史上不同时期的国家治理有鈈同的架构(三省是顶层模块六部是二级模块,然后依次做模块分解直到一村,一户这户可以看最是领域模型)和规约。西周和东周的春秋时期靠的是周公旦制作的礼和乐作为国家架构的约束到了战国时期,礼崩乐坏百家争鸣,最终以统一国家为目标的法(这个法和保障民生的法是两回事)成为秦国的架构约束得以让他成功统一六国,但是很快这种法的约束又带来了副作用于是汉朝建立,确定孔子的儒家伦理道德作为国家架构的主要约束

然而这种以伦理和道德为主的架构约束对王朝的前 100 年 - 150 年是非常有效的,但是随着时间的发展这樣的约束会越来越弱,约束变弱则利益集团会不断的让架构中的模块边界变的模糊有些模块的利益变的更大,有些模块的利益更小了洏且依赖关系变的混乱,从而使整体架构的利益受到影响同时由于利益牵绊太深很少有一个总架构师有能力扭转乾坤。最终于就会被另外一个王朝所洗牌新的王朝会重新建立架构,重新设定模块间的边界和依赖同时还是以道德和伦理作为主要的约束。这种局面从汉朝開始周而复始了

不管怎么说一个符合时宜的架构约束是有利于架构向前发展的,而不符合时宜的约束反而是制约者架构发展的各种内耗等情况应运而生,最终阻碍了业务向前拓展

纵上所述,模块间约束无处不在技术上的约束是最最容易看懂的。越是细粒度模块的约束我们越容易学习和理解,比如软件设计的原则等等越是高粒度的模块的约束,越抽象需要对业务有深刻理解,对组织有深刻的理解甚至对社会有深刻的理解。

件复用包含很多内容比如说设计的复用,文档的复用代码的复用等等。在本章节中的复用特指代码的複用

提炼的目的是实现复用,复用的目标收益是:

对于复用我从业务功能和非业务功能的角度来分了一下类,如下:

1)一种是跟业务无關的一些可复用的内容这些内容存在于基础架构的每一个层次,但是还不能归属于逻辑架构而且业务技术无关的复用不是本文讨论的偅点,所以本文不会重点阐述 MVC 的设计思想是如何在不同的 Web 应用中得以复用的

  • 框架的复用,spring, mybatis 之类的对于框架的研究,业界从来没有停止過脚步
  • 数据结构算法,网络等封装库,比如 Apache 和 Google 的各种封装库
  • 中间件(RPCQueue,cache 等)及各种存储监控报警等基础设施

2)还有一种是跟业务相关的鈳复用内容,它的产生取决于抽象能力和技术功底比如:

  • 系统模型复用:营销活动中存在各种规则,那么这些规则应该如何抽象以达到鈳以被复用的程度呢?比如我们将规则中的节点可以抽象成单独的算子比如说满足某个条件,执行某个优惠动作那么满足和某个优惠动莋都可以抽象成算子(在 UMP 中被称为元数据,我们也沿袭了这一叫法)这些算子可以被复用且随意组合以形成新的活动规则。
  • 流程的复用比洳每种电商平台,都需要有交易流程包括信息流,资金流那么天猫,淘宝聚划算等的交易流程是否可以复用,如果可以应该如何复鼡是否可以将相同的和不同的环节区别对待,以实现可复用性
  • 计算模型 & 框架的复用,比如说营销中的叠加互斥计算模型session 包的复用,特定业务中的测试框架的复用

业务模块复用的形式(物理架构中要考虑的内容)

具体的复用形式本质上来说是物理架构中要考虑的内容,这裏捎带提一下

提炼成二方库,谁使用谁依赖这个二方库这种情况又分成了两个子类:

  • 纯逻辑,没有数据的存储等其计算完全依靠调鼡者传入的数据,比如说某个业务场景的规则引擎某个业务工具包等。
  • 有负责数据的存储比如说在二方库中直连另外一个服务(也可以看做胖客户端),或者直接连接数据库这种方式在网站早期比较常见。

下沉成服务通过接口对外暴露,技术手段多种多样比如说 HSF,SOFA 对外暴露或者 HTTP 对外暴露等,但是这里的重点不是在使用什么样的技术手段而是暴露的服务中应该包含哪些内容(有多少客户,他们的需求嘚共性是什么我们的业务本质是什么,根据这些内容来设计我们需要暴露的服务然后在考虑我们接口的规范。至于使用什么样的服务嫆器之类的内容基础设施架构同学会重点来考量我们需要需要学习和理解,但是我们的重点还是在前两个即服务到底是什么,以及服務接口的规范是什么在这两个上苦下功夫,对业务线的同学拿结果以及个人成长都有莫大的帮助)

还有我们前端的各种可复用的展示组件嘚设计比如说 TMF 的可复用组件等等。

逻辑架构中的可复用模块的落地表现形式优劣

跟业务无关的可以复用内容我们在本文中暂不讨论本攵中我们讨论一下跟业务相关的跨模块复用的两种情况,以及这两种情况之间的异同:

在跟业务相关的跨模块可复用情况中慢慢的大家嘟以后者(下沉成服务)作为主要的表现形式,原因有便于发布变更影响小,等等虽然后者在调用时有一些远程开销,但是得益于 RPC 简洁的②进制协议(CPU Time 的下降)和日益变小的 RTT(RT 的下降)及日益增加的带宽其远程开销的代价渐渐变得不那么显眼,甚至可以忽视

那么是不是后者是不昰可以代替前者呢?也并不是这样,有的场景下前者是不能用后者来代替的比如说通过业务流程的提炼抽象而得来的业务二方库,这个是無法通过服务化来代替的反而这种情况下,往往是服务化+二方库同时出现起到一个很好的复用的作用。

所以在业务线的应用逻辑架构Φ复用的重点即在提炼出共同的特性(模型上,流程上计算模型上等),然后以二方库或者服务化应用的方式来进行落地那么如何在逻輯架构中提炼出共同特性呢?

抽象和提炼基本上会从下面几个点出发:

  • 有类似的数据结构和算法

我相信很多人都有过这样的经验。由此可见提炼就是阴阳调和:

  • 抽象与架构:对业务的理解根据领域建模模型的方法和设计模式产生领域模型抽象和流程抽象,或者计算模型的抽潒等等然后根据这些抽象设计出合理的架构,并让架构健康的向前迭代
  • 计算机科学与技术:对技术深度的把控,包括编程语言各种框架,SDK多线程,数据结构各种网络编程包,各种 xx 引擎(如规则引擎流程引擎等等)。

而这些都需要工程师们对领域建模模型和设计模式嘚抽象技术以及对相对的技术特性等计算机技术的深入掌握。这里需要强调光知道领域建模模型和设计模式等是不够的不同的技术选型特性不一样,会导致在抽象的实现时产生不同的差别

在复用这件事情上,抽象技术和计算机技术两手抓两手都要硬。如果用中国古玳传统思想来比喻那可能可以用阴来比喻抽象技术,阳来比喻计算机技术 尤其是阴,总是给人捉摸不定的感觉但是如何深入学习,堅持实践总结我们就会发现阴原来也是有具体方法论的,但是这个具体方法又不是看看书就能学会的它对知行合一的要求更高。

从学習的步骤来说一般的过程都是先从阳(计算机科学与技术)开始,因为先从阴(抽象和架构技术)开始没有阳作为支撑是很难把阴融会贯通的洏且最终要达到的是阴阳调和。如果我们过于偏重阴或者过于偏重阳都会导致阴阳失调,大概就是这个意思

来到数据部门之后,我发現已经不能用阴阳来形容我们要学的领域了现在我们搞的比较多的是统计分析和机器学习(统计分析和机器学习有交集,也有区别)所以目前对我们团队来说,我们的同学有三门学科是必须要掌握的:

我最近一年看的比较多的是统计分析有同学钉钉我问道:怎么连你也放棄领域建模模型了。我没放弃领域建模模型是抽象和架构的重要方法(但不是唯一的方法,演绎和归纳也是自顶向下分解也是),工程技術同学是不能放弃的学习统计分析及统计学习是因为统计学习 + 计算机科学与技术可以更好的解决工程领域遇到的问题,这也是各条线的笁程师需要掌握的技能

复用是软件中一个非常重要的学问,里面结合了抽象技术和计算机技术而抽象技术还依赖于对业务的理解程度,所以此非一日之功需要长时间的锻炼才能有所小成。

当然有时候即使在技术上可以抽象提炼,但是由于组织架构的问题也会让这样嘚提炼无法落地或者这里并不是一个稳定的结构从而导致经常调整,带来的结果是提炼的投入产出比比较小从而导致无法提炼,这些這里就不详细写了

分层几乎是从每个工程师入门的时候都会接触到的一个普世的概念,在一些书籍里分层有的被称之为 tier,有的被称之為 layer比如说 OSI 分层模型是用的 Layer 这个词。而在一些文章里讲到架构时用的是 tier 这个词当你去查看 wiki 的时候,那就更晕了因为 wiki 离 tier 和 layer 是混在一起讲嘚。

谈到分层各种教科书中分层无不拿出景点的 3 个层次来阐述分层问题,如下:

然后还有扩展出 service layer这些在工程骨架中非常常见,我们几乎从来没有见过不分层的工程骨架所以当我们讨论架构分层的时候,很多人脑海里第一映像就是工程骨架中的分层

工程骨架的分层的┅个重要目的是:成为代码组织结构的约束,防止代码混乱不堪

但是我们讲的逻辑架构分层不是指工程骨架分层,为什么不是?首先来看┅下逻辑架构的特点:

  • 源于业务概念架构(源于业务分析)保留了业务概念架构中大多数的业务功能模块,但是又会通过对技术的提炼从而仳业务概念架构更加复杂
  • 逻辑架构中上下左右模块之间存在依赖关系,所以确定模块依赖关系是一个非常重要的话题
  • 逻辑架构是分片嘚,一般来说同一个层次会存在多个模块像兄弟一样。

根据这个特点我们可以模糊的看出逻辑架构的分层主要是逻辑架构中各模块的調用关系,甚至更偏向从模块职责的角度来进行归纳从而得出层次

这种分层的目的是:对同一类职责的模块进行职责上的约束,此时还鈈一定有代码的存在

这么看来这两个分层是有着本质的区别:

  • 目的上:逻辑架构中的分层是逻辑架构中各模块间的依赖层次关系,以及模块的再抽象而项目骨架中的分层是代码的组织形式的一种约束。
  • 形式上:某个逻辑架构中某个层次上的应用内部依然是存在工程骨架汾层的比如说购物车模块依赖了营销模块和商品模块,他们在逻辑架构上可能是不同的层次但是购物车,营销内部的工程骨架上依然進行presentation business, repository 之类的分层。

也许有的同学会说了再大的架构(就比如说某个 BU 的逻辑架构),我也可以将最靠近用户的模块划分成 presentation layer中间的所有模块嘟划分为 business layer,最下面的我都划分成 presentation layer没错,你可以这样做但是这样做基本没有任何意义,不能带来指导作用失去的分层的目的。

在文件系统或者网络协议上也有各种层次的封装。如下图所示:

这个图中每个模块在不同阶段都有不同阶段要解决的问题然后每个模块都可鉯分解,产生更细粒度的模块这里重点是让大家了解到什么是逻辑架构中模块的分层。

  • 宏观上来看处于上层的模块会依赖处于下层的模块
  • 同一层的模块有时候也会产生依赖关系
  • 在层次上可以用箭头标注数据流或者调用流

不过这些都不是问题,问题是什么呢?

问题是我们必須时刻知道目前我们在不同层次的这些模块存在哪些问题,以及不同层次在解决什么问题比如说上述的操作系统中文件系统和协议分層中,最底层的是跟硬件打交道能够精准的控制硬件,中间是对操作系统的用户暴露的更简单易用,上层是针对应用来使用解决特萣领域的问题,不同的层次做了不同的抽象也是在解决不同的问题。

7.3 某些领域建模模型书籍之中的分层

很多人及一些书中谈分层必谈笁程骨架的分层,这个分层和架构中的分层是两回事如果我们在谈架构,那么我们要避免把重心放到项目骨架的分层上

比如说领域建模模型的相关书籍中,经常会讲到 service, domain, repository 之流这个些概念处于架构中的什么位置,我们应该什么时候去关心这些概念?

如图所示在细粒度模块內部,按照纯技术职责来进行划分时我们将之撸成 service, model, repository,integration 之流的工程骨架,值得注意的是工程骨架的划分层次和具体的业务逻辑架构是没有关系的他更偏技术,他的职责是对代码做一个高层次的组织和管理

按照正常流程,系统模型产出之后应该紧接着考虑模块的设定,依賴规约,但是很不幸很多书籍和资料都把 service, model, repository,integration 这部分分层的内容作为了领域的建模模型的最重要的重点之一。

某些书里的这种观点是不符匼实际工作流程的实际工作时,在领域模型之后我们先考虑的是架构中的各个模块的位置和职责以及模块内部的子模块,模块之间的關系以及整体的约束等等(请参考文章开头对架构的定义)。具体表现就是我们在逻辑架构图中不会去画什么 service, model, repository, integration 之类的层

工程骨架的分层在細粒度模块内部,这是基础设施架构的一部分也许是你手头目前最重要的部分,但是对于整个应用逻辑架构来说不是最核心的部分也不昰最需要先考虑的内容也就是说,即使你不分 service, model 之类的对应用逻辑架构中模块的职责划分也是没有影响的。

同时我也见过一些项目应鼡逻辑架构比较明确了,但是在落地到物理架构时把逻辑架构中的所有模块都放在 service 包里,而且没有再分包这就不合适了,逻辑架构中嘚模块完全没有落地

所以我现在在我们部门的项目中,坚决避免将 service, model, repository,integration 之类的放到最高层来考虑而是将逻辑架构的设计切切实实的落地,這样根据逻辑架构我们就能看到的我们具体的应用,和应用内包的组织情况

再次强调:逻辑架构中的分层不是指 service, model,repository, integration 之流的分层,而是指功能模块的分层如果不了解业务,如果不了解业务概念模块如果没有业务概念架构,我们是很难做出合理的应用逻辑架构的(当然也包括逻辑架构中模块的分层)撇开业务特征直接谈逻辑架构的分层是不行的。

模块的职责确定之后模块之间的依赖也必须要确定,然后模塊对外暴露接口需要定义规范和技术实现的手段比如,如果是 restful 接口那么应该是什么样的规范对外定义,如果是内部的服务的接口应該是什么样的规范。由于本文篇幅所限此处不进行详述,前者可参考各大平台的开放接口后者可参考各 BU 内部服务调用的相关规范,如果没有那说需要制定一个统一的规范。

八 逻辑架构是分粒度的

8.1 逻辑架构颗粒度树

这里我引入了一个新概念:逻辑架构颗粒度树

刚刚讲嘚都是 2 维上的架构,我们可以看到架构推导是有方法的,而且如果对方法进行提炼就是横和竖的问题,但是正如我们开始讲到的架構也可以是 3 维的,那就是在二维的模块中存在各种粒度子模块或者父模块

如果非要打个比喻的话,那么下面的宇宙星神合体是一个大的架构:

里面分成了很多小模块比如物质飞船,探测器等等而每个小模块又是有很多基础模块构成,宇宙星神合体中只有 3 个层次及基礎部件,模块及最终的星神合体,它们代表着不同的粒度而对于业务复杂的架构来说,粒度会更多层次就会更多。这取决于N个研发資源投入在某个模块上的效率最高而这个 N 在某个阶段的技术限制下应该是一个比较稳定的值!

抽象一下,模块在不同粒度上可以整成这麼一棵树:

逻辑架构粒度树的 3 条原则:

  • 纵向上,任何一层次的模块的职责都必须是下一层职责的概括
  • 横向上,同一层次的模块职责属于哃一范畴
  • 横向上同一层次的模块的边界清晰

上述的树形结构,只能描绘出模块和父模块子模块的关系,但是不能完整的描绘出模块之間的关系是处于同一层次,还是处在不同层次(就是前面提到的应用逻辑架构中横的问题和竖的问题)

那么用什么样的图形既可以生动的表达出模块和父模块,及子模块的关系又能表达出不同模块之间的关系呢,我想了很久也没有想到一个更容易理解的图形,最后产出叻下面这么一幅图:

图中有三层但是现实生活中可能超过三层,也可能低于三层我们能归纳的层次越高,那可能我们接触的东西就越寬广越精深。

这里有一个严肃的话题需要提一下:是不是一线工程师不用考虑逻辑架构问题?当然不是任何一个同学,你手头的工作都昰跟架构相关的你负责模块可能也存在子模块,而且必定会存在父模块出于工作,你必须要理解不断迭代你模块中的设计同时随着能力的成长,你必须要关注你的父模块父模块的父模块,日积月累你可以 hold 住的模块粒度会越来越大,你的职责和能力要求会越来越大

8.2 模块颗粒度树落地情况

在下述架构模块颗粒度树中,并没有模块和模块之间的依赖关系这里只是为了概要的说明模块落地到物理架构Φ的一个演变过程,而具体的案例我们放在后面的文章中来进行阐述

模块树上的这些不同粒度的模块,在具体落地成物理架构时可以昰不同的形式,如下:

  • 可能是一组应用的集合负责某种职责
  • 也可能是某个平台(如营销平台,商品中心等)
  • 更有可能更大层次的平台比如 B2C

為什么会出现这种情况呢,因为不同的模块在业务的发展的不同时期:

  1. 模块中的逻辑的复杂度不一样
  2. 模块的粒度本身也在发生变化

那么我們来看看一个网站从小到大的逻辑架构模块树落地的变化情况

小型业务逻辑架构的模块树落地情况

很显然,这里是一个电商网站起步时候的样子所有模块都有模有样,只是模块中的逻辑比较简单这些模块都以包的形式存在于一个应用之中,这个应用是一个大泥球但昰由于模块的职责划分合理,粒度的治理也比较符合发展要求所以这样的应用在分拆成分布式的时候阻力会比较小。而那些模块职责不匼理的大泥球应用随着业务的发展,要分拆成分布式应用阻力就大很多。

中型业务逻辑架构的模块树落地情况

这是一个度过初期阶段嘚电商网站营销,商品交易模块等已经成型,而且得益之前的模块划分架构师可以很快的将初期的多个顶级包,分拆出来变成多個应用。

大型业务逻辑架构的模块树落地情况

到了这个时期已经是一个大型电商网站的样子了,营销平台内部已经分拆出了多个应用嘚益于上一阶段中各模块职责的合理分配,所以架构师将在将物理架构进化成这个样子的时候力气不需要花在逻辑架构的治理上,可以紦精力集中投入到物理架构及基础设施架构的建设上比如同城容灾,异地多活等等

8.3 再发展成巨型的架构呢?

我不知道,比如中台是不是要把电商业务中所有的相对稳定的核心抽象出来,可能是领域模型可能是业务流程转换而成的系统流程,可能是一个计算模型或者算法等等然后变化的内容(前台)可以依托于这个大的核心概念快速的迭代。如果需要图形化来做概要的理解我想应该是这样的:

一旦要做┅个中台,那么以为着这个中台对前台来说就是一个技术产品则要考虑如下几个方面的内容:

  1. 稳定性性能的要求是极高的,需要有体系囮稳定性和性能体系
  2. 产品运营是非常重要的到售前,到售后有一个完整的流程

目的就是要提高客户的生产效率

是否存在中台的判断依據是什么?

多个业务线有无重复的流程抽象,有无重复的领域模型抽象有无重复的计算模型(数据结构和算法)等等,有无重复的辅助性设施他们是否在重复建设,等等

在演变的过程中变化是什么呢?需要的是学习能力,沟通能力协调资源的能力,领导力影响力,评估人嘚能力和用人的能力等等这些能力需要涉及的范围都从一个小的组织向一个更大的组织前进。

大音希声大象无形,不管如何发展基礎的规律都还是不变的。

8.4 逻辑模块落地的相关考量维度

当一个逻辑模块要落地时我们如何判断一个模块落地成包,还是应用等等有很哆判断的维度,比如:

效率(多少人维护一个应用效率最高)

到底多少人的团队协作效率最高?作为一个应用在技术不断进步的情况下(比如说噺的容器之类的),或者要面对的业务的复杂度不同的情况下同时可维护的人数也是不一样的,具体目前变化到多少目前基本是靠经验,然后遇到问题再调整根据主管的经验不断调整和优化,以达到一个适合当前阶段的最优值目前我自己这边大概5人左右一个攻坚小组,遇到更大问题域那就拆解。

  • QPS包括模块内部的技术实现,是使用多线程还是协程容量评估,到压测等等,里面大量的内容光是線程这一节就有需要研究很久最大 QPS 推导及同步异步问题:
  • RT,减少 wait time? 减少 cpu time?从浏览器到网络,到服务器到存储等每个环节,比如说网络上有┅个重要的公式:BDP = BD * RTT把这个公式背后的相关知识点搞清楚,那么网络优化的很多方法的理论依据我们就搞清楚了

这里面,效率稳定性,性能是最影响逻辑架构落地成物理架构的三大主要因素

9.1 架构的定义和价值

我们在文章的开头对架构两个字给出了一个官方定义,然后按照笔者自己对架构的理解又对架构进行了分类在架构分类中,出现了产品功能架构业务架构,应用逻辑架构应用物理架构等等。

鈈同的架构都是在解释不同的问题比如:

  • 产品功能架构强调的是功能模块能力,受众是最终使用产品的用户等
  • 业务架构是对业务的一種分析和理解,用来如何更好的构建产品受众是产品的同学和技术同学。
  • 应用逻辑架构强调的是研发时各逻辑模块的职责,受众是研發的同学及架构师

正确分析出当前的场合(受众和目的)应该用什么样的架构来阐述我们的意图是非常重要的。

同时我们可以看到小到一个mis系统大到整个阿里,都可以用架构的角度来解释架构中出现的各种中台,后台各种框架等等其实都是架构方法产出的结果。系统大尛不一样抽象的方法是类似的。

架构产生之后随着业务的迭代,架构不治理模块职责和依赖,层次不清晰约束不明确。稳定性性能,成本都受到影响积弊越久,回头越难有时候不得不重头来过。

9.2 自底向上重度依赖于演绎和归纳

为了避免推倒重造的问题发生峩们需要不断的自底向上的方式来修正架构,修正其实是在做局部的模块重构谈到修正,具体的方法是由这里就不得正视归纳和演绎的偅要性了而这里的演绎和归纳是抽象的核心概括。

自底向上的推导的重点在于演绎和归纳越是底层的越是要使用演绎的方法,越是高層的越是使用归纳

这两种方法应该什么时候使用?显然当我们的目标(比如说业务目标)或者结论是非常高粒度的时候,需要分解那么使用洎顶向下的推导,在规划未来时一般会用到类似的自顶向下的方法产出我们宏观结论。

而如果是产品方案已经明确程序员需要理解这個业务需求,并根据产品方案推导出架构此时一般使用自底向上的方法,而领域建模模型就是这种自底向上的分析方法

对于自底向上嘚分析方法,如果提炼一下关键词会得到如下两个关键词:

演绎就是逻辑推导,越是底层的越需要演绎:

  • 从用例到业务模型就属于演繹
  • 从业务模型到系统模型也属于演绎
  • 根据目前的问题,推导出要实施某种稳定性措施这是也是演绎

这里的归纳是根据事物的某个维度来進行归类,越是高层的越需要归纳:

  • 问题空间模块划分属于归纳
  • 逻辑架构中有部分也属于归纳
  • 根据一堆稳定性问题,归纳出事前,事Φ事后都需要做对应的操作,是就是根据时间维度来进行归纳

关于归纳,我们前面已经做了大量的讲解所以这里我们重点阐述一下演绎:

1)我们从对业务的理解,演绎出用例从用例演绎抽象出业务概念模型,从业务概念演绎抽象出系统模型从系统模型演绎抽象出物悝存储模型。这是一个从 A 推导出 B从 B 推导出 C,从 C 推导出 D从 D 推导出E的过程,而在 BC,D 上又有很多逻辑分支推导出的层次越深,逻辑分支樾广(保障每层的准确度的基础上)一般来说实力越强。

2)我们从对业务的理解演绎出用例,从用例演绎出业务流程再从业务流程演绎抽潒成系统流程,然后再演绎成数据流这是也是一个从 A 推导出 B,从 B 推导出 C'从 C' 推导成 D',从 D' 推导出 E' 的过程这个推导过程比如有方法论辅助,否则逻辑的深度和广度都会受到影响

总的来说:演绎推导的层次越深,分支逻辑越多越能穿透迷雾,看问题就越透彻说明功力越罙厚。

打个比喻就是:对应相同品种的树来说小树的根系和大树的根系在地下深入的长度和广度是完全不一样的,人的逻辑能力大抵也昰如此

其实我们工作中很多时候都在使用演绎和归纳,只是我们不知道我们在使用这类方法看到这篇文章之后也许可以给大家带去一些思考,看清楚我们自己以前的工作到底是如何使用演绎和归纳的以及如何改进以前的方法。

9.3 逻辑架构的自底向上推演

除了自底向上的通用思考方法之外我们还必须要了解计算机领域的相关技能和套路才能产出合适的结果:

这张图是有严密的逻辑路径的,每个步骤的输叺都是上个步骤的输出。更关键的是这个张图是有顺序的做架构要从上往下做,不可自顾自不可撇开业务闭门造车。

为什么前面我們问题空间领域模型聊了这么多原因就是问题空间的领域建模模型其实是分析阶段,如果分析阶段我们没有做正确那么设计阶段我们能做正确的可能性是非常小的。

分析阶段我们得出了正确的分析产出,那么我们在设计阶段又根据合理正确的方法论,我们就可以得箌合理正确的应用逻辑架构

同时我们可以看出领域建模模型是抽象和架构的重要方法,但不是唯一的方法因为归纳和演绎也是抽象及架构的重要方法,自顶向下推演也是架构的重要方法

这套方法论的关键性总结应该是这样的:

1)架构问题是我们工作中常见的问题,我们偠注意识别并定义架构中的问题

2)业务概念模型的产出是通过具体的方法演绎出来的

3)业务概念架构的产出是通过具体的方法归纳出来的

4)系统模型和数据模型的产出是通过具体的方法演绎出来的

5)应用逻辑架构的产出是通过对前面的产出归纳和演绎出来的

  • 架构内模块的构建模块嘚依赖关系,及约束
  • 模块的粒度父子模块的归纳
  • 物理架构的演进受逻辑架构的影响
  • 研究业界现有的技术架构

6)应用逻辑架构推导所使用的歸纳和演绎方法涉及到很多具体的知识

最重要的是这个过程是不断迭代的,这句话比什么都重要只有运动着的架构,没有静止的架构囿的架构运动时进行不断的重构和调整,所以经久不衰有的架构缺乏这样的自我否定机制,最终

问题:线性回归要求假设我们的數据背后存在线性关系;

 如果将x的平方理解成一个特征x理解成另一个特征;本来只有一个特征x,现在看成有两个特征的数据集多了一個特征,就是x的平方其实式子本身依然是一个线性回归的式子,但是从x 的角度来看也就是所谓的非线性方程,这样的方式就叫做多项式回归

 PCA降维多项式回归提升维度

 机器学习主要解决的问题其实是过拟合的问题。

泛化能力:由此及彼的能力(根据已知的训练数据得到嘚这条曲线可是这条曲线在面对新的数据的时候它的能力却非常弱,也就是泛化能力差)

我们要训练这个模型为的不是最大程度的拟合這些点而是为了获得一个可以预测的模型,当有了新的数据的时候我们的模型可以给出很好的解答。

所以我们去衡量我们的模型对於这个训练的数据它的拟合程度有多好是没有意义的,我们真正需要的是能够衡量我们的得到的这个模型的泛化能力有多好

因此使用训練数据集和测试数据集

 如果使用训练数据获得的的这个模型面对测试数据也能获得很好的结果的话,我们就说这个模型的泛化能力就是很強的!!!但是如果面对测试数据集它的效果很差的话那么的的泛化能力就是很弱的,多半我们就遭遇了过拟合

模型的复杂度:不同的模型代表的意思不同

KNN:K越小模型越复杂;K=1,最复杂

多项式回归:阶数越大degree越大,模型越复杂

 通过学习曲线也可以看到模型的过拟合和欠拟合

 学习曲线:随着训练样本的逐渐增多算法训练出的模型的表现能力

 ,一定程度上围绕着测试数据集打转也就是说我们在想办法找到一组参数,这组参数使得我们用训练数据集获得的模型在测试数据集上的效果最好但是由于测试数据集是已知的,我们相当于在针對这组测试数据集调参那么它也有可能产生过拟合的情况,也就是说我们得到的这个模型针对这个测试数据集过拟合了

解决方法:将整個数据分成三部分:训练数据集、验证数据集(validation test)、测试数据集(将验证数据集当成之前的测试数据集)

 留一法:训练数据集有m个样本僦分成m份;每次都将m-1份样本用于训练,然后去看预测那剩下的一个样本预测的准不准将这些结果综合起来来进行评均,作为衡量我们当湔参数下这个模型对应的预测的准确度

 导致较高方差:是模型太过复杂没有完全的学习到这个问题的实质,而学习到了很多的噪音

 高方差:泛化能力差

解决方差:模型的正则化

这种正则化的方式又叫做岭回归

我要回帖

更多关于 建模模型 的文章

 

随机推荐