人月神话读书 告

第二次作业

你是否认为，没有足够的技术水平就无法使用敏捷开发方法strong>

我不同意这这种看法。敏捷开发过程中会产生各种各样的问题，例如测试工作量过于巨大，代码检查工具不理想等。如果没有足够优秀的开发、测试工具，会使整个软件工程难上加难，拖累进度。

“敏捷过程模型是增量方法和迭代方法的复合”。你是否认同这个观点么strong>

同意。迭代开发只是要求将开发分成多个迭代，并没有回答一个重要的问题：怎么划分迭代。这时，一般采用”增量开发”划分迭代。所谓的”增量开发”，指的是软件的每个版本，都会新增一个用户可以感知的完整功能。也就是说，按照新增功能来划分迭代。增量开发加上迭代开发，才算是真正的敏捷开发。

对案例进行分析，总结敏捷开发的过程，有何体会strong>

过程：设计人员完成设计文档；开发详细设计体现开发设计思路；开发设计对于代码设计理解一致；编写测试用例；编码开发；

体会：敏捷开发的第一个好处，就是早期交付，从而大大降低成本。敏捷开发的第二个好处是，及时了解市场需求，降低产品不适用的风险。

针对下列软件项目场景，探讨它们最适合采用哪种过程模型。

1. 已被广泛使用的某个产品，要开发新版本，包含了一组新功能，规定了紧迫的最后期限并已对外公开。

复用+敏捷开发：由于该项目是要发布新版本，所以可以使用面向复用的软件过程，又由于需求明确而固定不变且时间紧迫，所以可以使用敏捷过程。

1. 要开发某个突破性的产品，规模很大，所需的开发技术先进，风险较大，且市场上尚未有类似产品，用户尚未对其形成完整的预期；团队人员充足。

螺旋过程：风险较大，侧重风险分析。

RAD过程：团队人员充足。

1. 要开发的系统以某科学家团队的研究成果为基础，目标是在下一年度发布。

形式化开发：以某科学家团队的研究成果为基础，由于是独创性的科研成果，需要较高的可靠性，且时间充足。

1. 要开发的系统类似于团队之前已经做过的某个项目，只是规模更 大、复杂度更高一些，需求已经由用户写成文档。

复用+瀑布模型：某个团队之前已经做过的某个项目，可以使用面向复用的软件过程。因为需求已经明确写成文档，瀑布模型比较合适。

1. 一组身经百战的团队人员要开发一个互联 服务，同类产品在不 断更新中，互联 用户在使用过程中随时提出反馈

敏捷开发：需求不断变化，且技术成熟。

第三次作业-关于使用git分布式开发的感受

去中心化

本地提交

本地提交好处主要有3点：

1) 断 提交。

2) 小步提交。可以对自己的阶段成果有跟踪，并且提高每次变更的安全性。

3) 本地库。这个和断 提交是同一个实现，但从需求角度出发则略有不同，主要是说即使只有自己一个人开发项目，也可以轻易的让自己的代码有版本跟踪。

4) 本地回滚。这个其实是由于本地库的存在而产生的，但可以减少中央库上的冗余版本。

分支策略

分支策略从技术上来讲是将版本节点化了，即最终的版本状态是树状的。从结果上来讲既是弱化了分支，也是强化了分支。弱化的是分支的概念，强化的是分支的功能。在Git实际开发中分支的分离和merge是属于日常操作，开启和合并分支成本相比SVN要小得多：SVN是复制一份代码到分支目录，Git则是在分支点做一下标记。随便一次冲突就会自动产生分支，所以大家每天都在与分支打交道。这便是弱化了分支的概念，由于分支成本很小，因此使得按功能分支的开发模式（每个分支一个功能，开发完了再merge到主干）变得非常简单，大家可以完全不需要再因为担心SCM成本太高而选用主干开发模式（所有功能都在主干上开发，到了发版本前再分离出分支）。当然Git还有很多其他不错的地方，比如Tag策略。

第四次作业

基于你开发软件的经历，是否有过对代码进行大范围修改的现象用什么方法进行代码的有效维护/strong>

没有，通常是写一部分测试一部分。如果要进行大范围修改的话，最好保留完整的可以运行的模块。这样方便修改，不容易破坏其他的模块。

