无线通讯产品App的设计讨论 -- 连载四

xdwangxf

【上期简单回顾】

连载三主要规划和整理了LTE终端App协议栈的业务目标，并对前期准备阶段做了简单的小结。

【本期重点】

从本期开始，大家的工作重点就是根据业务目标，开启建模之路，并且逐步清晰化并确定需求。

本期的重点就是对建模进行一定的分析和讲解，算是启动建模之路前的铺垫。

【本期内容】

1.      何谓“建模”？

百度百科对“建模”的定义如下：

建模就是建立模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。

------http://baike.baidu.com/view/44500.htm?fr=aladdin

维基百科将“建模”分为数据建模和数学建模。对“数据建模”的描述如下：

在App工程中，数据建模是运用正式的数据建模技术，建立信息系统的数据模型的过程。是一种用于定义和分析数据的要求和其需要的相应支撑的信息系统的过程。

------http://zh.wikipedia.org/wiki/数据建模

“建模”（Modeling），是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察的对象的内部结构和工作原理的便于理解的表达。

------大象-Thinkingin UML

个人理解：建模是挖掘事物本质的关键内容和规律，以数学和工程技术的方法进行描述并构建，达到认识事物、分析事物和掌握事物发展规律的目的。

2.      为何要建模？

大家这里讲解的是App设计，需要建模吗？

建模分析，是为了达到更好的分析和掌握现生活的问题。比如预测天气、分析人类特定爆发行为、无线通讯的信道模型分析等，其实建模在大家的生活中无处不在。

如果大家编写的是一个简单App系统，比如单一的文件操作，或者简单如“Hello world！”的程序，是不需要建模的。

针对复杂的商业App系统，除了要求满足业务功能和性能之外，安全、可靠、便于维护、便于扩展，都提出了很高的要求。随着客户的要求越来越多样化，商用App也需要拥抱变化。因此，需要研发团队使用更为系统的方法进行App设计。

建模，有助于帮助大家理解App产品的关键内容和本质规律，更好的满足现代的商用App系统的要求。

当然，大家的认识水平和技术能力是有限的，建模不可能是包治百病的良药，但是却可以使大家的App设计过程更为扎实和细致，更好的拥抱变化。大家的目标就是无限趋近于理想答案。

3.      如何建模？

如何建模涉及到建模的方法，抽象的角度，和建模的结果。

（1）    建模的方法：针对App系统，认为面向对象和面向过程的方法。面向对象本质是将事物对象化，而面向过程是从顶层逐步向下，将复杂的系统逐步模块化。面向对象的优势是符合人类的思维方式，每个对象都是一个自组织系统；面向过程的优势是以业务的发生顺序为主线，逐步实现，初始理解比较容易。而且针对规模不大的系统，面向过程的方法具有先天的优势。面向对象和面向过程的分析方法，不是对立而是互补的关系。大家在建模时，要将这两种方法结合起来使用。

补充一个问题：

也许有人会问，通讯产品常用C语言来实现，而C语言是一种典型的面向过程的语言。如何能用面向对象的方法来建模呢？

我的理解是：

语言就和工具一样，用何种语言，是工具的选择不同。而且通讯产品属于嵌入式系统，同时追求高效处理。因此也决定了通讯产品大多用C语言。但是不能说C++不适用于通讯产品。

用何种方法来进行设计和用何种用语言来实现，没有必然的联系。不能说C语言就无法实现面向对象程序。须知，C++底层的机制，实际上都是用C语言实现的。只是大家使用C++时，看不到也不关心罢了。

（2）    抽象的角度

需要回答两个问题：什么是抽象的角度？如何选择抽象角度？

抽象的角度，简单一点就是大家观察事物的角度。

大家还记得苏轼的“横看成岭侧成峰”的诗句吗，其实很好的反映了观察角度不同，导致观察到的结果也不同。

如何选择抽象角度呢？大家不能乱看，也不能随着心性来看。为什么“横着看而不竖着看”，是有原因的。会到App设计这个问题上面来。设计App的目的是为了解决客户的现实问题。因此，解决客户的现实问题，就是抽象的目标；站在客户的角度来看某个现实问题，就是一个抽象的角度。因此，App建模中，会有多个抽象的角度。因为客户会有多个，现实问题也会有多个。

（3）    建模的结果

针对这个问题，个人理解《大象-Thinking in UML》的2.1节，针对“模是什么”的内容，讲解的非常好。

“一个由抽象角度确定了的目标需要由静态的事物加上特定条件下产生的一个特定的场景来完成，即静态的事物（物）+特定的条件（规则）+特定的动作（参与者的驱动）=特定的场景（事件）”。

这里提到了“物”、“事”、“规则”和“事件”。其实要建立的目标就是上面的这个等式。

在UML中，以上的几个概念的学名：

人 = 业务主角（Actor）

物 = 业务实体（Entity）

事 = 业务用例（Use Case）

规则 = 限制条件（constrain）

这里，给出《大象-Thinking in UML》中的建模公式，有兴趣的可以好好理解、揣摩。

图3.1 建模公式

提示：如果大家喜欢《大象-Thinking in UML》的话，建议大家购买正版书籍学习。也算是敬重编辑的劳动成果。

4.      本连载建模的过程

这里，对本连载的建模顺序做一个简单的描述。

现实世界à业务模型à概念模型à设计模型

进一步描述就是：

（1）    从实际的问题中挖掘业务用例，建立业务模型。在建立业务模型过程中，同时也针对业务领域进行建模；

（2）    从业务模型建立概念模型，并提炼业务架构；

（3）    从业务模型和业务架构中，获取设计模型。

设计模型，其实就是系统方案得到的内容。设计模型之后，可能大家都比较熟悉了。

在建模过程中，会穿插讲到使用到的UML、RUP（统一App开发过程）的相关常识，并综合RUP的4+1视图和UML

的各种视图，将大家的建模过程逐一展示出来。

【小结】

算是正式启动建模过程之前的铺垫。

个人觉得，前面两期连提到的“前期准备工作”和本期提到的“建模过程”，是一些企业在App设计中缺少或者有但是没有重视并且真正落到实处的。这可能也是造成App产品研发过程中测试和后期维护成本高的原因之一。