【软件工程理论与实践】homework（四）part2

读《大象-Thinking in UML》

---

以下皆是参考大佬写的读书笔记：(https://blog.csdn.net/bit_kaki/article/details/80067462)

---

一、UML是一种语言

语言是用来沟通的主要方式，包含了单词和语法
UML 的单词就是各种元素、视图和模型，语法就是建模的方法
语言最基本的功能是能清楚地表达和传递信息
UML最基本的就是通过模型将需要做的系统清楚表示出来

二、UML采用的是面向对象的方法

面向对象是一种认知世界的方法，在面向对象方法里，一切有名字的东西都是对象
对象和对象之间彼此独立，只有在某个特定场景下，它们的某一个特定实例才相互联系在一起
每个对象都是一个整体，内部不可分割，外部只能通过边界和其他对象对接
对象参与每个场景时都会展现其某一个方面性质，这方面性质都可以抽象出来

三、建模的实质是将现实世界抽象为模型

同样的事物在不同的世界观的人眼里会产生不同的结果，而这个世界观在建模里对应的是抽象角度
一旦决定了抽象角度，就确定了一个目标
一个由抽象角度确定了的目标需要由静态事物加上特定条件下产生的一个特定场景来完成，即静态的事情（物）+特定的条件（规则）+特定的动作（参与者的驱动）=特定的场景（事件）
建模其实也就是由人+事+物+规则，将现实世界抽象为模型

四、项目的启动

项目的启动首先源自“老大”的愿景，在老大看来，为什么要开发这个系统
然后是进行涉众分析，谁关心这个系统？会涉及到他的什么利益？
再次是投入，愿意花多少钱，允许多少时间？
最后是风险，比如客户参与少；没有度量方式；技术风险；重要人物反对；以前曾被取消过……

五、客户访谈技巧

一般来说系统分析员是计算机专家，习惯于从计算机角度来看问题；客户是业务专家，习惯身边的人也熟悉这个业务领域。
所以系统分析员需要改变自己的立场，了解业务是什么，还要弄清业务为什么。
首先，应该有一个详细的涉众分析报告，循序渐进地从接触到深入了解客户；
其次，不要急于深入业务细节，而是先就一些大框框进行沟通，借此习惯和了解对方的沟通方式；
再次，双方的时间是有限的，因此每一次会面都需要争分夺秒，用最快的时间把问题搞清楚；
最后，系统分析员需要承担每次会谈结果记录，并且需要正式的反馈和确认，以便之后和客户在需求变更时候有依据。

六、需求获取

在对每个业务进行需求调研时候首先要明确该业务的边界，每个边界的划分则指明了需求分析的起点
找到业务主角，访谈业务主角或者从业务主角的角度来看与系统的交互，就可以得到业务用例
根据业务用例用合适的视图表达出来就构建除了业务模型
业务建模常见的视图有两种：活动图和时序图
活动图中活动是主要的内容，表达的内容是业务主角或业务工人做什么；时序图中，消息是主要的内容，表达的内容是业务主角或业务工人之间传递的是什么

七、需求分析

需求分析首先要找到关键概念，关键概念是指支撑起客户整个业务架构的那条主线，在UML方法里，就是由一些关键的业务用例构成
根据各个关键概念，梳理出相关的概念用例，获取概念模型
每个概念模型表示一个功能，各个概念模型之间通过软件架构联系起来
从概念模型入手，根据找到业务主线找到每个大的业务构件，再通过领域模型分解为小的构件,再根据概念模型找到各个小的构件之间的依赖关系。
如此就得到了项目的业务架构

八、系统分析和设计

将每个业务模型抽象为描述系统的模型，就得到了系统模型
业务用例抽象为系统用例的基本方法有：映射、抽象、合并、拆分、演绎等
系统分析的成果是获取到系统的每个分析类，这些分析类基本上可以分为实体、边界、控制三类，和开发中的MVC正好对应
将分析类的成果考虑具体实现语言和实现方式，也就是系统设计，得到的成果就是开发中可直接用的类、包和接口

九、理论和实际

《大象》这本书尽管作者举了很多生动的例子，画了大量的图，但整体来说是依然是非常枯燥的
对于书中理论，抽象程度都比较高，专业的词汇也比较多，所以看下去真的很难
不过UML作为目前可视化建模语言的工业标准，其本身也源于面向对象分析和设计的方法
目的就是为了更清晰、简单的表达软件设计中的动态和静态信息
所以如果能结果实际项目来看会往往觉得豁然开朗的感觉，但强行去从概念理解往往会让自己更懵
另外我觉得uml的学习最大的成果是有这样一种思维方式，如何分析和设计一个系统
但真正在无比推崇“敏捷开发”的现在，我觉得uml很多时候还不如一个高真的axure更能传递清楚软件设计的信息