《系统架构》是一本由爱德华·克劳利（Edward Crawley） / 布鲁斯·卡梅著作，机械工业出版社出版的平裝图书，本书定价：119.00，页数：2017-1，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《系统架构》精选点评：
●小弟翻譯的書，請大家多多指教。
●将系统架构这么多变的过程进行了较结构化地拆分和详述。 讲形式与功能的映射，以及功能的涌现等内容非常精彩。
●可以说是手把手教你系统思维和创建系统架构的教科书，需要一些基础，不然会看的比较累
●精华思想集中在第一分。架构本质也是一种管理，需要考虑更多因素的去衡量
●* 一刷。看着有点头疼。各种给概念和形式语言，找个时间再读。 * 作者用系统思维来讲述系统以及系统架构。文中给出架构师的 3 个职责：消除歧义、创造概念和管理复杂度。之后有给出了架构的评估方法和优化的方法。
●陆军副长写推荐序也是蛮硬核的，断断续续1个月读完了，4星推荐。 有过一定工程经验后回头看能找到不少方（心智模型，系统思维，架构原则）上的共鸣，整书的行文编排真是少见的出彩，每章节通过问题引开，逐一深入，再要点总结。真是为读者考虑周全，或许因为偏向硕士教材的缘故吧。 虽然还是会忍不住感叹，最后几章在程序化解决架构设计决策优选的问题上有些隔靴搔痒。有时想想，这般心思也很危险，还停留在有本武林秘籍就能称霸天下的幻梦里。或许关于这个实践工程问题本身就够写几本书了（数据挖掘，机器学，启发式算法，NP 完全问题…）。 如此看来市场（CS）里绝大分工程架构更多都只能算设计吧。面向经验，直觉，可规约似的架构（一步步趟出来的）。毕竟创造力这种东西有时候是和审美相关且难以量化和昭示的
●好的入门加工具书
●对自己有帮助的就第一分，后面快速过了，可能是境界太低吧，大分内容没耐心看
●第一遍细读理解之后，时隔几个月在应用的过程中回看和巩固，受益无穷
●一切皆架构
《系统架构》读后感(一)：可能是一处翻译问题
5.5.1 功能交互与功能架构， 最后一句话，
在这种简单的流式系统中，有一种非常特殊的操作数，它由上游的过程所创建，并且由下游的过程来销毁，这种操作数构成了交互。”一种非常特殊的操作数“的意思很难理解。原文为，
In such simple flow-through systems, there is a unique operand that is created by the upstream process and destroyed by the downstream process, which constitutes the interaction.原文中的unique，应为”唯一“的意思。
这段话的意思是说，简单系统中的上下游过程交互只涉及唯一的操作数，它由上游过程创建并由下游过程销毁。如下图所示，
Figure 5.12 internal functions and functional architecture of bread slice making.《系统架构》读后感(二)：系统架构2：分解-管理复杂的利器
原创 精进学思行
看到上面两张图，你有什么感受？你最直观的可能是：一个比较有条理，一个比较杂乱。它们实现的功能可能是完全相同，但是如果出现了故障，检查起来，可能困难程度就不同了。我们在《为什么需要生物学思维》：有限认知，如何应对日益复杂系统？提到了通过生物学思维应对复杂性，本文继续分享应对复杂的一种比较传统，但是很有效的方法——分解。
1 复杂VS难懂
在英文中有两个词很精确地表述了上述现象：Complex和Complicated，不翻译过来是复杂和难懂。复杂指的组成系统的要素或者实体，高度相关，相连和混杂。而难懂则是指是否超出了人的观察和理解能力，上面的图片中，本质上都是比较复杂的，但是后者明显比前者更好懂。
在生命是什么？中，我们明白复杂化系统提高动态稳定的重要方法，在《为什么需要生物学思维》：有限认知，如何应对日益复杂系统？我们分享了系统越来越复杂的两个重要原因——吸积和交互，在这里再补充一个——功能需求越来越多，以前的手机只需要能通话就行，现在的手机通话已经退居次要地位，而功能的增加通常也会导致复杂度的增加，我在工作中深有体会，一个公司中，工程的人最怕市场的人不断加功能或者需求，比如你看别人的车能跳舞，我们可不可以比他们更炫，不经跳舞，还会唱歌？
虽然在《为什么需要生物学思维》：有限认知，如何应对日益复杂系统？中，我们提到用生物学思维应对复杂系统，但是在建构系统的时候，还是要有人懂这个系统，那就需要区分三种不同的复杂度概念。
2三种复杂度
在《系统架构》中提到三种复杂度：必要复杂度，实际复杂和表面复杂度。
必要复杂度：系统保持一定功能和性能的最低复杂度；
实际复杂度：实际实现功能时的复杂度；
表面复杂度：看上去的复杂程度。
比如，我们为汽车选择动力系统的时候，可以是纯内燃机（自然吸气，涡轮增压等）、纯电动和混动，如果只是为了能让车动起来，那么是存在一个最小复杂度的动力系统，这就是必要复杂度；而我们实际和设计动力系统，因为存在一些不够优化的设计，导致实际复杂度高于必要复杂度，表面复杂度和前两种常常是相反的，因为表面复杂度是人们常常接触到的复杂度，为了提高人们的使用界面的简洁，常常背后是异常复杂的，比如苹果手机，我们使用时很简单，小孩不用教都能学会，但是背后需要复杂的系统支撑。
还有一个工作中常见的现象，就是在沟通中，呈现同样的问题和信息，有的人只需要用1页PPT就能把问题讲的清晰明了，而有的人可能用了几十页，还是让人一头雾水。为什么？我的观察是，1页纸看上去很简洁清晰，但是背后可能进行大量的整理和思考，将复杂化留给了自己；而后面的几十页，看似做了很多工作，但只是大量信息的堆砌，将复杂的处理留给了听众。
复杂是难以避免的，但我们的认知有限，所以，需要在复杂和难懂之间做平衡。正如《系统架构》中提到：好的系统架构就是具备必要复杂度，同时又不难懂的系统。有什么好用的工具？分解。
3 如何分解？
3.1分解方向
分解的时候通常有两个不同的方向：上下和内外。上下分解有可以分为自顶向向下和自底向上，最典型的就是产品中的V字型，从整体分解到件，再从件组装为整体。
内外，就是从内到外，或者从外到内，最典型的就是人的关系——由亲到疏，以及我们常说的“修齐治平”，当然这两种分解分解方向也可以交替使用。
3.2二下一上
这是《系统架构》中提到的一种重要的分解原则：
如果要判断Level1分解是否合适，必须深入到Level2中。
这里把Level0看成是将要被分解的整体，Level1是分解后的第一级，Level1是分解后的第二级。为什么这个原则重要？因为分解后，如果能够让组内的元素耦合度比较高，而组之间的耦合度低，有利于模块化，并减低沟通成本，而Level1分组所需要的信息，包含在Level2的互动中。
而我认为，如果有必要，甚至要再往下多分解几层，那么我们最多可以分到什么程度呢？最后合理的应该保持在几层呢？
3.3原子件和模块
我们可以分解到什么程度？古希腊人用“原子”表示不可再分，在系统分解中，我们将其定义为“原子件”，这个定义比较模糊，用途不同，指代的不同。比如，对于整车厂，到零件就可以了，典型的如螺栓，但对于螺栓零件公司，可能还需要再分解为1字头、十字头，什么螺纹等，比如是用一字头还是十字。《系统架构》中提到一个基本判断原则：不能再拆解了，一经拆解就失去了意义。
如果每个系统，我们都分解到原子件，很容易超出人们的理解程度，所以需要降低其表面的复杂度，一个重要的方法就是模块化，将原子件集成为各个模块。我们在使用的模块的时候，常常不需要关心模块内的具体内容，只需要知道模块的功能和结构，典型的就是芯片的使用，对大多数使用芯片的人，关心的只是输入和输出。
模块不仅可以降低表面复杂度，而且对系统修理也比较容易，常常只需要更换换掉的模块就可以。那是不是模块化越多越好，其实也不然，因为如果模块太多，那么你就要定义很多的接口，而接口的数量的增加其实也会增加复杂度，另外，模块通常就意味着里面有一些模糊的东西你不知道，存在黑箱，你是不清楚里面究竟发生了什么？
3.4分解面
对于分解而言，除了前面提到的方向和深度，还有一个重要方面是——分解面（也叫分解平面），通俗讲就是我们从哪个角度进行分解，比如对人群，我们可以按照年龄、性别，职业等进行分解，分解面的选择，不仅影响人们的理解程度，也会影响系统最后功能的涌现以及架构的美观程度。
以汽车为例，我们可以按照构成分，将其分为车身，底盘，电驱动等，也可以按照性能/功能分为加速性能，制动性能，储物功能，舒适性能都等。在金字塔原理：结构思考，清晰表达中，我们也分享了多种分类的方式，它们也是典型的分解面。
在《系统架构》中提到了13种常见的分解面，最典型的如形式、功能、设计自由度等。
总结
表面越简洁，可能底层越复杂。为了实现特定的功能，一定的复杂度是必须的，这被称为必要复杂度，而实际系统的复杂度常常超出必要复杂度。而人的认知能力有限，在保持必要复杂度同时，又不能让其难懂（表面复杂度）。在这个过程中，分解是重要的手段，分解需要考虑：方向，分解深度和分解面的选择。
《系统架构》读后感(三)：系统架构3 ：如何用简洁图形描述系统架构？
精进学思行 精进学思行 今天这周在和其它门讨论一个工程问题的时候，对于其中一个细节大家有不同的理解，“空对空”讨论很久无果，直到有人拿出了一张系统架构图，明确指出有争议的点，大家才迅速结束了争论。
对于复杂的系统，其中包含很多要素及其交互关系时，如果没有一个清晰的沟通载体，常常容易出现大家的理解偏差。在系统架构2：分解-管理复杂的利器，我们分享过应对复杂度的一个有效工具是分解，但分解完成后，常常需多方协作完成，这就需要彼此都能够很好理解整个系统或者是自己负责的业务。一种常见的方式是通过文本的方式对系统进行描述，但这种描述常常不够直观和准确，沟通效率偏低。 有更好的方法吗？在画图：一种简单高效的思维和沟通工具中，我们分享过通过画图可以更好沟通和交流，而在系统工程领域，前人已经提出两种有效的描述系统架构的图形化语言——OPM（Object Process Methodology）和SysML（Systems Modeling Language）。这两种模型都是比较精确的语言模型，用图形的方式展示了整个系统的结构，本文先简介OPM。主要从如下几个方面介绍： OPM是什么？OPM的关键要素：对象和过程对象和过程如何连接构成系统？ 1 OPM 是什么？ OPM 的全称是"Object Process Methodology",直译过来就是“对象过程方法”，是由以色列理工学院的Dov Dori教授研发出来的，它的目的是将面向对象的图表和面向过程的图表综合到一套方法中，更方便对系统架构进行描述。什么是面向对象和面向过程？它们都是来自于计算机软件领域。 面向对象，是把构成问题的各个事务分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描叙一个事物在整个解决问题的步骤中的行为。 面向过程，是把问题分解为题各个步骤，关心的是如何通过步骤的实现来解决问题。
以公交车载客为例，如果是用面向对象的方式描述，就会把整个系统分为公交车，司机，乘客，车站等，然后分析它们在整个系统运作中的互动关系，关注的焦点是对象；而如果是面向过程，则会把整个从过程拆解为“载客-启动-到站”，关注的焦点是过程。 而OPM方法就是把系统架构中涉及到的对象和操作过程整合到一起，而且因为其简洁和准确性，现在已经成为了ISO标准,本文的大分内容引用的就是《ISO/PDPAS 19450Automation systems and integration — Object-Process Methodology》。 从表现形式上来看，OPM这种系统架构语言主要包括三个分：对象，过程以及它们之间的连接。以下图为例，就是一个典型的OPM图，它表达的是"树"(对象)，通过“成长（过程）”，从"小"的状态变成"大"的状态，图中矩形表示对象，椭圆表示过程，箭头表示它们之间的连接，我们分别对其进行介绍。
2对象和过程
2.1对象（Object）
在OPM中，对象指的是存在，或者将会存在的东西，它可以是物理的，或者信息的。比如一张桌子，一个电脑都算是对象，一段音乐和一电影也可以算是个对象。在OPM中，常常用矩形表示对象，不同形式的矩形表示不同类型的对象,比如用有阴影的矩形表示物理的对象；同时，对象可以有多种状态，比如上图中的树，有小和大两种状态。
2.2过程（Process）
过程主要指的是可以将一个或者多个对象进行转化的东西。比如上面通过“生长”可以将树从“小”变“大”；通过"烹饪"把"食材"变成"食物";通过"组装"可以把"零件"变成汽车。3连接 连接就是对象和对象，对象和过程，过程和过程之间进行关联。在OPM中主要有两大类连接：程序性连接和结构性连接。3.1程序性连接程序性连接主要用来连接对象和过程，它又可以分为很多类，这里介绍两种典型的：转化连接和使能连接。①转化连接转化包括三种：消耗，创造，影响，从下图可以看到，“吃”会“消耗掉”食物；“采矿”产生了“铜”；“精炼”影响了“铜”。
类似的，我们看到信息类的对象也有这样几种关系：创造，编辑，删除。
②使能连接使能连接，表述的是要使得一个过程发生，需要的对象条件。常常分为两类：人和设备。如下图所示，焊接需要有具备焊接能力的人，加工制造需要机器设备。
3.2 结构性连接 结构性连接主要是连接不同的对象，它可以分为很多类，这里介绍两种典型的：带标签的结构连接和基本结构连接。①带标签的连接如下图，在连接上加上标签，说明对象的关系，比如下图表示的就是发动机和变速箱它们是相互连接的，以及机场和城市的关系等。
②基本结构连接我们常见的分和整体之间关系就可以用这种连接，只不过这里会用一个实心的三角号来表示一个整体是由那些分所组成的。
总结如何用一个比较简洁，直观和精确地描述系统架构？OPM就是这样的一种语言，它通程序性和基本结构两类连接将对象和过程整合起来，形成对系统架构的完整认知，便于理解和沟通。 附录：
《系统架构》读后感(四)：系统架构5 形式| 没有形式，何来功能？
精进学思行 精进学思行 今天
在系统架构1：系统架构-对系统的抽象和分析中，我们提及了分析系统及系统架构两个重要的角度——形式和功能，前者描述的是系统是什么，后者呈现的是系统能干什么。本文将从如下三个方面和你分享“形式”：
形式是什么？
形式环境是什么，为什么它重要？
对系统进行形式分析的步骤是什么？
1 什么是形式？
1.1形式的定义
形式的英文是Form，按照《系统架构》中的定义：
形式是系统的物理体现或者信息体现，它存在或有可能于某段时间内稳定而无条件地存在，并且对功能的执行起到工具性的作用。它包括实体的形式及实体的形式关系，先于功能的执行而存在，是系统/产品的一项属性。
在这定义中至少包含3层意思：
第一层：形式可以是物理的，也可以是信息的，汽车的零件构成是形式，一个程序的代码也可以是形式；
第二层：可以是过去存在过而现在消失了，也可以是现在存在，甚至是将来可能存在的，加上时间维度，我们就可以讨论更多可能的系统和形式；
第三层：对功能的实现具有承载性或者帮组，而且后面我们发现，任何功能的实现都需要有形式作为载体，所以它也是系统的一个天然属性。比如你要实现从A移动到B点，要么借助交通工具这种形式，要么双腿这这种形式。
为了更进一步分析形式，我们还可以从对象和结构两个方面进行描述。
1.2 对象
按照《系统架构》中的定义，对象指的是：
某段时间内有可能稳定而无条件存在的事物。
貌似对象和形式有点类似，但是它们有两个重要的不同：对象不必承载功能；对象不一定要先于功能而存在。
但是对象还有一个重要的特性，它常常携带被描述事物的特性或者状态，就像我们在系统架构3 ：如何用简洁图形描述系统架构？分享的一样，如果用OMP表示，它可以用表示为：
为什么要在形式的基础上还引入对象？我的理解是，通过对象以及对象之间的关系可以更好描述不同的形式，而对于对象的关系，或者叫形式所包含的关系（“形式关系”），在《系统架构》中将其等价为“结构”。
1.3 结构
什么是结构？
形式关系或结构，是形式对象之间有可能在某段时间内稳定而无条件存在的关系，它们有可能有助于功能交互的执行。
听上去比较抽象，其实很常见，比如公司就是将人（对象），通过纵向关系（上下级）和横向关系（平级）组织到一起，进行产品的（功能），这里的纵向和横向关系就是一种结构，只不过有些是扁平，有些是层级的。
在结构中，常见的关系有两种：空间/拓扑关系（spatial/topological relationship）与连接关系（connection）。
1.3.1空间/拓扑关系
空间关系用来表达位置或方向，比如上下、左右、前后等，拓扑则描述的是物体的布，可以表示在内，包含，围绕等，这种关系对系统常常很重要，我们都知道买房的3个黄金法则：“位置，位置，还是位置”。再以我的专业——汽车噪声振动控制为例，在进行零件布置建议的时候，为了降低车内噪声，要尽可能让会发声的零件远离乘员舱。
1.3.2连接关系
还是以前面的居住地点为例，为什么位置很重要？因为好的位置和外优质资源有更好的连接关系。而连接关系，常常也意味着它会为被连接的对象提供某种能力，让其能够传递或交换某些东西，进而促进系统的交互性，让功能涌现。
典型的案例就是人类三次工业。第一次工业带来的蒸汽机、火车、汽车等发明，提升了人类的“物流”能力；第二次电力，提升了人类的“能量流”能力；第三次工业，提升了人类的“信息流”能力，这些能力的提升，让人们的经济发生指数级增长。
1.3.3 其它关系
当然，除了上面两种重要的关系外，还有其它关系，比如最常见的人际关系，我们有父母，子女，朋友和同事。我们在地球上都受到重力的作用，这是地球和我们的相互吸引的关系等。
如何用更加直观的方式表达上面提到的对象和关系呢？可以参考系统架构3 ：如何用简洁图形描述系统架构？和系统架构4：更易计算的系统描述（SysML）。
2形式环境
就像约翰.多恩的诗句《没有人是一座孤岛》中吟诵的一样，
“没有人是一座孤岛，……每个人都像一块小小的泥土，连接成整个陆地……”
我们也需要把被分析的系统，放到它所在的环境中考虑，有两个有用的考虑视角：全产品系统（whole product system）和使用情景（use context）。
2.1 全产品系统
以汽车为例，即使你只是一个汽车车身设计工程师，你不仅需要考虑你车身本身，你甚至需要考虑和上下游系统的关系，比如造型设计，生产制造，甚至是财务成本等。
2.2使用情景
大分的系统都是有使用情景，比如你设计一个日常使用汽车，你需要考虑到它在酷暑和寒冬天气下的使用的性能，不需要太考虑它在异常颠簸和崎岖的路上性能，但如果你设计的是军用汽车，那就需要有另外一个考量了。
我们在做工程时，也会碰到这种情况，比如有些零件在一定条件下工作，噪声会变大，在解决之初，我们可能希望尽可能降低噪声，但是要求越高，常常意味成本的增加，这个时候，我们就需要考虑它的使用条件，如果噪声差的情景完全不会出现，或者概率极低，花很多资源解决，就很可能是一种浪费。
3 如何对系统进行形式分析？
以上介绍了形式是什么，以及和相关的环境，如果需要分析一个系统的形式，我们常常应该怎么做呢？我理解可以分为如下的4步，我们以《系统架构》中举到的离心泵为例说明：
步骤1:定义系统
了解我们要研究的系统是什么，比如我们要研究的是泵，它主要是给流经它的液体加压，我们可以暂时把它隔离来看。
步骤2: 分解描述
分析它由那些分构成（对象），这些对象如何的相互关系是什么（结构），我们可以通过图示的方式进行表示，无论是系统架构3 ：如何用简洁图形描述系统架构？中提到的OPM,还是系统架构4：更易计算的系统描述（SysML）中的SysML，或者就是示意图，比如下图中泵的构成，及其件的相对关系。
步骤3:深入机理
分析它主要功能背后的机理，比如它是通过叶轮快速搅动对液体做功，增加流体在泵内的速度，将电机的电能转化为液体的压力。
步骤4:考虑环境
要让它发挥作用，它肯定还需要连接的进出水管，以及输入电能，甚至还需要一个操作人员，这些都是和它相关的周边系统。同时还要考虑，它是用在日常的厨房中，还是用在化工中。
总结
形式是功能的载体，可以从对象和结构两个方面对形式进行分析，它们是功能得以实现的基础。如何对系统的形式进行分析？可以从定义系统，分解描述，深入机理和考虑环境四个方面展开。
《系统架构》读后感(五)：系统架构4：更易计算的系统描述（SysML）
原创 精进学思行
在系统架构3 ：如何用简洁图形描述系统架构？中，我们分享了一种图形化描述系统的方法——OPM，本文分享和它并行的另一种方法——SysML（System Modeling Language ），主要包括如下三方面： SysML的历史？SysML的主要表达图形有哪些？SysML和OPM有什么不同？ 1 SysML是什么，从哪来？ SysML（System Modeling Language）从名字上看，就让人感觉是正统，因为它翻译过来就叫“系统建模语言”。但是它的历史并不长，从下图可以看到它诞生于2003年，是由对象管理组（Object Management Group，OMG）和系统工程国际（International Council on Systems Engineering，INCOSE）联合的。从图中也会发现，它是从UML（Unified Modeling Language）中演化而来的，而UML主要是用于软件系统工程，后来发现可以拓展到其它系统工程中，于是就从UML中选择了分视图，再加入一些更加通用的视图，就形成了现在看到的SysML。
2 有哪些视图？ 前面提到了“视图”，和OMP类似，SysML也是通过图形的方式来描述系统。目前的SysML包含有9类视图，它们可以分为3类：要求（Requirements），结构（Structure）和行为（Behavior），从名称上可以看出，它们分别用来描述系统要满足的要求，结构和行为方式，我们分别进行简介。2.1要求 顾名思义，要求图就是用来定义系统应该满足的要求。这种要求通常可以分为两类：功能类和非功能类，比如汽车最基本的功能是要能跑，而其跑起来噪声大小则是非功能类。每个系统的功能可能各不相同，但是其非功能类的要求通常有如下的几种：性能表现，设计边界（如重量，尺寸等），界面要求以及可用性，比如在我们汽车中的人机交互（HMI）和用户体验就是一种非功能性的要求。而每种要求还可以通过图形的方式进行细化，甚至定义非常具体量化的指标。通过要求图的方式定义完系统的要求后，就可以在后续的系统构建和测试中，要求的满足程度，进行优化调整。2.2结构 通俗理解，结构就是静态描述系统构成分及其之间的相互关系，在SysML主要包含3类：块定义图（Block definition diagram），内块图（Internal Block diagram）和包（Package Diagram）。 2.2.1块定义图（Blockdefinitiondiagram）块是个抽象概念，用来描述系统中的件，模组等，它们可以是软件的，也是可以是硬件的。用矩形表示，而这个块本身可以承载它所表示对象的特性，约束，状态等信息。 2.2.2 内块图（InternalBlockdiagram）内快图其实就是把“块”打开，如果“块”是个黑盒子，那么内块图就是“白盒子”。 2.2.3参数图（ParameterDiagram）参数图的目的是对内快图的一种参数量化，强化了数学法则对内块的定义。
2.2.4包图（PackageDiagram）如果说“内块”是对"块"的打开，那么包图就是对"块"的进一步封装，因为一个系统中块太多，为了人们的理解，就需要进行进一步的归类。 2.3行为 我理解“行为”类的图，主要用来表述系统中描述方式，主要包括如下的四类。 2.3.1活动图（Activitydiagram）活动（activity）用来描述系统的输入，输出和控制的流动，也包括这些协调这些流动的条件，其实很类似于我们常见的流程图。 2.3.2序列图（Sequence diagram）在序列图中一个重要的概念是Message，我在工作中听到对它的一个专业翻译“报文”。而序列图其实就是就是基于接收和分发报文来执行动作，比如我在做汽车声音时，为了让某个声音在特定的出发条件下发出，就需要找到对应的报文，然后按照设定的逻辑发出。 2.3.3状态机（StateMachinesDiagram）状态（State）常常表示的是一个对象在生命周期中表现的特定特征，比如汽车中的制动系统，有制动和非制动两种状态。而状态机，描述的就是在一定的触发条件下，对象表现的活动，这种触发可以是时间，事件，某个信号等。比如你按下台灯开关（触发），它就点亮（状态1），再按一次（触发），它就熄灭（状态2）。2.3.4使用案例（Usecase）描述系统的操作者会怎么使用，比如我们常常说的使用场景，也可以描述多个操作者对同一个系统不同分的操作。 3 SysML和OPM有什么异同？ 在系统架构3 ：如何用简洁图形描述系统架构？中的OPM和SysML，它们都是动过视图化的方式来描述系统，让我们更好理解和掌控复杂系统。它们有什么异同？我看到主要有三点： 3.1视图数量不同 OPM只需要1种类型的图，就能将对象和过程涵盖进来，而SysML需要多个视图（共9个选择）来分别针对不同的用途。 3.2适用阶段不同 OPM更简洁，但是主要适用于概念构想阶段，而SysML则更加适合详细的设计阶段，而且不同的用途可以采用不同的视图。 3.3可计算性不同 对系统的描述和达成共识只是开始，而我们更加关心系统的动态性能如何？这就需要引入仿真或计算，并预测复杂系统的特性及其参数变化对功能的影响，而在这个方面SysML的有时要明显优于OPM，并不是因为SysML本身可以计算，而是它对系统的描述更加细致，有利于用外在的辅助仿真工具实现，总体看来，SysML是为各种仿真搭建了一个比较的框架。 总结 SysML（System Modeling Language）用3类（需求、结构、行为）9种类型的图来刻画系统架构，更适合于系统的详细设计阶段，为系统的仿真提供了一个更高的框架。 参考：1 OMG Systems Modeling Language(OMG SysML™)Tutorial September, 2009；2https://sysmlforum.com3 Graph-Based Digital Blueprint for Model Based Engineering of Complex Systems
