第一章1、面向过程和面向对象首先是一个认识论，其次是方法论。

认识论决定方法论。

2、软件开发分成5个阶段：需求分析阶段，系统分析与设计阶段、系统实现阶段、测试阶段，维护阶段。

3、分析模型和设计模型最早在Jacobson的OOSE中就提出来了，不是RUP中首先提出的。

这两个模型的本质差别在于：1.分析模型是对问题域的描述，而独立于实现技术的。

2.设计模型是使用具体的实现技术实现分析模型，是依赖于实现技术的4、面向对象分析的主要活动包括：理解用例模型、识别分析类、定义交互行为、建立分析类图以及评审分析模型等面向对象分析应该建立：功能模型、分析对象模型和动态模型等三种类型。

其中功能模型由用例和场景表示，分析对象模型由类图和对象图表示，动态模型由状态图和顺序图表示。

4、面向对象中那些图代替了面向过程中的图？系统结构图——————用例图IPO图——————时序图或协作图数据流图——————带有实现类的活动图(带泳道)E-R ——————类图和对象图第二章1、UML不是系统设计的方法，只是一种表示法。

UML（Unified Modeling Language 统一建模语言）是一种定义良好、易于表达、功能强大且普遍适用的建模语言（更不是编程语言）。

UML是一个标准的图形表示法，它不是面向对象的分析和设计，也不是一种方法，它仅仅是一组符号而已。

2、在理解用户需求方面UML提供了有用例图、时序图、活动图、状态图。

在描述系统的静态结构方面，UML提供了类图、对象图、包图、用例图。

在描述系统的动态结构方面，UML提供了活动图、时序图、状态图、协作图。

系统设计，系统分析，用户需求都要用到的图：时序图。

3、UML的作用（why）?答：1.为软件系统建立可视化模型2.为软件系统建立构件3.为软件系统建立文档4.UML比任何一种程序语言的语义都丰富。

5.UML的类图是E-R图的超集4、UML由基本词汇和语法两个部分构成，包括了UML语义和UML表示法两个部分。

一般情况下，状态图被作为是对类图的具体补充。

5、补充类图是用例图的细化，所有图都是用例图的细化。

状态图和活动图在语义上是等价的，时序图与协作图也是。

如果强调时间和顺序，则使用顺序图；如果强调上下级关系，则选择合作图。

两者之间可以相互转换。

6、行为图包括有状态图、活动图。

交互图包括有时序图和协作图。

实现图包括有构件图和部署图。

第三章1、Why：为什么软件企业要采用行之有效的软件过程？答：行之有效的软件过程可以提高软件企业的开发效率：首先，通过理解软件开发的基本原则有助于对软件开发过程中重要的问题作出明智的决定；其次，可以促进开发工作的标准化、促进项目小组之间的可重用性和一致性；第三，它提供了一个可以使软件企业引进行业内先进实践技术的机会，这些技术包括代码检测、配置管理、变更控制和体系结构建模等2、RUP是由Rational软件公司开发的一种预定义好的软件过程框架。

软件项目真正的灵魂是软件过程3、RUP有三个突出的特点：（1）用例驱动；（2）以架构为中心；（3）采用迭代和增量模型4、RUP过程框架模型每个循环包括四个阶段：初始、细化、构建和产品化。

每个阶段的主要工作是：初始化阶段的主要工作是：业务建模、需求分析，次要工作是分析设计、项目管理。

里程碑：命周期目标里程碑；细化阶段的主要工作是：需求、分析设计、实施。

里程碑：周期结构里程碑；构建阶段的主要工作是：实施，配置与变更管理，部署。

里程碑：功能里程碑；产品化阶段的主要工作是：配置与变更管理，部署。

里程碑：发布里程碑；5、RUP可用4个基本元素来表达：1.角色（Workers, the "who" ）2.活动（Activities, the "how" ）3.产出品（Artifacts, the "what" ）4.工作流（Workflows, the "when" ）一个工作流可以被表述为一个序列图（sequence diagram ）, 一个协同图（collaboration diagram ）, 或者一个活动图（an activity diagram ）。

7、RUP核心工作流：业务建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在业务用例模型和业务对象模型中定义组织的过程，角色和责任在需求捕获阶段、分析设计阶段和测试阶段，都使用相同的use-case 模型。

设计模型是代码如何编写的蓝图。

整个系统是通过构件的实现而实现的测试的执行是沿着三个质量维度进行的：可靠性，功能、性能。

8、补充：角色并不代表个人，而是说明个人在业务中应该如何表现以及他们在业务活动中应该承担的责任9、Why: 投入那么多成本来实施统一过程值得吗？1.采用统一过程可以提髙软件成熟度。

2.采用统一过程可以提髙软件技术水平和质量的需要。

3.统一过程适于开发稳定的架构，它通过不断的演进来逐步推进软件产品，这一特点使得它特别适合于长期战略的软件产品。

10、适用场合：对于大型公司和大型项目来说，RUP却非常适合。

Relations: RUP和XP也不是非此即彼的关系，比如对整体项目来说，用RUP是适合的，具体到细部倒是可以应用XP。

第五章1、为什么会有衍生型？答：在建模的不同阶段，为了区分同一视图在不同阶段的区别，会用不同的图来表示2、使用者有三大类：系统用户、与所构建的系统交互的其它系统和一些可以运行的进程（对第三类使用者的说明：当经过一定的时间触发系统中的某个事件时，时间就成了使用者）。