经常看到“某某公司的业务系统为了维护和升级需要耗费大量的时间，甚至导致系统不可用”的新闻 道。例如2013 年6月23日全国各地工商银行发生故障，系统非常缓慢导致业务停办，其原因是由于系统的数据库升级时考虑不全面所导致的。你认为系统在升级时最大的难点是什么、有什么规避措施strong>

最大的问题可能是在不改变原有的系统稳定性基础上进行更新。有效的措施是保留之前可以运行的版本，可以采用敏捷开发迭代更新的方式。

传统观点认为：“在软件开发过程中越早开始写程序，就要花越长时间才能完成它”，产业界的统计数据也表明：“在一个程序上所投入的 50-70％是花费在第一次将程序交付给用户之后”。 不过，最新的软件开发方法论(例如敏捷开发思想) 则认为“应该尽早交付可运行的程序”。 你怎么看待这两个看似矛盾的观点strong>

我认为两者并不冲突，时间上越早完成越有优势，可以进行大量测试，修改未发现的BUG，尤其是在交付之后在大量用户使用之后会暴露出的各种BUG，也许可以被提前发现。

你以前的实践中使用过持续集成的方法吗下你的具体体会和经验。

1、流程全自动化，减少重复性的手工操作

2、持续发布测试，时刻保持可发布的产品

3、团队、高层对项目、产品的进展清晰可见，把控风险

4、资源效率有效利用，流动效率更快

 

因此，如果要做到持续集成，我们需要：

1、一套持续集成工具，大体可分为云集成与本地化集成系统，云集成比如Travis CI、cloudbees的云集成等，本地化集成主要是开源Jenkins的搭建，如果需要大规模部署Jenkins且有预算可使用Jenkins商业版

2、自动化测试工具、良好的测试用例编写

3、版本控制系统，git、gerrit推荐

4、构建、测试失败反馈机制，邮件、自动化运维(AI…)、日志收集分析系统

5、一套需求、产品、开发、测试、部署、运维共同使用的敏捷研发管理系统，市场上有阿里云效、腾讯的TAPD等

 

第五次作业

为什么要进行软件测试测试的基本原则有哪些strong>

目的：以最少的人力，物力和时间找出软件中潜在的各种错误与缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患以及带来的商业风险。

 

软件测试基本原则：

1.所有测试的标准都是建立在用户需求之上的，测试的目的在于发现系统是否满足规定的需求；

2.“尽早地和不断地测试”，越早进行测试，缺陷的修复成本就会越低；

3．程序员应避免检查自己的程序，由第三方进行测试更客观有效；

4.穷举测试是不可能的；

5.充分注意测试中的群集现象，一段程序中一发现的错误数越多，其中存在的错误概率越大，因此对发现错误较多的程序段，应进行更深入的测试；

6.设计测试用例时应包括合理输入和不合理输入，以及各种边界条件、特殊情况下要制造极端状态和意外状态；

7.注意回归测试的关联系，往往修改一个错误会引起更多错误；

8.测试应从“小规模”开始，逐步转向“大规模”；

9.测试用例式设计出来，不是写出来的，应根据测试的目的，采用相应的方法设计测试用例，从而提高测试的效率，更多的发现错误，提高程序的可靠性；

10.重视并妥善保存一切测试过程文档（测试计划，测试用例，测试 告等）；

对测试错误结果一定要有一个确认的过程。

常用的软件测试模型有哪些一下各自的优缺点。

常用的软件测试模型有V模型、W模型和H模型。每种模型都有各自的优缺点。

V模型的价值在于非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程各阶段的对应关系。在V模型中,测试工作在编码之后才能进行，所以在软件开发早期各个阶段引入的错误不能及时被发现。尤其是需求阶段的错误只有等到最后的验收测试才能被识别。对分析、设计阶段产生的错误不能及时发现并改正的缺点会对后期的修复工作带来诸多不便，造成更多资源的浪费和时间的延迟。

在V模型的基础上,增加开发阶段的同步测试，就是W模型。W模型的最大优势在于，测试活动可以与开发活动并行进行，这样有利于及早地发现错误，但是W模型也有一定的局限性。在W模型中，需求、设计、编码等活动依然是依次进行的，只有上一阶段完全结束，才有可能开始下一阶段的工作。与迭代的开发模型相比，这种线性的开发模型在灵活性和对环境的适应性上有很大差距。

