2020-10-16

形式化方法

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

《大象–thinking in UML》

一、参与者（Actor、主角）(一)特点：1)业务建模的核心。它是涉众代表，代表涉众对系统的利益要求，并向系统提出建设要
求。系统是以参与者的观点决定的，他对系统的要求，对系统的表述完全决定了系统的功能性。2)参与者位于边界之外1.谁对系统有着明确的目标和要求，并且主动发出动作？2.系统是为谁服务的？3)业务工人（Business Worker）4)参与者可以非人5)涉众是发现参与者的重要来源6)涉众（Stakeholder），又称干系人，指与建设系统有利益相关的一切人和事，但涉众不
一定是系统的参与者。参与者是涉众代表，他对系统的要求直接影响到系统的建设，他们的要求就是系统需求的来源。参与者通过对系统提出要求来获得他所代表的涉众的利益。由此可见，参与者也并不需要询问同一岗位所有人，而是找出可代表该岗位的代表，与之沟通。7)用户和参与者，用户是指系统的使用者，系统的操作员，他是参与者的代表。8)角色是参与者的职责，是一个抽象的概念，从众多参与者的职责中抽象出相同的一部
分，将其定义一个角色。一般适用于概念阶段的模型，以表达业务的逻辑理解。一个用户可以代理多个参与者，一个用户可以拥有多份职责，即可被指定多个角色。(二)问题1)谁负责提供、使用或删除信息？2)谁将使用此功能？3)谁对某个特定功能感兴趣？4)在组织中的什么地方使用系统？5)谁负责支持和维护系统？6)系统有哪些外部资源？7)其他还有哪些系统将需要与该系统进行交互？(三)版型1)业务主角（Business Actor）定义业务的参与者，在需求阶段使用，用来确定业务范围。非常重要，建立业务模型、查找业务用例都须用业务主角。业务范围和系统范围不同，业务范围指项目涉及的所有客户业务，有些业务内容没有系统参与也一样客观存在。系统范围仅指软件要实现的业务功能。有些系统功能不在业务范围，如操作日志。业务主角针对业务人员，而非计算机用户，也不应过早引入计算机系统的概念，以免混淆，导致误导用户。业务主角必须在实际业务里能找到对应的岗位或人员。
常用问题：  业务主角的名称是否是客户的业务术语？  业务主角的职责是否在客户的岗位手册里有对应的定义？  业务主角的业务用例是否都是客户的业务术语？  客户是否对业务主角能顺利理解？ 
 
2) 业务工人（Business Worker） BW被动参与业务。 BW处于系统边界内。 
不需要为BW建立业务模型，只在主角的业务模型中出现。 
虽然不参与业务建模，但他们仍然不可或缺，如领域模型、用例模型。缺少他们业务模型就不完整，甚至不能运行。 
判断他是在边界之内和边界之外，常用问题：  他是主动向系统发出动作的吗？  他有完整的业务目标吗？  系统是为他服务的吗？ 
 
(四) 检查点（RUP官方文档，非常有助于检查发现的参与者是否正确） 
1) 是否您已找到所有的参与者？也就是说，是否您已经对系统环境中的所有角色都进行
了说明和建模？虽然您应该检查这一点，但是要到您找到并说明了所有用例后才能将其确定。 
2) 每个参与者是否至少涉及一个用例？删除未在用例说明中提及的所有参与者，或与用
例无通信关联关系的所有参与者。 
3) 您能否列出至少两名可以作为特定参与者的人员？如果不能，请检查参与者所建模的
角色是否为另一角色的一部分。如果是这样，您应该将该参与者与另一参与者合并。 4) 是否有参与者担任与系统相关的相似角色？如果有，您应该将他们合并到一个主角
中。通信关联关系和用例说明表明参与者和系统是如何相互关联关系的。 
5) 是否有两个参与者担任与用例相关的同一角色？如果有，您应该利用参与者泛化关系
来为他们的共享行为建立模型。 
6) 特定的参与者是否将以几种（完全不同的）方式使用系统？或者，他使用用例是否出
于几个（完全不同的）目的？如果是这样，您也许应该有多几个参与者。 
7) 参与者是否有直观名称和描述性名称？用户和客户是否都能理解这些名称？参与者
的名称务必要与其角色相符。否则，应对其进行更改。    
二、用例（Use Case）  用例是UML建模中最重要的元素。除了用例外，所有其他元素都是“封装”、“独立”的。这些元素在没有外力作用时，是“老死不相往来”的。用例正是施加这一“外力”的元素，它使得其他各自独立的元素能共同组成一篇有意义的文字。  用例是一种把现实世界的需求捕获下来的方法。首先有某人的一个愿望，这个愿望驱使人去做事并获得一个确定的结果。一个系统就是由各种各样的愿望组成的。如果所有对系统有愿望的人要做的所有事情都找全了，那这个系统的功能性就被确定下来了。  官方定义：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作
印象笔记随时记录一切 读书笔记
生成特定主角可以观测的值。  本书定义：一个用例就是与参与者交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集合。  一个用例场景就是一个用例的实例。  一个完整的用例定义由参与者、前置条件、场景、后置条件构成。

(一) 用例特征  
a) 用例是相对独立的。 
不需要与其他用例交互而独自完成参与者的目的。如取钱是一个用例，而填写取款单却不是。没人会只为了填写取款单跑一趟银行。 
b) 用例的执行结果对参与者来说是可观测的和有意义的。 
例如，一个后台进程监控参与者在系统里的操作，在参与者删除数据之前执行备份。虽然它是系统的一个必需组成部分，但它在需求阶段却不应该作为用例出现。因为这是一个后台进程，对参与者来说是不可观测的，它应作为系统需求在补充规约中定义。又比如，登录系统是一个用例，但输入密码不是。因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但单纯输入密码却是没有意义的。 
c) 这件事必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动，也
不应该主动启动另一个用例。 
如从ATM取钱是一个用例，ATM吐钞却不是。 d) 用例必然是以动宾短语形式出现的 
如喝水是一个有效的用例，而“喝”和“水”却不是。很多用例中以“计算”、“统计”、“报表”、“输出”、“录入”之类命名的并不在少数。 
e) 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元。