软件工程第三次作业

一、阅读和了解什么是形式化方法

    形式化方法英文的名称是formal methods。在逻辑科学中是指分析、研究思维形式结构的方法。它把各种具有不同内容的思维形式(主要是命题和推理)加以比较，找出其中各个部分相互联结的方式，如命题中包含概念彼此间的联结，推理中则是各个命题之间的联结，抽取出它们共同的形式结构，再引入表达形式结构的符号语言，用符号与符号之间的联系表达命题或推理的形式结构。
    例如，把全称肯定命题，用符号形式化为"SAP"；把联言命题、假言命题分别形式化为:"p∧q、“p→q”。又例如:一个具体的假言联言推理"如果这种金属是纯铝,那么它的物理性质必与纯铝相同;如果这种金属是纯铝，那么它的化学性质必与纯铝相同；但这种金属的物理性质和化学性质与纯铝不相同；所以，它不是纯铝。"这个推理的形式结构是："如果p，则q；如果p，则r；非q且非r；所以非p。"可进而形式化为下列公式：((p→q)∧(p→r)∧┐q∧┐r→┐p。

根据说明目标软件系统的方式，形式化方法可以分为两类:

    1)面向模型的形式化方法。面向模型的方法通过构造一个数学模型来说明系统的行为。
    2)面向属性的形式化方法。面向属性的方法通过描述目标软件系统的各种属性来间接定义系统行为。

根据表达能力，形式化方法可以分为五类:

    1)基于模型的方法:通过明确定义状态和操作来建立一个系统模型(使系统从一个状态转换到另一个状态)。用这种方法虽可以表示非功能性需求(诸如时间需求)，但不能很好地表示并发性。如:Z语言，VDM，B方法等。
    2)基于逻辑的方法:用逻辑描述系统预期的性能，包括底层规约、时序和可能性行为。采用与所选逻辑相关的公理系统证明系统具有预期的性能。用具体的编程构 造扩充逻辑从而得到一种广谱形式化方法，通过保持正确性的细化步骤集来开发系统。如:ITL(区间时序逻辑)，区段演算(DC)，hoare 逻辑，WP演算，模态逻辑，时序逻辑，TAM(时序代理模型)，RTTL(实时时序逻辑)等。
    3)代数方法:通过将未定义状态下不同的操作行为相联系，给出操作的显式定义。与基于模型的方法相同的是，没有给出并发的显式表示。如:OBJ， Larch族代数规约语言等;
    4)进程代数方法:通过限制所有容许的可观察的过程间通信来表示系统行为。此类方法允许并发过程的显式表示。如:通信顺序过程(CSP)，通信系统演算 (CCS)，通信过程代数(ACP)，时序排序规约语言(LOTOS)，计时CSP(TCSP)，通信系统计时可能性演算(TPCCS)等。
    5)基于网络的方法:由于图形化表示法易于理解，而且非专业人员能够使用，因此是一种通用的系统确定表示法。该方法采用具有形式语义的图形语言，为系统开发和再工程带来特殊的好处。如 Petri图，计时Petri图，状态图等。

二、阅读《大象——thinking in UML》

    《大象：ThinkinginUML》以UML为载体，将面向对象的分析设计思想巧妙地融入建模过程中，通过贯穿全书的实例将软件系统开发过程中方方面面的知识有机地结合在一起。

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

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

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

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

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

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

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

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

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