在H模型中，软件测试过程的活动完全独立，贯穿于整个软件产品的生命周期，与其他流程并行进行。当软件测试人员认为测试准备完成，即某个测试点准备就绪时，就可以从测试准备阶段进入到测试执行阶段。

软件测试的过程及其相关的活动。

1．项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后sqa进入项目，开始进行统计和跟踪

2．开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。

3．测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

4. 测试用例完成后，测试和开发需要进行评审。

5. 测试人员搭建环境

6. 开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提交给bugzilla。

7. 开发提交第二个版本，包括bug fix以及增加了部分功能，测试人员进行测试。

8. 重复上面的工作，一般是3-4个版本后bug数量减少，达到出货的要求。

9. 如果有客户反馈的问题，需要测试人员协助重现以及回归测试。

四、分别介绍一下单元测试、集成测试、确认测试、系统测试、验收测试的基本过程。

1、单元测试：完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。

 

2、集成测试：通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构，应当避免一次性的集成（除非软件规模很小），而采用增量集成。

 

自顶向下集成：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。

   

自底向上集成：从原子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要求所有隶属于某个给顶层次的模块总是存在的，也不再有使用稳定测试桩的必要。

 

3、确认测试：又称有效性测试。有效性测试是在模拟的环境下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定，它包含的信息就是软件确认测试的基础。

 

      确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是确认测试的任务，即软件的功能和性能如同用户所合理期待的那样。

 

  　通过集成测试之后，软件已完全组装起来，接口方面的错误也已排除，确认测试即可开始。确认测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。

 

4、系统测试：是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试.

 

5、验收测试：验收测试是指系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。验收测试包括Alpha测试和Beta测试。

 

Alpha测试：是由用户在开发者的场所来进行的，在一个受控的环境中进行。

 

Beta测试：由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并 告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件。

 

作为两种常用的测试方法，黑盒测试和白盒测试有何异同strong>

白盒测试需要更加深入的接触到代码，例如代码语句zhidao的规范性、正确性之类的，可以通过画程序流程图来分析代码的路径，找出路径后可以根据路径来写测试用专例，而黑盒测试不需要接触代码，主需要根据软件的功能来设计一些测试用例，例如某个按钮是否属实现它的功能，做白盒的话可能会更加难，黑盒测试则更加普遍，当然待遇相对来说白盒高的多。

某档案管理系统，要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。用等价类划分法设计测试用例，来测试程序的“日期检查功能”。

1. 划分等价类编 ，表示等价类划分结果

 

1. 测试数据期望结果覆盖的有效等价类

200808输入有效①、◎、图

1. 为每一个无效等价类设计一个测试用例，设计结果如下:

95June无效输入D

2001无效输入E

1999006无效输入F

180002无效输入G

288801无效输入H

200300无效输入I

202013无效输入J

第六次作业-课后讨论：

一、MMO的架构设计

• 基于分层、缓存、异步、分布式/并发四种架构设计思想，分析MMO的架构设计所面临的设计决策：
  •  

所有针对伸缩性而设计的架构，通常需要包含多台机器；

从很小的系统开始，随着用户数的增长而增加处理能力；

采用多核CPU，各核通过并发来实现系统总体性能的增长；

MMO的总体架构应采用分布式和并发的系统架构。

对MMO程序员来说，开发分布式并发程序过于复杂了

程序员把系统视为一台单机，运行着一个线程；

对应用程序隐藏分布式和并发，而是由基础设施来考虑；

 

• • (异步请求) vs 调用返回方式(同步请求)em>

MMO的编程模型应是事件驱动的

服务器端部署事件监听器，监听客户端生成的事件；

如果检测到事件，服务器生成一项任务并执行；

服务器也可周期性的生成任务，不受客户端玩家的控制

 

• • C/S结构，它们如何划分功能em>

传统的企业应用的架构：瘦客户端+胖服务器；

MMO的架构：超胖的客户端+超瘦的服务器