3、How：如何确定使用者？答：①从系统边界内外的角度，通过回答问题确定使用者：谁对系统有着明确的目标和要求并且主动发出动作？系统是为谁服务的？谁对系统产生的结果感兴趣②从涉众和岗位设置的角度回答问题以确定使用者。

③从外部系统的角度回答问题以确定使用者。

④从系统内进程或定时做某项工作的角度。

4、业务范围和系统范围是不同的？业务范围指项目所涉及的所有客户业务，这些业务有没有软件系统都客观存在。

系统范围则是指软件实现的那些对应于业务功能的系统功能。

从功能性需求来说系统范围是业务范围的一个子集5、（Why）建立业务模型、查找业务用例都必须使用业务主角。

（How）如何使用业务主角？答：(1). 在查找业务主角时必须抛开计算机。

这是因为在初始需求阶段，需要获得的是客户的业务模型，根据业务模型才能建立计算机系统模型。

(2). 业务主角必须在实际业务里能找到对应的岗位或人员。

6、业务工人：图书馆管理员是业务工人，借阅者是使用者。

在建模时，有些人员是被动参与业务的，而且是在系统之内，被称为“业务工人”。

不需要为他们建立业务模型。

（How）如何区分使用者和业务工人呢？最直接的办法是判断是在边界之外还是边界之内。

如果边界尚不清楚，可以通过下面的三个问题确定边界：◆他是主动向系统发出动作的吗？◆他有完整的业务目标吗？◆系统是为他服务的吗？7、Relations：使用者与涉众、操作者及角色的关系？⑴.使用者与涉众的关系◆并不是所有的涉众都是系统的使用者。

◆使用者是涉众的代表。

使用者对系统的要求直接影响系统的建设，他们的要求就是系统需求的来源。

使用者通过对系统提出要求来获得他所代表的涉众的利益。

⑵.使用者与操作者的关系1) 操作者是使用者的实例或代理。

一个操作者可以代理多个使用者。

2) 并非所有的使用者都是操作者⑶.使用者与角色的关系1)一个角色代表了系统中的一类职责。

例如办公自动化系统中。

2)由于一个用户可以代理多个使用者，因此一个用户可以拥有多个职责，也就是可以被指定多个角色。

角色一般适合用在概念阶段的模型里，以表达业务的逻辑理解。

处于核心地位的是使用者通信关联关系和用例说明表明使用者和系统是如何相互关联关系的。

是否有两个使用者担任与用例相关的同一角色？如果有，应该利用使用者泛化关系来为他们的共享行为建立模型。

其他的动作都是合并8、用例一是由使用者启动，用例不能没有启动者；二是结果对使用者要可观测；三是结果对使用者要有意义；四是多种可能活动场景集合成一个用例。

一个完整的用例定义由使用者、前置条件、场景、后置条件构成。

业务模型是系统模型的最重要输入。

1、业务用例实现是实现对象追溯到需求的一个重要环节。

在后续的建模过程中，根据业务用例实现将得出关键业务对象，再从业务对象转化到设计对象，生成代码。

2、业务用例与系统用例的区别体现在：业务用例可以理解为使用者的行为，是客户能提出的需求。

系统用例可理解为系统的行为，来支持/协助使用者完成其行为，是对需求的另一方面的阐述。

业务用例是客户业务视角，而系统用例则是系统视角。

3、业务用例模型与系统用例模型之间的关系⑴.业务用例模型与系统用例模型图的相似之处◆两者都有参与者。

在业务用例图中，将一个参与者原型化为<<BusinessActor>>。

两者都有用例。

在业务用例模型中，将一个用例原型化为<<Business用例>>◆在参与者与用例之间两者都有一个通信关联。

◆业务用例和系统用例都能够包含、扩展，以及一般化关联。

⑵．不同之处在于设计范围：业务用例着重于业务操作，系统用例着重于要设计的软件系统。

白盒测试与黑盒测试：业务用例常常是以白盒形式编写的，系统用例以黑盒形式编写的业务操作者：在系统用例图中，只让参与者与用例进行交互。

但在业务用例图中，可以让业务参与者和业务角色与业务用例进行交互。

4、UML 业务模型包括两个模型:用例视图（Use-Case View）中的业务用例模型(用例图)和逻辑视图（Logical View）中的业务分析模型（类图，时序图、通信图）用例视图（Use-Case View）中的业务用例模型和逻辑视图（Logical View）中的业务分析模型5、用例的特征：a 完备性：用例在“功能”上是完备的b. 可观测和有意义性：用例的执行结果对使用者来说是可观测的和有意义的。

c用例总是由一个使用者发起的，使用者的愿望是这个用例存在的原因。

不存在没有使用者的用例，用例不应该自动启动，也不应该主动启动另一个用例。

d．用例必然是以动宾短语形式出现的6、评判有效用例的三种测试的方法：老板测试、EBP测试、规模测试。

看看就是了：EBP测试用一种更加精确的方式量化了用例的有效性。

它除了要求进行有价值的业务操作以外，还必须产生有价值的、持续保留的数据。

同时，它还要求了完成这个任务的时效性，即必须在一个会话中完成。

持续数日或跨越多个会话的用例都不能通过这个测试。

不能通过规模测试的一个典型错误，就是将系统的一个步骤中作为用例。

7、发现用例的前提条件是发现使用者；而确定使用者的同时就确定了系统边界。