软件工程导论知识点概要.doc

1.1 软件危机
软件危机的表现
软件危机是指在计算机软件的开发、使用和维护过程中遇到的一系列严重问题。
1）成本难以估计、成本高。
2）软件开发进度估计不准确，项目延期比比皆是。
3）软件质量得不到保证（功能和性能）。
4）用户对“已完成的”软件系统不满意的现象经常发生。
5）维护非常困难(多样性 、复杂性、 副作用)。
6）软件通常没有适当的文档。
7）软件产品供不应求，跟不上计算机普及速度。

产生软件危机的原因
（1）与软件本身的特点有关 (逻辑复杂，成本高，风险大,难于维护)。
（2）与软件开发与维护的方法不正确有关：
软件≠程序（软件是程序、数据及相关文档的完整集合）
急于求成=拔苗助长(软件从定义、开发、使用和维护、废弃要经历一个漫长的生命周期)
各自为阵无方法学（应要组织良好、管理严密、各类人员协作共同完成的工程项目）
1.2 软件工程定义
软件工程是应用计算机科学、数学、心理学及管理科学等原理开发软件的工程。它借鉴传统工程的原则、方法，以提高质量、降低成本和提高效率为目的。
软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。
软件工程的特性：
1. 软件工程关注于大型程序的构造
（传统的程序设计技术和工具是支持小型程序设计的）
2. 软件工程的中心课题是控制复杂性（问题分解）
3. 软件经常变化（考虑将来要发生的变化）
4. 开发软件的效率非常重要（寻求更好、更有效的工具）
5. 和谐地合作是开发软件的关键（运用标准和规程）
6. 软件必须有效地支持它的用户（软件要服务于用户）
7. 在软件工程领域中通常是由具有一种文化背景的人替具有另一种文化背景的人创造产品
软件工程的7条基本原理
1.用分阶段的生命周期计划严格管理
2.坚持进行阶段评审
3.实行严格的产品控制
4.采用现代程序设计技术
5.结果应能清楚地审查
6.开发小组的人员应该少而精
7.承认不断改进软件工程实践的必要性
软件工程方法学
通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学(methodology)，也称为范型(paradigm)。
目前使用得最广泛的软件工程方法学，分别是传统方法学和面向对象方法学。
软件工程方法学包含3个要素：方法、工具和过程。
1.3 软件生命周期
每阶段的基本任务:
1. 问题定义
2. 可行性研究
3. 需求分析
4. 总体设计
5. 详细设计
6. 编码和单元测试
7. 综合测试
8. 软件维护
1.4 软件过程
软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
通常包括四种基本的过程活动： （１）软件规格说明；（２）软件开发；（３）软件确认；（４）软件演进
软件过程模型:
软件开发程模型是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。
几种典型的模型：瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型、RUP等。
软件过程模型的选择基于项目和应用的性质、采用的方法工具以及需要的控制和交付的产品。
瀑布模型(Waterfall Model ）:
传统瀑布模型：规定了各项软件工程活动，包括：制定开发计划、需求分析和说明、软件设计、程序编码、测试、运行维护。并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
特点：
1、阶段间具有顺序性和依赖性。
2、推迟实现。
3、质量保证。
优点:
1、可强迫开发人员采用规范的方法（例如，结构化技术）； 严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
2、瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。
3、瀑布模型适合于用户需求明确、完整、无重大变化的软件项目开发!!
问题：
1、不适应需求经常发生变更的环境：在项目的开发过程中，变更可能会引起混乱。所以，有人形象地把采用线性模型进行商业软件工程称之为“在沙滩上盖楼房”。（适合于用户需求明确、完整、无重大变化的软件项目开发）
2、线性顺序模型每一步的工作都必须以前一阶段的输出为输入，这种特征会导致工作中发生“阻塞”状态。
3、由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。
4、是一种整体开发模型，程序的物理实现集中在开发阶段的后期，用户在最后才能看到自己的产品。在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。
快速原型模型（Rapid Prototype Model）
步骤：第一步进行试验开发，得出产品的“原型”，其目的在于弄清软件需求并探索可行性；第二步在原型的基础上开发出较为满意的软件产品。
该模型克服了瀑布模型的部分缺陷，减少了软件需求不明确给开发工作带来的风险。
前提:
(1)是用户必须积极参与原型的建造，建造原型仅仅是为了定义需求，之后就必须被全部抛弃(至少是部分抛弃)，实际的软件必须在充分考虑到软件质量和可维护性之后才被开发。从这个意义上说，原型模型又往往被称为“抛弃原型模型”。
(2)是必须有快速开发工具可供使用。
增量模型 (Incremental Model)
是一种渐进地开发逐步完善的软件版本的模型，该模型一般首先开发产品的基本部，然后再逐步开发产品的附加部分。
整个软件产品被分解成许多个增量构件。每个构件由多个相互作用的功能模块构成，并能够完成特定的功能。
该增量模型表明：必须在开始实现各个构件之前就全部完成需求分析、规格说明和概要设计，因此风险较小。
优点：是十分有用的一种模型。在克服瀑布模型缺点、减少由于软件需求不明确而给开发工作带来风险方面，确有显著的效果；缩短产品提交时间都能够起到良好的作用。
困难：
1、在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。
2、开发人员既要把软件系统看作整体。又要看成可独立的构件，因此相互矛盾。除非开发人员有足够的技术能力协调好。
3、多个构件并行开发，具有无法集成的风险
螺旋模型 (Spiral Model)
优点：对于高风险的大型软件，螺旋模型是一个理想的开发方法。
缺点：风险驱动，需要相当丰富的风险评估经验和专门知识，否则风险更大。
适合场合：
主要适用于内部开发的大规模软件项目，随着过程的进展演化，开发者和用户能够更好地识别和对待每一个演化级别上的风险。只有内部开发的项目，才能在风险过大时方便地中止项目。
如果进行风险分析的费用接近整个项目的经费预算，则风险分析是不可行的。
喷泉模型 (Fountain Model)
特点：喷泉模型的各阶段均采用了“对象”这一统一范式，整个过程看起来像喷泉从喷出到落下再喷出的周而复始过程产生的光滑水柱，体现了软件创建所固有的迭代和无间隙的特征。
适合场合：喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。
Rational统一软件开发过程
RUP软件开发生命周期是一个二维的软件开发模型。横轴代表时间，体现生命周期特征；纵轴代表工作流，体现了开发过程的静态结构。
RUP中的软件生命周期在时间上被分解为四个顺序的阶段：初始、细化、构造和移交。每个阶段围绕着9个核心工作流分别迭代。
适合场合：可开发或大或小、分布在各个领域的项目，表明了RUP的多功能性和广泛适应性。适合于需求不稳定、不全面的软件项目开发。

1.5 小结
软件 =程序+数据+文档
软件危机: 原因,现象,办法 (软件工程学)
软件工程:指导计算机软件开发和维护的一门工程科学
软件工程3个要素：方法、工具和过程。
软件生命周期:定义,开发,运行维护
软件过程: 瀑布模型，快速原型模型、增量模型、螺旋模型、喷泉模型、RUP等

2.1 可行性研究目的：
用最小的代价在尽可能短的时间内确定问题是否能够解决。
2.2 可行性研究的主要内容
(1) 技术可行性
(2) 经济可行性
(3) 操作可行性
(4) 法律可行性
(5) 社会可行性

2.3 数据流图
1、一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。
2、它只是描绘数据在软件中流动和被处理的逻辑过程，是系统逻辑功能的图形表示。
3、设计数据流图时只需考虑系统必须完成的基本逻辑功能，完全不需要考虑怎样具体地实现这些功能。
画数据流图的方法：
1、自顶向下，逐步求精
2、先画顶层DFD，描绘系统的整体逻辑概貌；顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据。
3、其次画中间层流图：对上层父图的处理的细化，形成子图。底层流图是指其加工不需要在做分解的数据流图，它处在最底层。
注意：数据流图应该分层，并且在把功能级数据流图细化后得到的处理超过9个时，应该采用画分图的办法。当把一个处理分解为一系列处理时，分解前和分解后的输入输出数据流必须相同！
数据流图用途：
1、画数据流图的基本目的是利用它作为交流信息的工具。
2、分析员把他对现有系统的认识或对目标系统的设想用数据流图描绘出来，供有关人员审查确认。
3、由于在数据流图中通常仅仅使用4种基本符号，而且不包含任何有关物理实现的细节，因此，绝大多数用户都可以理解和评价它。
4、数据流图着重描绘系统所完成的功能，其另一个主要用途是作为辅助物理系统的分析和设计的工具。
2.4 小结
1、可行性研究的任务: 技术, 经济,社会
2、可行性研究过程: 8 步骤
3、数据流图: 源点或终点，处理，数据存储和数据流
4、数据字典: 是分析阶段的工具，包括流，元素，存储，处理4类元素组成。
5、成本/效益分析：从经济角度判断是否继续投资于这项工程的主要依据。
3.1 需求分析的具体任务
确定对系统的综合要求：
1、功能需求
2、性能需求
3、可靠性和可用性需求
4、出错处理需求
5、接口需求
6、约束
7、 逆向需求
8、将来可能提出的要求
分析系统的数据要求:
建立数据模型，用图形化的工具描述数据结构（如层次方框图和warnier图）。
导出系统的逻辑模型
数据流图、实体－联系图、状态转换图、数据字典等。
修正系统开发计划：
由分析过程准确地估计系统的成本和进度，修正以前制定的开发计划。
3.2 与用户沟通获取需求的方法
1、访谈
2、面向数据流自顶向下逐步求精
3、简易的应用规格说明技术
4、快速建立软件原型（它应该实现用户看得见的功能，原型要具有快速并容易修改的特点）
3.3 数据规范化
规范化的目的是：
1、消除数据冗余，即消除表格中数据的重复；
2、消除多义性，使关系中的属性含义清楚、单一；
3、使关系的“概念”单一化，让每个数据项只是一个简单的数或字符串，而不是一个组项或重复组；
4、方便操作。使数据的插入、删除与修改操作可行并方便；
5、使关系模式更灵活，易于实现接近自然语言的查询方式。
3.4 状态转换图(状态图)
通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。
状 态
1、状态规定了系统对事件的响应方式。
2、系统对事件的响应，既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。
3、可分为：初态(初始状态)；终态(最终状态)；中间状态
4、一张状态图中只能有一个初态，而终态则可以有0至多个。
事 件 事件就是引起系统做动作或(和)转换状态的控制信息。

符 号

1、初态用实心圆表示，终态用一对同心圆(内圆为实心圆)表示
2、中间状态用圆角矩形表示，分成上、中、下3个部分。
3、 活动表的语法格式：事件名(参数表)/动作表达式
(1)“事件名”可以是任何事件的名称。在活动表中经常使用下述3种标准事件：entry，exit和do。
(2) entry事件指定进入该状态的动作，exit事件指定退出该状态的动作，而do事件则指定在该状态下的动作。需要时可以为事件指定参数表。
(3) 动作表达式描述应做的具体动作。
4、事件表达式的语法：事件说明[守卫条件]/动作表达式
(1) 事件说明：事件名（参数表）
(2) 动作表达式：当状态转换开始时执行该表达式。
(3) 守卫条件是一个布尔表达式，如果既有事件说明又有守卫条件，则当事件发生且守卫条件为真是状态转换才发生，如果只有守卫条件没有事件说明，则守卫条件为真时，发生状态转换。
5.1 设计过程
1. 设想供选择的方案；2. 选取合理的方案；3. 推荐最佳方案；4.功能分解；5. 设计软件结构；6. 设计数据库；7. 制定测试计划；8. 书写文档；9. 审查和复审
5.2 设计原理
模块化
1、把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，这些模块集成起来构成一个整体，可以完成指定的功能以满足用户的需求。
2、模块是由边界元素限定的相邻程序元素的序列，而且有一个总体标识符代表它。模块是构成程序的基本构件。
3、过程、函数、子程序和宏等，都可作为模块。
4、面向对象方法学中的对象是模块，对象内的方法（或称为服务）也是模块。
模块化的好处:
1、可以降低软件开发的难度；
2、可以使程序结构清晰，增加易读性和易修改性；
3、模块化还有利于提高代码的可重用性及团队合作开发大型软件的可行性。
抽象
抽象是人类在解决复杂问题时经常采用的一种思维方式，它是指将现实世界中具有共性的一类事物的相似的、本质的方面集中概括起来，而暂时忽略它们之间的细节差异。结构化程序中自顶向下、逐步求精的模块划分思想正是人类思维中运用抽象方法解决复杂问题的体现。
逐步求精
定义：为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。
好处：
1、降低了软件开发中每个阶段的工作难度；
2、简化了软件的设计和实现过程；
3、有助于提高软件的可读性、可测试性和可维护性；
4、在程序设计中运用抽象的方法还能够提高代码的可重用性。
信息隐藏和局部化
1、信息隐藏：设计和确定模块，使得一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说，是不能访问的。
目的：主要是为了提高模块的独立性，减少将一个模块中的错误扩散到其他模块的机会。模块之间的信息传递只能通过合法的调用接口来实现。信息隐蔽对提高软件的可读性和可维护性都是非常重要的。
2、局部化：是指把一些关系密切的软件元素物理地放得彼此靠近。如模块中的局部数据元素是局部化的一个例子。
3、局部化和信息隐藏概念是密切相关的，局部化有助于信息隐藏
模块独立
模块的独立性是指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他模块的接口是简单的。
1、耦合：不同模块之间互连程度的度量。
2、内聚：模块功能强度的度量。
3、模块独立是模块化、抽象、信息隐藏和局部化概念的直接结果。
3、优点：比较容易开发出有效模块化(即具有独立的模块)的软件；独立的模块比较容易测试和维护。
4、耦合：
(1) 数据耦合：若两个模块之间仅通过模块参数交换信息，且交换的信息全部为简单数据，则称这种耦合为数据耦合。耦合性最低。
(2) 控制耦合：若模块之间交换的信息中包含有控制信息(尽管有时控制信息是以数据的形式出现的)，则称这种耦合为控制耦合。控制耦合是中等程度的耦合，它会增加程序的复杂性。
(3) 特征耦合：当把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素。
(4) 公共环境耦合：若两个或多个模块通过引用公共数据相互联系。
(5) 内容耦合：一个模块访问另一个模块的内部数据；一个模块不通过正常入口而转到另一个模块的内部；两个模块有一部分程序代码重叠；一个模块有多个入口(这意味着一个模块有几种功能)。
(6) 尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不用内容耦合。
5、内聚：低内聚：偶然内聚，逻辑内聚，时间内聚
中内聚：过程内聚，通信内聚
高内聚：顺序内聚，功能内聚
6、高内聚，低耦合
6.1 结构程序设计
1、结构程序设计技术：是实现质量要求的基本保证,是详细设计的逻辑基础。
2、结构程序设计定义：
① 一个程序的代码块仅仅通过顺序、选择和循环这三种基本的控制结构进行连接；
②并且每个代码块只有一个入口和一个出口。
- 3、只用三种基本的控制结构(顺序,选择,循环)就能实现任何单入口单出口的程序。从而实现结构程序设计。
4、三种基本结构的共同特点：
(1) 只有一个入口；
(2) 只有一个出口；
(3) 结构内的每一部分都有机会被执行到；
(4) 结构内不存在“死循环”(无终止的循环)。

5、结构程序设计的特点：
(1) 由三种基本结构顺序组成的，可以解决任何复杂的问题。
(2) 程序内不存在无规律的转向，只在基本结构内才允许存在分支和向前或向后的跳转。
6.2 过程设计的工具
（1）过程设计是设计模块的详细步骤（算法），是详细设计阶段应完成的主要工作。
（2）过程设计的工具描述程序处理过程的工具。

程序流程图的优缺点:
主要优点：对控制流程的描绘很简明直观、易于理解，便于初学者掌握。
主要缺点：
(1) 本质上不是逐步求精的好工具。
----改进：PAD图
(2) 用箭头代表控制流，描述程序时可以随意跳转。
----改进：N-S图
(3) 不易表示数据结构。
----改进：PAD图
(4) 嵌套的条件选择表示不清。
----改进：判定树、判定表
PAD图（问题分析图）
PAD图的特点：
(1) 能展现算法的层次结构；
(2) 表示形式直观易懂；
(3) 既可用于表示程序逻辑，又可用于描述数据结构；
(4) 支持自顶向下，逐步求精的过程。
判定表
当算法中包含多重嵌套的条件选择时，用程序流程图、盒图、PAD图等都不易清楚地描述，然而，判定表能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。
判定表的优缺点：
优点：判定表能够简洁而无歧义地描述处理规则。可以对判定表进行校验或化简。
缺点：并不适于作为一种通用的设计工具，直观性不够。
判定树
判定树是用来表达加工逻辑的一种工具。比判定表更直观，是一种常用的系统分析和设计工具。
判定树的优缺点：
优点：比判定表更直观。
缺点：
(1) 不够简洁，数据元素重复多次地写。
(2) 画判定树时分枝的次序对简洁程序有影响。
PDL程序设计语言
(1) 是一种非形式化、比较灵活的混杂语言。也称为伪码。
(2) 用于描述模块内部过程的具体算法，以便在开发人员之间比较精确的进行交流。
PDL的优缺点:
优点：
(1)可以作为注释直接插入到源程序中。有利于PDL和源程序保持一致性。
(2) PDL编写方便。
(3)可以由自动处理程序将PDL生成程序代码。
缺点：
(1) 不如图形工具形象直观。
(2) 描述复杂的条件组合与动作间的对应关系时，不如判定表清晰简单。
6.5 程序复杂程度的定量度量
McCabe方法
基本原理：根据程序控制流的复杂程度定量度量程序的复杂程度（称为程序的环形复杂度）。
采用“流图”：仅描绘程序的控制流程，完全不表现对数据的具体操作及分支或循环的具体条件。
基本步骤：
(1) 将程序流程图或PDL等映射为流图。
(2) 基于流图计算环形复杂度，以定量度量程序的复杂程度。
流图
定义：
—仅仅描绘程序的控制流程
基本符号：
—圆：表示结点，代表一条或多条语句。
—箭头线：边
—区域：由边和圆围成的面积
基本原则:
—合并原则：顺序处理框和菱形判定框、顺序处理框序列分别合并映射成流图中的一个结点。
—分解原则：复合条件分解为若干个简单条件，每个简单条件映射成流图中一个结点。
—其他情况下的框映射成流图中的一个结点。
计算环形复杂度的方法：
(1) 流图中的环形复杂度V(G)=区域数。
(2) 流图G的环形复杂度V(G)=E-N+2,其中，E是流图中边的条数，N是结点数。
(3) 流图G的环形复杂度V(G)=P+1，其中，P是流图中判定结点的数目。
环形复杂度的用途：
(1) 可以用于比较两个算法的优劣。对测试难度的一种定量度量。
(2) 作为模块规模的精确限度。环形复杂度高的程序往往是最困难、最容易出问题的程序。实践表明，模块规模以V(G)≤10为宜。
7.1 软件测试基础
根本目标
尽可能多地发现并排除软件中潜藏的错误，最终把一个高质量的软件系统交给用户使用。
软件测试准则
(1) 所有测试都应该能追溯到用户需求。
(2) 应该远在测试开始之前就制定出测试计划。
(3) 把Pareto原理应用到软件测试中。（测试发现的错误中的80%很可能是由程序中20%的模块造成的。）
(4) 应该从“小规模”测试开始，并逐步进行“大规模”测试
(5) 穷举测试是不可能的。
(6) 为了达到最佳的测试效果，应该由独立的第三方从事测试工作。
测试方法
测试步骤
(1) 模块测试；(2) 子系统测试；(3) 系统测试；(4) 验收测试；(5) 平行运行
7.2 白盒测试技术
逻辑覆盖 以程序的逻辑结构为基础设计测试用例的技术。
(1)语句覆盖 使程序中每个语句至少执行一次。
(2)判定覆盖 使每个判定的真假分支都至少执行一次。
(3)条件覆盖 使每个判定的每个条件的可能取值至少执行一次。
(4)判定/条件覆盖 每个条件的所有可能取值至少执行一次；使每个判定的真假分支都至少执行一次。
(5)条件组合覆盖 所有可能的条件取值组合至少执行一次。满足条件组合覆盖的测试数据，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。覆盖标准相对较强，但是也不意味着所有的路径都能被执行到。
(6)路径覆盖 使程序中每条可能路径都至少执行一次。
控制结构测试
基本路径测试（常用）
第1步：画出程序流图
第2步：计算程序的环形复杂度P （表示程序基本路径集中的独立路径数的上限）
第3步：确定独立路径的基本集合
第4步：从该基本集合导出测试用例
第5步：执行测试用例
第6步：写测试报告
条件测试 条件成分的类型包括布尔算符、布尔变量、布尔括弧（括住简单条件或复合条件）、关系算符及算术表达式。
循环测试 （1）简单循环；（2）嵌套循环；（3）串接循环

7.3 黑盒测试技术
黑盒测试着重测试软件功能。黑盒测试并不能取代白盒测试，它是与白盒测试互补的测试方法，它很可能发现白盒测试不易发现的其他类型的错误。
黑盒测试力图发现下述类型的错误：
①功能不正确或遗漏了功能；
②界面错误；
③数据结构错误或外部数据库访问错误；
④性能错误；
⑤初始化和终止错误。
黑盒测试技术：
(1)等价划分法：把程序的输入域划分成若干个数据类，据数据类导出测试用例。(2)边界值分析法。(3)错误推测法。(4)因果图法等
9.1 面向对象的概念
1）对象 对象是封装了数据和行为的通信单位。
2）类 类是对具有相同数据和相同操作的一组对象的定义，即类是对具有相同属性和行为的对象的描述。
3）消息 对象之间进行通信的构造或结构。消息分为请求消息和完成消息两种 (由消息模式描述)。消息模式：发送对象、接收对象、内容
4）封装 面向对象的一个重要原则。封装是指在面向对象的程序中，把数据和实现操作的代码集中起来放在对象内部。
5）继承 面向对象描述类之间相似性的重要机制，子类自动地共享基类中定义的数据和方法的机制。
6）多态性 允许每个对象以自己最合适的方式去响应共同的消息，从而增强软件的灵活性和可复用性。
7）重载 函数重载是指在同一作用域内具有多个同名的函数，这些函数具有若干个不同的参数特征；运算符重载是指同一个运算符可以施加于不同类型的操作数上。
9.4 对象模型
对象模型表示静态的、结构化的系统的“数据”性质。它是对模拟客观世界实体的对象以及对象彼此间的关系的映射，描述了系统的静态结构。
类图的基本符号
1. 定义类
UML中类的图形符号为长方形，分成上、中、下3个区域（下面两个区域可省略），分别放类的名字、属性和服务。类名应该是富于描述性的、简洁的而且无二义性的。
2. 定义属性
UML描述属性的语法格式如下：
[可见性] 属性名： 类型名=初值 {性质串}
属性的可见性（即访问性）：共有的(public)、私有的(private)和保护的(protected)，分别用加号(+)、减号(-)和井号(#)表示。
3. 定义服务
服务也就是操作，UML描述操作的语法格式如下：
可见性 操作名（参数表）： 返回值类型{性质串}
参数表是用逗号分隔的形式参数的序列。描述一个参数的语法： [参数名：]类型名[=默认值]
表示关系的符号
1. 关联 关联表示两个类的对象之间存在某种语义上的联系。
1）普通关联：类与类之间存在连接关系就可以用普通关联表示。
2）关联的角色：在任何关联中都会涉及到参与此关联的对象所扮演的角色（即起的作用），如果没有显式标出角色名，则意味着用类名作为角色名。
3）限定关联：通常用在一对多或多对多的关联关系中，可以把模型中的重数从一对多变成一对一，或从多对多简化成多对一。
4）关联类：说明关联的性质可能需要一些附加信息。关联类通过一条虚线与关联连接。关联类与一般类一样，也有属性、操作和关联。关联中的每个连接与关联类的一个对象相联系。
2. 聚集 也称为聚合，是关联的特例。聚集表示类与类之间的关系是整体与部分的关系
1）共享聚集：在聚集关系中处于部分方的对象可同时参与多个处于整体方对象的构成。一般聚集和共享聚集的图示符号，都是在表示关联关系的直线末端紧挨着整体类的地方画一个空心菱形。
2）组合聚集：如果部分类完全隶属于整体类，部分与整体共存，整体不存在了部分也会随之消失（或失去存在价值了），则该聚集称为组合聚集（简称为组成）。组成关系用实心菱形表示。
3. 泛化 就是通常所说的继承关系，它是通用元素和具体元素之间的一种分类关系。具体元素完全拥有通用元素的信息，并且还可以附加一些其他信息。用一端为空心三角形的连线表示泛化关系，三角形的顶角紧挨着通用元素。
1）普通泛化：普通泛化与继承基本相同。没有具体对象的类称为抽象类。抽象类通常作为父类，用于描述其他类（子类）的公共属性和行为。图示抽象类时，在类名下方附加一个标记值{abstract}。
2）受限泛化：给泛化关系附加约束条件，以进一步说明该泛化关系的使用方法或扩充方法。
3）多重继承：一个子类可以同时多次继承同一个上层基类。
9.5 动态模型
动态模型表示瞬时的、行为化的系统的“控制”性质，它规定了对象模型中的对象的合法变化序列。
9.6 功能模型
用例图
一幅用例图包含的模型元素有系统、行为者、用例及用例之间的关系。
1）用例：表示系统提供的服务，主要刻画系统如何被参与者使用。Use Case是UML中一个非常重要的概念。用例是对一组动作序列的抽象描述，系统执行这些动作序列，将产生相应的结果。用例也可以理解为参与者为了使用系统提供的某一完整功能而和系统之间发生的一段对话。用例描述一般包括：简要描述（说明）、前置（前提）条件、基本事件流、其他事件流、异常事件流、后置（事后）条件等等。
2）用例之间的关系：
扩展关系：向一个用例中添加一些动作后构成了另一个用例，用例间即为扩展关系。
使用关系：当一个用例使用另一个用例时，用例间即构成了使用关系。
两者区别：
（1）通常描述一般行为的变化时采用扩展关系。
（2）在两个或多个用例中出现重复描述又想避免这种重复时，可以采用使用关系。
用例建模
1）与传统的功能分解方式相比，用例建模方法完全是从外部来定义系统的功能，它把需求与设计完全分离开来。
2）在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求。
3）用例建模步骤：识别参与者；识别用例 ；识别关系；建模
面向对象方法学优点：
1、与人类的思维习惯相一致；2、稳定性好；3、可重用性好；4、较易开发大型软件产品；5、可维护性
10.3 建立对象模型
确定类与对象
1. 找出候选的类与对象：
可感知的物理实体；人或组织的角色；应该记忆的事件；两个或多个对象的相互作用，通常具有交易或接触的性质；需要说明的概念
2.筛选出正确的类与对象：
（1）冗余；（2）无关；（3）笼统；（4）属性；（5）操作
3.确定关联：
1.初步确定关联：需求陈述中使用的描述性动词或动词词组，通常表示关联关系。
(1)直接提取动词短语得出关联
(2)需求陈述中隐含的关联
(3)根据问题域知识得出的关联
2.筛选：
(1)已删去的类之间的关联
(2)与问题无关的或应在实现阶段考虑的关联
(3)瞬时事件
(4)三元关联：将三元关联改造成二元关联。
(5)派生关联
3.进一步完善：正名、分解、补充、标明重数。
划分主题
在概念上把系统包含的内容分解成若干个范畴
1.应该按问题领域而不是用功能分解的方法来确定主题
2.不同主题内的对象相互间依赖和交互最少的原则
3.主题层、类与对象层、结构层、属性层、操作层
确定属性 属性是对象的性质或特征
1.分析：应该首相找出最重要的属性，在逐渐把其余属性添加进去。
2.选择：
1）误把对象当属性；2）误把关联类的属性当作一般对象的属性；3）把限定误当成属性；4）误把内部状态当成属性；5）过于细化；6）存在不一致的属性
识别继承关系
两种建立继承(即泛化)关系的方式：
(1) 自底向上： 抽象出现有类的共同性质泛化出父类，这个过程实质上模拟了人类归纳思维过程。
(2) 自顶向下： 把现有类细化成更具体的子类或从已知类派生出一个新类，这模拟了人类的演绎思维过程：从一般到特殊。
反复修改
1.一次建模过程很难得到完全正确的对象模型。
2.有些细化工作(例如，定义服务)是在建立了动态模型和功能模型之后才进行的。