MMO对客户端计算机CPU速度、内存和图形性能的要求极高，专门处理图形密集的、高度交互的任务；只要有可能，数据就存储在客户端；

服务器端则尽可能的保持简洁，仅保存共享的世界真实状态，在不同玩家之间保持一致，避免作弊。

 

• •  

传统企业应用中：90%的数据访问是只读的，只改写少量数据；

MMO中：大多数客户端任务只访问服务器上的少量状态数据，但其中50%被改写。

二、NoSQL

作为软件系统中用于存储和管理数据的重要工具，传统的关系数据库系统（RDBMS）多年来一直是主流；

随着互联 服务的兴起，出现了所谓的NoSQL和一系列相关开源产品。

通过查阅资料，了解NoSQL、它与传统SQL数据库的差异；

为什么NoSQL适合于互联 服务中的数据存储种场合下，它比传统SQL在哪些NFR方面做得更好em>

1. 关系型数据库

1.1什么是关系型数据库

关系数据库（Relational database），是创建在关系模型基础上的数据库，借助于集合代数等数学概念和方法来处理数据库中的数据。现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示。

• 数据库：包括一个或多个表
• 表（关系 Relation）：是以列和行的形式组织起来的数据的集合
• 列（属性 Attribute）：在数据库中经常被称为字段
• 行（值组 Tuple）：在数据库中经常被称为记录

我们可以理解为：系型数据库，是指采用了关系模型来组织数据的数据库。

在关系型数据库当中一个表就是一个关系，一个关系数据库可以包含多个表。

关系型数据库的主要代表：SQL Server，Oracle，MySQL，PostgreSQL。

1.2 关系型数据库优点

• 事务一致性：通过事务处理保持数据的一致性
• 复杂查询：支持SQL，可以进行 JOIN 等复杂查询
• 容易理解：二维表结构是非常贴近逻辑世界的一个概念，关系模型相对 状、层次等其他模型来说更容易理解
• 使用方便：通用的 SQL 语言使得操作关系型数据库非常方便
• 易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率

1.3 关系型数据库缺点

• 读写性能：在数据量达到一定规模时，由于关系型数据库的系统逻辑非常复杂，为了维护一致性，使得其非常容易发生死锁等的并发问题，所以导致其读写速度下滑非常严重
• 表结构更新：表结构可以在被定义之后更新，但是如果有比较大的结构变更的话就会变得比较复杂
• 高并发： 站的用户并发性非常高，往往达到每秒上万次读写请求，对于传统关系型数据库来说，硬盘I/O是一个很大的瓶颈
• 海量数据：对于关系型数据库来说，在一张包含海量数据的表中查询，效率是非常低的

2. 非关系型数据库

2.1 什么是非关系型数据库

非关系型数据库（NoSQL）是对不同于传统的关系数据库的数据库管理系统的统称。

当代典型的关系数据库在一些数据敏感的应用中表现了糟糕的性能，例如为巨量文档创建索引、高流量 站的 页服务，以及发送流式媒体。关系型数据库的典型实现主要被调整用于执行规模小而读写频繁，或者大批量极少写访问的事务。

NoSQL 的结构通常提供弱一致性的保证，如最终一致性，或交易仅限于单个的数据项。

NoSQL 提出另一种理念，例如，以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。

NoSQL 与 SQL 存在许多显著的不同点，其中最重要的是 NoSQL 不使用 SQL 作为查询语言。其数据存储可以不需要固定的表格模式，也经常会避免使用 SQL 的 JOIN 操作，一般有水平可扩展性的特征。

非关系型数据库包括：

临时性键值存储：memcached、Redis=

永久性键值存储：ROMA、Redis

面向文档的数据库：MongoDB、CouchDB

面向列的数据库：Cassandra、HBase

主要代表：MongoDB，Redis，CouchDB

2.2 非关系型数据库分类

由于非关系型数据库本身天然的多样性，以及出现的时间较短，相比关系型数据库，非关系型数据库非常多，并且大部分都是开源的。

非关系型数据库严格上不是一种数据库，应该是一种数据结构化存储方法的集合。依据结构化方法以及应用场合的不同，主要分为以下几类：

