《需求工程——软件建模与分析》阅读笔记三

　　建模是研究系统的重要手段和前提。凡是用模型描述系统的因果关系或相互关系的过程都属于建模。再展开点讲我对建模的理解应该是用形式化的图形或语言抽象的 描述事物，其中包括了对事物组成结构和相互关系方面的静态描述，也包括了对事物和外部交互机制，事物内部组件运行机制的内在描述。

　　建模是对需要实现的目标的高度抽象定义和实现，当我们一看到模型，我们很容易的预测到后续事物真正实现后的结果。这个是建模的好处之一，即可以通过抽象的 模型来预见未来；同时，通过建模，再加上相关的设计图纸和工艺流程，可以指导我们后续真正的实现，这是建模的好处之二，即建模是分析和设计的过程，通过建 模可以更好的衔接从需求到实现的中间环节。

　　对于软件建模，首先从建模能够预见未来来分析，常规的UML建模工具和方法往往很难到达这个目标，因为UML更加偏重于分析和设计，偏重于指导实现，而不 是真正能够很好的预见系统本身。如果从这个层面上来看，界面建模，原型和交互设计往往更加容易达到这点目标。需要将这块纳入到软件建模的内容，但是需要看 到的没有UML建模的内容，用例的分析，组件的划分，单纯直接跳跃到界面建模往往很难真正的满足系统的组件化和高扩展架构。而没有界面原型，用户又很难对 将要实现的业务系统有一个很形象的理解。

　　其次从建模指导后续实现来讲，这是UML的一个强项，UML本身就是面向对象的分析和设计方法的一个符号体现，通过UML符号来抽象的表达我们需要表达的 事物。在这里面一方面是要理解软件系统的组成架构，包括从业务层面的功能模块和业务组件的划分，也包括了从存技术层面的架构分层等，这些属于建模的静态部 分。另外一方面还需要详细的描述任何一个需求的实现的过程，在这个过程中外界和内部如何交互，内部的组件之间又应该如何协同，这些属于建模的动态内容。

　　在我们谈软件建模的时候，经常认为软件建模是一个内部的分析和设计的过程，和用户无关。但是从传统的工程领域建模，它们却更加关注用户能够看得懂的模型和 图纸。任何一个产品的实现，首先是用户要认可和可视化的了解我们将要实现的产品，然后才是如何通过分析和设计更好的去按步骤实现它。如果要进行选择，前者 往往高于后者，技术人员一定不要犯制作很好的架构而客户不需要的产品的毛病。

　　在原型的重要性提升后，原型往往只反映了事物的静态功能和组成，只有动态的原型才能够更好的体现事物内在的交互和协同。动态化的原型建模感觉后续应该更加 成为软件领域建模考虑的一个重点，即如何更好的通过模型来反映一个用户可以理解的真实系统。我们需要考虑的是通过成本最低的方式尽早反应，以最大化的降低 风险。从这个意义上，除了动态完全仿真原型外，短周期的迭代交互就更加重要。但是要认识到，迭代交互的是可用的毛坯房，而不是交付的单个客厅。

　　在RUP方法论中经常谈到是用例驱动，架构为核心，这是面向对象建模的一个思路，即首先从用户的业务目标和行为分析入手，通过动态的业务流程和行为分析， 逐步分解到我们需要哪些组件，这些组件应该如何交互才能够支撑这些业务功能。动态分析入手，逐层分解和细化，形成组件和组件交互。那除了从用例驱动，能否 从前面谈到的原型驱动，能否从用户关心的核心数据驱动来形成一套可行的建模思路，是可以考虑的问题。包括领域模型和领域驱动设计给我的启发，能否从业务核 心数据对象直接入手，首先找到核心的业务数据对象，然后再来看为了满足业务需求和流程，这些数据对象之间应该如何协同？进一步再来分解到业务组件和单元， 这些都是可以考虑的思路。

　　在工程和机械设计领域，我们看到往往模型定了，可以很快速的通过模型生产产品，这是因为其平台已经足够成熟和自动化，固化来可以直接将模型的结果映射为制 造需要的配置参数而不需要人工的任何干预。比如机织毛衣，只要毛衣图样定了输入电脑，机器即可快速的进行编织，完全和你看到的模型一样。之所以我们谈了很 多年的MDA模型驱动架构，有模型直接进行的代码和功能模块生产很困难，正在于软件系统构建本身的复杂性，虽然我们进行了大量的尝试，包括将建模分解到数 据，界面，流程，业务规则，但是仍然很困难，特别是业务规则的建模和自动生成上。MDA要真正落地必须要有一个强大的平台，这个平台可以很好的完成UML 模型到需要实现功能的自动映射。