• 面向高性能并发读写的 key-value 数据库：key-value数据库的主要特点即使具有极高的并发读写性能，Redis，Tokyo Cabinet，Flare 就是这类的代表
• 面向海量数据访问的面向文档数据库：这类数据库的特点是，可以在海量的数据中快速的查询数据，典型代表为 MongoDB 以及 CouchDB
• 面向可扩展性的分布式数据库：这类数据库想解决的问题就是传统数据库存在可扩展性上的缺陷，这类数据库可以适应数据量的增加以及数据结构的变化

2.3 非关系型数据库优点

非关系型数据库的出现，多是源于关系型数据库的性能不足，故非关系型数据库的优点也很明显：

• 读写性能：无需经过 SQL 层的解析，读写性能很高。主要例子有Redis，由于其逻辑简单，而且纯内存操作，使得其性能非常出色，单节点每秒可以处理超过10万次读写操作；
• 简单的扩展：基于键值对，数据没有耦合性，容易扩展。典型例子是 Cassandra，由于其架构是类似于经典的 P2P，所以能通过轻松地添加新的节点来扩展这个集群；
• 存储格式多：支持key-value形式、文档形式、图片形式，而关系型数据库则只支持基础类型；
• 低廉的成本：这是大多数分布式数据库共有的特点，因为主要都是开源软件，没有昂贵的License成本；

2.4 非关系型数据库缺点

• 不提供对 SQL 的支持：如果不支持 SQL 这样的工业标准，将会对用户产生一定的学习和应用迁移成本
• 支持的特性不够丰富：现有产品所提供的功能都比较有限，大多数 NoSQL 数据库都不支持事务，也不像 MS SQL Server 和 Oracle 那样能提供各种附加功能，比如 BI 和 表等
• 现有产品的不够成熟：大多数产品都还处于初创期，和关系型数据库几十年的完善不可同日而语

3. 关系型数据库与 NoSQL

3.1 NoSQL 使用场景

并不是任何场景，NoSQL 都要优于关系型数据库。NoSQL 使用场景常见如下：

数据库表 schema 经常变化
比如在线商城，维护产品的属性经常要增加字段，这就意味着 ORMapping 层的代码和配置要改，如果该表的数据量过百万，新增字段会带来额外开销（重建索引等）。

数据库表字段是复杂数据类型
对于复杂数据类型，比如 SQL Sever 提供了可扩展性的支持，像 xml 类型的字段。DB 层对 xml 字段很难建高效索引，应用层又要做从字符流到 dom 的解析转换。NoSQL 以 json 方式存储，提供了原生态的支持，在效率方便远远高于传统关系型数据库。

高并发数据库请求
此类应用常见于 web2.0 的 站，很多应用对于数据一致性要求很低，而关系型数据库的事务以及大表 JOIN 反而成了”性能杀手”。

海量数据的分布式存储
海量数据的存储如果选用大型商用数据，如 Oracle，那么整个解决方案的成本是非常高的，要花很多钱在软硬件上。NoSQL 分布式存储，可以部署在廉价的硬件上，是一个性价比非常高的解决方案。

3.2 NoSQL 和关系数据库结合

一般把 NoSQL 和关系数据库进行结合使用，各取所长，需要使用关系特性的时候我们使用关系数据库，需要使用 NoSQL 特性的时候我们使用 NoSQL 数据库，各得其所。NoSQL 数据库是关系数据库在某些方面（性能，扩展）的一个弥补。

举个简单的例子吧，比如用户评论的存储，评论大概有主键 id、评论的对象 aid、评论内容 content、用户 uid 等字段。我们能确定的是评论内容 content 肯定不会在数据库中用 where content=’’ 查询，评论内容也是一个大文本字段。那么我们可以把主键 id、评论对象 aid、用户 id 存储在数据库，评论内容存储在 NoSQL，这样数据库就节省了存储 content 占用的磁盘空间，从而节省大量 IO，对 content 也更容易做 Cache。

另外，可使用 NoSQL 作为缓存服务器。MySQL + Memcached 的架构中，Memcached 这类内存缓存服务器缓存的数据大小受限于内存大小，如果用 NoSQL 来代替 Memcached 来缓存数据库的话，就可以不再受限于内存大小。虽然可能有少量的磁盘IO读写，可能比 Memcached 慢一点，但是完全可以用来缓存数据库的查询操作。

 

第七次作业

三种UML流派及异同

1. OMT（Object Modeling Technique）方法

OMT方法是1991年由JamesRumbaugh等5人提出的，经典著作为“面向对象的建模与设计”。

 特点是开发工作起始于对真实世界的对象建模上，然后围绕这这些对象使用这个模型来构造独立于语言的设计。建立三种模型：

•  描述系统数据结构的对象模型(object model).
•  描述系统控制结构的动态模型(dynamicmodel).
•  描述系统功能的功能模型(functionmodel).

1. Booch方法

Booch最先描述了面向对象的软件开发的基础问题，指出了面向对象开发方法是一种完全不同于传统的功能分解的设计方法。面向对象的软件分解方法更接近人对客观事物的理解，而功能分解只能通过问题空间的转换获得。

 

Booch方法包括各种模型，涉及软件系统的对象、动态及功能各方面，对类及继承方面的描述特别值得借鉴。

1. OOSE方法

Jacobson于1994年提出了OOSE方法,其最大特点是面向用例(Use-Case),并在用例的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武器,但用例贯穿于整个开发过程,包括对系统的测试和验证。OOSE比较适合支持商业工程和需求分析。

1. 三者建模能力比较（图源 络）
   1. 结构建模表

 

 

 

 

 

 

 

 

1. 1. 行为建模表

 

1. 1. 体系结构建模表

 

存在的问题

1. 面对众多的建模语言,用户由于没有能力区别不同语言之间的差别,因此很难找到一种比较适合其应用特点的语言;
2. 众多的建模语言实际上各有千秋;
3. 虽然不同的建模语言大多类同,但仍存在某些细微差别,极大地妨碍了用户间的交流。

统一建模语言(UML)

1. 特点：
   1. 统一了各种方法对不同类型的系统、不同的开发阶段以及不同内部概念的不同观点，消除了各建模语言之间的差异
   2. 不仅适合于一般系统的开发，对并行、分布式系统的建模尤为适宜
   3. 一种建模语言，而不是一个开发过程
   4. UML定义了用例图、类图、对象图、状态图、活动图、序列图、协作图、构件图、部署图等九种图
2. 目标
   1. UML是用于描绘软件蓝图的标准语言，不是可视化的程序设计语言,而是一种可视化的建模语言，其提出的目标是:
      1. 易用性：可进行可视化建模，编制说明和建立软件文档。
      2. 无关性：UML与具体的实现无关,与具体的过程无关, 可以用于任何语言任何开发过程。
      3. 复用性：UML强调在开发中对架构,框架,模式和组件的重用。
      4. 可扩展性：UML本身具有扩展机制。
3. 组成——对应的思想（红字部分体系的思想是根据自己的理解标注的，不代表正确答案）
   1. 事务
      1. 构建事务——UML的静态部分，描述概念，或者物理元素
         1. 类OOSE/Booch
         2. 接口
         3. 协作
            1. 一组事务间相互合作的集合
         4. 用例OOSE
         5. 构件
         6. 节点
      2. 行为事物——UML的动态部分，描述跨越空间和时间的行为Booch
         1. 交互——是实现某一功能用到的构件事物之间的消息的集合
            1. 消息OOSE
            2. 动作序列
            3. 链接
         2. 状态机——描述事务或交互在生命周期内响应事件所经历的状态序列
      3. 分组事务——描述事务的组织结构，主要有包来实现
         1. 包：把元素编组的机制。
      4. 注释事务
         1. 对元素进行约束或解释的简单符
   2. 图
      1. 用例图OOSE
      2. 类图Booch
      3. 对象图Booch/OOSE/OMT
      4. 状态机图OMT
      5. 活动图OOSE/OMT(数据)
      6. 顺序图OOSE/OMT
      7. 通信图
      8. 构件图OOSE/ Booch（模块）
      9. 包图
      10. 组合构件图Booch
      11. 定时图
      12. 交互概览图Booch
   3. 关系Booch
      1. 依赖——一个独立元素发生变化会影响另一个依赖元素的Booch
      2. 关联Booch
      3. 泛化——继承是一种泛化OOSE/Booch
   4. 实现——实现接口