第 9 讲 面向对象分析与设计 2004-03-12.

Presentation on theme: "第 9 讲 面向对象分析与设计 2004-03-12."— Presentation transcript:

1 第 9 讲 面向对象分析与设计

2 思考题 软件开发中为什么要使用面向对象方法？ 面向对象分析方法与结构化分析方法有哪些相似之处？有何区别？
面向对象方法是对过去的一个完全突破，还是“换汤不换药”？

3 传统方法学的缺点 存在的问题： 生产率提高的幅度远不能满足需要； 软件重用程度很低； 软件仍然很难维护； 软件往往不能真正满足用户需要。
出现上述问题的原因很多，最根本的是瀑布型开发模型和结构化技术的缺点。

4 传统方法学的缺点 瀑布型模型的缺点：僵化 瀑布模型要求：生命周期各阶段间遵守严格的顺序。 实际情况：软件开发往往在反复实践中完成。
瀑布模型要求：预先定义并“冻结”软件需求。 实际情况：某些系统的需求的一个逐渐明确的过程，且预先定义的需求到软件完成时可能已经过时。

5 传统方法学的缺点 结构化技术的缺点 ： 本质上是功能分解，以实现功能的过程为中心，而用户的需求变化主要是针对功能的。这就使基于过程的设计不易被理解；且功能变化往往引起结构变化较大，稳定性不好。 系统有明确的边界定义，且系统结构依赖于系统边界的定义，这样的系统不易扩充和修改。 结构分析技术对处理的分解过程带有任意性，不同的开发人员开发相同的系统时，可能经过分解而得出不同的软件结构。 数据与操作分开处理，可能造成软构件对具体应用环境的依赖，可重用性(reusability)较差。

6 解决问题的途径 新的软件开发模型，如快速原型方法、螺旋型方法等； 新的软件开发方法学――面向对象方法学。

7 Post_office.Send (request, payment)
面向对象方法学(OOM) 南京 北 京 对象Object = 数据Attribute + 操作Method Message Post-office Send by method 我想把邮局搬到 我家门口，多加几个 邮递员，24小时都开门 …… Attributes: location; employee; …… Object 唉，那就先送束花吧 —— Post_office.Send (request, payment) 对不起， 本邮局不提供 此类服务 Methods: send; sell; …… 注意：Object内部的attributes不允许外部用户直接改动，只有当它提供了相应的服务method时，用户才能通过发送message来提请它执行。

8 面向对象方法学OOM 特点：尽可能模拟人类习惯的思维方式，即问题域与求解域在结构上尽可能一致。与传统方法相反，OOM以数据或信息为主线，把数据和处理结合构成统一体—对象。这时程序不再是一系列工作在数据上的函数集合，而是相互协作又彼此独立的对象的集合。

9 面向对象思想的起源 维特根斯坦是本世纪乃至人类哲学史上最伟大的哲学家之一。 他生前于1922年出版了一本著作——《逻辑哲学论》(Tractatus Logico-Philosophicus)。 在该书中，他阐述了一种世界观，或者说一种认识世界的观点，这种观点，在六七十年后的今天，终于由一种哲学思想沉淀到技术的层面上来，成为计算机业界的宠儿，这就是“OO”，Object-Oriented，面向对象。

10 面向对象思想的起源 维特根斯坦在《逻辑哲学论》 一书中提出了如下思想：
＊世界可以分解为事实 ( The world divides into facts.) ＊事实是由原子事实(atomic facts)组成的。 ＊一个原子事实是多个对象(objects)的组合。 ＊对象是简单的(基本的) The Object is simple。 ＊对象形成了世界的基础。

11 面向对象方法的历史 雏形阶段 面向对象的概念最早是在1966年的仿真语言Simula67中出现的，这个语言是由挪威奥斯陆大学和挪威计算中心共同研制的，在这个语言中体现了面向对象方法的基本要点。 Alan Kay加入Xerox的Palo Alto研究中心（PARC）后，吸收了Simula67中的类、对象、继承等概念，与同事共同设计了Smalltalk语言。1972年PARC发布了Smalltalk-72，其中正式使用了“面向对象”术语，标志着面向对象程序设计方法的正式形成。

12 面向对象方法的历史 完善阶段 1981年PARC推出了Smalltalk80，被认为式面向对象语言发展史上最重要的里程碑。
作为一项新的软件方法学需要一段时间才能被广泛接收。 Smalltalk的商品化工作到1987年才开始进行。 追求纯OO的宗旨(如严格的封装等)使讲究时效的开发人员感到不便。

13 面向对象方法的历史 繁荣阶段 从80年代中期到90年代，出现了大批实用的OOPL，如C++, Object Pascal, Eiffel, Java等。

14 面向对象方法与技术起源于面向对象的编程语言OOPL。
但是正如《软件工程百科全书》中所言：“编程并不是软件开发问题的主要根源。需求分析与设计问题更为普遍并且更值得解决。因此面向对象开发技术的焦点不应该只对准编程阶段，而应更全面地对准软件工程的其它阶段。面向对象方法真正意义深远的目标是它适合于解决分析与设计期间的复杂性并实现分析与设计的复用。” 基于这一事实，人们对面向对象方法的研究重点，从OOP转移到了OOA和OOD。

15 案例 学生注册系统（student register system, SRS）需求规范
当学生被大学录取后，学生所有SRS建立学习计划，即确定满足特定学位程序所需要的课程，并选择一名辅导教师。SRS要检验所提出的学习计划是否满足该学生所希望获得的学位的要求。

16 案例 cont. 一旦建立了学习计划，则在以后每个学期的注册期间，学生都可以在线查询课程计划，选择要选修的课程，如果课程由多名教授讲授，则还可以指定听课时间（即每星期几，每天什么时间听课）。 SRS要参考学生在线的所完成课程的成绩单（学生也可以随时查看自己的成绩单），检验学生是否满足所申请课程的必要的预修条件。

17 案例 cont. 假设：(a)所要求的预修课程已经满足；(b)课程满足该学生学习计划要求之一；(c) 每个课程如有空位，则学生可以参加听课。
如果学生以前所等待的课程可以提供（或者用于某个学生取消了听课计划，或者由于该课程的听课位置增加了），则该学生会被自动录取到所等待的课程中，并向该学生发送一个电子邮件。该学生如果不再对这个课程感兴趣，可以自行决定取消，否则学生要为该课程付费。 学生最迟可以在学期的第一个星期末决定退出所选的课程。

18 面向对象的基本概念 对象是现实世界中个体或事物的抽象表示，是面向对象开发模式的基本成份。
对象是指将属性（数据/状态）和操作（方法/行为）捆绑为一体的软件结构，代表现实世界对象的一个抽象。 属性表示对象的性质，属性值规定了对象所有可能的状态。一般只能通过执行对象的操作来改变。 操作描述了对象执行的功能，若通过消息传递，还可以为其它对象使用。

19 类：物以类聚 类（class）是一组具有相同属性和相同操作的对象的集合。
类的定义包括该类的对象所需要的数据结构（属性的类型和名称）和对象在数据上所执行的操作（方法）。 类定义可以视为一个具有类似特性与共同行为的对象的模板，可用来产生对象。

20 实例 实例(instance)是从某类创建的对象，它们都可使用类中提供的函数。 对象的状态则包含在实例的属性中。
实例化 (instantiation)是指在类定义的基础上构造对象的过程。 同一个类的不同对象的差别是通过不同对象的不同属性值的差别来体现的。

21 Dr. Brown: Professor Blow: Student UML对象图 UML类图

22 void send (req_type request, money_type payment);
例: class Post_office { private : loc_type location ; emp_type employee ; …… public : void send (req_type request, money_type payment); void sell (int goods, money_type payment) ; } ; main ( ) { Post_office My_PO ; req_type My_request ; money_type My_payment ; …… My_PO.Send ( My_request, My_payment) ; }

23 封装 封装encapsulation是指将对象的状态信息（属性）和行为（方法）捆绑为一个逻辑单元，并尽可能隐藏对象的内部细节。
封装是面向对象的一个重要原则，它有两个涵义：第一个是把对象的全部属性和全部操作结合在一起，形成一个不可分割的独立对象。第二个是“信息隐藏”，即尽可能隐藏对象的内部细节，对外形成一个边界，只保留有限的对外接口使之与外部发生联系。 封装可以提高事物的独立性，而且还可以有效地避免“交叉感染”和减少“波动效应”。

24 继承 ：相似性与多样性 继承(inheritance)：类可分层，下层子类与上层父类有相同特征，称为继承。
继承是使用已存在的定义做为基础建立新定义的技术。 新类的定义可以是既存类所声明的数据和新类所增加的声明的组合。新类复用既存的定义，而不要求修改继承类。 既存类可当做基类来引用，则新类相应地可当做派生类来引用。

25

26 使用继承设计一个新类，可以视为描述一个新的对象集，它是既存类所描述对象集的子集合。
这个新的子集合可以认为是既存类的一个特殊化。Quadrilateral类是Polygon类的特殊化。Quadrilateral是限制为四条边的多边形。我们还可以进一步地把类Quadrilateral特殊化为Rectangle 。

27 类Quadrilateral的操作可以等同于类Polygon的操作，而Rectangle类的操作又与Quadrilateral类的操作相同。
新类的操作还可以被看做是既存类操作的一个扩充操作。例如，从一个既存的车辆类派生的四轮驱动车类可能不仅是车辆类子集合定义的特殊化，而且还可能在新类的操作中引入新的能力。

28 类的继承层次

29 在类的继承层次中，Quadrilateral的实际参数可以替换Polygon的形式参数。

30

31 继承的好处 继承使得导出类变得非常简洁明了，导出类中只包含那些使它们与父类不同的最本质的特性。
通过继承，可以重复使用和扩展那些经过测试的没有修改过的代码。 最好的方法是从现存的类中导出新的子类。 分级分类是人类组织和利用信息的技能。按照这种方法组织规划软件，使得结构简单，易于维护和扩展。

32 一旦建立了类的层次结构，并且编写了一个应用程序的代码，改变非叶节点的类将对整个层次结构产生“波动影响”。
所以，一旦一个应用程序的非叶节点类的代码编写完成后，就尽量避免向其中增加新的特征。

33 导出类的规则 通过添加特性来扩展基本类 研究从父类继承的操作
子类执行父类的操作的特殊化处理是通过一种称为替换（overriding）的方法实现的。

34

35

36 导出类的规则 cont. 不能改变特征的语义（目的和含义） 不能替代属性 不能删除特性

37 多重继承 在一个类层次结构种任何给定的类都允许由两个或多个类作为直接父类 ，称为多重继承 。

38 消息 ：合作之道 消息(message)：对象间只能通过发送消息进行联系，外界不能处理对象的内部数据，只能通过消息请求它进行处理（如果它提供相应消息的话）。

39 发送给一个对象的消息定义了一个方法名和一个参数表（可能是空的），并指定某一个对象。
消息是一个对象与另一个对象的通信单元，是要求某个对象执行类中定义的某个操作的规格说明。消息包括提供服务的对象标识、服务标识、输入信息、返回信息。 发送给一个对象的消息定义了一个方法名和一个参数表（可能是空的），并指定某一个对象。 一个对象接收的消息则调用消息中指定的方法，并将形式参数与参数表中相应的值结合起来。 Message: = object_ID. method_ID (parameter(s))；

40 void send (req_type request, money_type payment);
例: class Post_office { private : loc_type location ; emp_type employee ; …… public : void send (req_type request, money_type payment); void sell (int goods, money_type payment) ; } ; main ( ) { Post_office My_PO ; req_type My_request ; money_type My_payment ; …… My_PO.Send ( My_request, My_payment) ; }

41 多态性 polymorphism 多态性是指在一般类中定义的属性或操作被特殊类继承之后，可以具有不同的数据类型或表现出不同的行为，使得同一个属性或操作在一般类及其各个特殊类中具有不同的语义。

42 重载overload－在子类中对继承来的属性或操作进行重新定义；
与多态性的实现有关的语言功能有： 重载overload－在子类中对继承来的属性或操作进行重新定义； 动态绑定dynamic binding－在运行时根据对象接收的消息动态地确定要链接哪一段操作代码； 类属generic－操作参数的类型可以是参数化的。

43 重载 Student类可以合理地定义不同的print()方法标识: boolean print();
void print (String fileName); void print (int detailLevel); void print (int detailLevel, String fileName); void print (String reportTitle, int maxPage);

44 关联 association 关联：类之间存在的结构关系。 教授指导学生 学生选修课程 学位计划包括多门课程

45 反身关联 反身关联 (reflexive association):在相同类的两个实例之间发生关系。
一个课程是很多课程的预修课程，而且一个课程可以有很多的预修课程。

46 多元关联 一个学生可以选修一门课程、一个教授讲授一门课程、一个教授指导一个学生。

47 多值性 多值性multiplicity是指某个类有多少对象可以和另一个类的单个对象关联。 1:1 - 类A的一个实例仅对应着类B的一个实例
1:N - 对于类A的一个实例，有很多类B的实例通过某种关系与其关联。 N:N - 对于类A的一个实例，可能有很多类B的实例与之关联，反之亦然。

48 链接 link 链接是对象之间存在的一种结构关系。 一个对象是该类加入属性值之后的实例，同样，一个链接是一个实例加入成员对象之后的一个关联。
关联是某些类的对象之间的一种潜在关系，链接是那些类的对象之间的一种实际关系。

49 链接 advises Blow: Student Lee: Student Smith: Student
Dr. Brown: Professor

50 聚合 聚合aggregation是关联的一种特殊形式，常被认为“包含”、“由…组成”关系，即部分类与由它们组成的类之间是一种整体－部分(part-whole)关联。 聚合表示两个类之间的一种关系。

51 聚合

52 面向对象的基本概念 对象 （属性与方法） 类与实例 封装 （信息隐藏） 继承（多重继承） 消息 多态性（重载、动态绑定） 关联与链接 聚合

53 面向对象方法学 OOM = Object +Class +Inheritance +Communication with messages

54 对象把数据和处理数据的方法封状成一个单元
数据实体 输入 过程2 过程1 过程3 输出 传统方法数据与过程是分离的 属于该对象 的数据 对象 处理数据的方法 消息 对象把数据和处理数据的方法封状成一个单元

55 传统方法和面向对象方法的比较 传统方法 面向对象方法 系统是过程的集合 系统是交互对象的集合 过程与数据实体交互 对象与人或其它对象交互
过程接受输入并产生输出 面向对象方法 系统是交互对象的集合 对象与人或其它对象交互 对象发送与响应消息 面向功能 ,把系统看成一组功能 把问题当作一组相互作用的实体，并确定实体间关系

56 OOM的优点 ① 传统方法：面向过程设计，以计算为核心，数据与操作分离，不易理解。
OOM：以object 为核心，强调对现实概念的模拟而不强调算法。“面向对象方法学的基本原则，是按照人们习惯的思维方式建立问题域的模型，开发出尽可能直观、自然地表现求解方法的软件系统”。  Class：由特殊到一般的归纳(induction)  Inheritance：由一般到特殊的演绎(deduction)

57 ③传统方法：通过建立标准函数库来重用软构件。但标准函数缺少必要的“柔性”，难以适应不同场合的不同需要。
② 传统方法：结构依赖于功能，不稳定。 OOM：以object模拟实体，需求变化不会引起结构的整体变化，因为实体相对稳定，故系统也相应稳定。 ③传统方法：通过建立标准函数库来重用软构件。但标准函数缺少必要的“柔性”，难以适应不同场合的不同需要。 OOM：一个class所有的instances都可重用它的代码；由 inheritance派生出的新的class可重用其父类的代码，并且可以修改、扩充而不影响其父类的使用。

58 ④ 传统方法：可维护性是最令人头痛的问题。 OOM：从以下几方面改善了可维护性 ——
稳定性好：软件功能需求的变化不牵动全局，只需局部修改； Class 独立性强：只要修改不涉及class的对外接口，则内部修改完全不影响外部调用； Inheritance和多态性(polymorphism)使其很容易被修改和扩充； 容易理解； 有这一条就什么都好办了！  容易测试、调试。 这一点还可商榷

59 注：OOM并不是减少了开发时间，而是通过提高可重用性、可维护性，进行扩充和修改的容易程度等，从长远角度改进了软件的质量。OOM与Prototyping结合使用效果好。

60 小结 “面向对象”是一种认识客观世界的世界观，它将客观世界看成是有许多不同种类的对象构成的，每个对象有自己的内部状态和运动规律，不同对象之间的相互联系、相互作用就构成了完整的客观世界。 “面向对象”是从结构组织的角度去模拟客观世界的一种方法，这种方法的基本着眼点是构成客观世界的那些成分----对象。 用“面向对象”的观点去认识客观世界，用“面向对象”的方法去模拟客观世界，这就构成了“面向对象”的完整含义。

61 面向对象软件开发 面向对象技术是一个有全新概念的开发模式,其特点是: 方法是对软件开发过程所有阶段进行综合考虑而得到的；
从生存期的一个阶段到下一个阶段所使用的方法与技术具有高度的连续性； 将OOA、OOD、OOP集成到生存期的相应阶段。

62 面向对象软件开发 面向对象的分析：建立应用领域的面向对象模型，识别出的对象反映了与待解决问题相关的一些实体及操作。
面向对象的设计：建立软件系统的面向对象模型，这个软件系统能实现识别出的需求。在面向对象设计的对象与要解决问题的答案是关联的。虽然两者存在密切的关系，但设计者有时不得不通过增加新的对象和转换问题对象的方法来实现答案。 面向对象的程序设计：使用面向对象的成语设计语言来实现软件设计。面向对象的程序语言支持对象的直接实现和提供设施来定义对象。

63 面向对象分析 OOA 面向对象分析方法确实不同于结构化分析方法吗？
Fichman and Kemerer 在“Object-oriented Conventional Analysis and Design Methodologies” 中阐述： 我们的结论是面向对象分析方法表现了相对面向过程的方法学（如结构化分析）的根本性变化，而且相对面向数据的方法学仅仅是增量性的变化。面向过程的方法学在建模过程中的关注点不是对象的内在性质，从而导致了和面向对象的三个基本原理相正交的问题域模型。

64 OOA OOA方法使得软件工程师能够定义待解决问题的类和对象，类之间的相互关联的方式，对象的内部结构（属性和操作），以及允许对象在一起工作的通信机制（消息）来对问题域进行建模。 OOA的目标是开发一些列的模型，这些模型描述软件系统，以满足用户需求。与结构化分析方法的目标是一致的。

65 OOA 建立分析模型5个基本原则： （1）建模信息域； （2）描述模块功能； （3）表示模型行为； （4）分解数据、功能和行为模型
以表示更多细节； （5）早期模型表示问题的本质， 而后期模型提供 实现细节。

66 OOA OOA的意图是提供系统的精确、简明、易理解的面向对象模型，也就是“蓝图”自动化。为了达到这个目标，必须完成以下任务：
1. 必须在客户和软件工程师之间沟通， 了解基本的用户需求； 2. 必须标识类(定义属性和方法)； 3. 必须刻划类的层次结构； 4. 表示对象与对象关系（关联）； 5. 必须建模对象行为； 6. 任务1到5迭代反复使用，直至完成建模。

67 OOA建模方法 建模方法＝过程＋标记＋工具 标记：用于交流模型的一种图形“语言”。 工具：使标记工作自动化，
过程：说明如何收集需求并确定要建模的提炼。 标记：用于交流模型的一种图形“语言”。 工具：使标记工作自动化， 一般使用“Drag and Draw”方式。 过程是最重要的，然后是标记，工具是三者中重要性最低的。

68 流行的几种建模方法 Booch方法 Coad-Yourdon方法
James Rumbaugh方法 (Object Modeling Technology, OMT) Jacobson方法（简称OOSE） ESA的HOOD方法 Wirfs-Brook的RDD方法 由Rumbaugh, Booch, Jacobson 提出的统一建模语言(Unify Modeling Language, UML)

69 Booch方法 Booch方法包含微开发过程和宏开发过程。微级别定义一组分析任务在宏过程中的每个步骤中被反复应用。其宏过程包括：
标识类和对象 标识类和对象的语义 标识类和对象间的关系 进行精化

70 Jacobson方法 Jacobson方法提出面向对象的软件工程OOSE，强调use case，描述用户和产品或系统之间如何交互的场景scenario.

71 Coad/Yourdon方法 Coad/Yourdon的OOA过程概述： 使用“寻找什么”标准来标识对象 定义一般/特殊结构
定义整体/部分结构 标识主题（子系统构件的表示） 定义属性 定义服务

72 Rumbaugh方法 (OMT) Rumbaugh的OOA过程概述： 开发对问题的范围陈述 建造对象模型 开发动态模型 构造系统的功能模型

73 统一的OOA方法 Rumbaugh, Booch, Jacobson提出的统一建模语言(Unify Modeling Language, UML)。 UML是一种定义良好，易于表达，功能强大且普遍实用的建模语言。

74 OOA建模 不同面向对象分析方法的相似步骤： （1）获取系统的用户需求； （2）标识场景scenario或用例use－case；
（3）使用基本需求作为指南，选择类和对象； （4）为对象定义属性和操作； （5）定义类的结构和层次； （6）建造对象-关系模型； （7）建造对象-行为模型； （8）根据use－case来评审OOA模型。

75 OOA模型的组成结构 对象-关系模型 类/对象 模型 对象-行为模型 使用实例 Use Case 操作 属性 协作者

76 UML 统一建模语言 “The Unified Modeling Language is a language for specifying, constructing, visualizing, and documenting artifacts of a software-intensive system” － The UML Summary Originally: unification of notations for OOA/OOD Goal was to eliminate the notation wars and allow tool interchange It is process independent, but can be adapted to support particular processes It became an OMG standard at the end of 1997 It was developed by a team of companies lead by Rational Software Corporation

77 UML的应用 UML的目标是以面向对象的方式来描述任何类型的系统，具有很广的应用领域。其中最常用的是建立软件系统的模型，但它同样可以用于描述非软件领域的系统。 UML是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模。 UML适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。 UML是一种建模语言，不是一种方法，它独立于过程。利用它建模时，可遵循任何类型的建模过程。

78 UML的主要内容 UML融合了Booch、OMT和OOSE方法中的基本概念，而且这些基本概念与其他面向对象技术中的基本概念大多相同；

79 软件开发过程 Rational公司1998年发布了名为Rational Unified Process－RUP的面向对象软件开发过程框架。
该框架将软件开发过程分为四各阶段： 初始阶段 细化阶段 构造阶段 移交阶段 该过程框架强调的原则： 用例驱动 (Use Case Driven) 以架构为中心 (Architecture-Centric) 迭代增量 (Iterative and Incremental)

80 UML的定义 UML的语义 UML表示法 描述基于UML的精确元模型定义。

81 模型内容的组织和UML表述 UML的用于描述模型的基本词汇(“构造块”)： 关系 (Relationships) 图 (Diagrams)
事物 (Things) 关系 (Relationships) 图 (Diagrams)

82 模型内容的组织和UML表述 事物 (Things) 结构事物(Structure) 行为事物(Behavioral)
UML中的静态元素：交互(Interaction) 状态机(State Machine) 组织事物(Grouping) UML的分组元素：包(Package) 注释事物(Annotation) UML的分组元素：注释(Note)

83 模型内容的组织和UML表述 关系 (Relationships) 图 (Diagrams) 关联关系 (Association)
依赖关系 (Dependency) 泛化关系 (Generalization) 聚合关系 (Aggregation) 实现关系 (Realization) 图 (Diagrams) 9种图

84 UML的9个模型 序号 模型名称 模型定义和解释 1 业务模型 建立业务流程的抽象 2 领域模型 建立系统的语境(业务操作规则) 3
用例模型 建立系统的功能需求 4 分析模型 建立概念设计（逻辑设计） 5 设计模型 建立问题的解决方案 6 过程模型 建立系统的并发和同步机制 7 部署模型 建立系统的硬件拓扑网络结构 8 实现模型 建立的软硬件配置设计 9 测试模型 建立系统的测试计划设计

85 UML的9种图 类图 对象图 用例图 顺序图 协作图 状态图 活动图 构件图 配置图 包图: 包中的类以及包与包之间的关系(静态图) 图名称
图定义 图性质 1 类图 一组类、接口、协作及它们的关系 静态图 2 对象图 一组对象及它们的关系 3 用例图 一组用例、参与者及它们的关系 4 顺序图 一个交互，强调消息的时间顺序 动态图 5 协作图 一个交互，强调消息发送和接受的对象的结构组织 6 状态图 一个状态机，强调对象按事件排序的行为 7 活动图 一个状态机，强调从活动到活动的流动 8 构件图 一组构件及关系 9 配置图 一组接点及它们的关系 包图: 包中的类以及包与包之间的关系(静态图)

86 UML的5种视图 在UML 中，系统的表示使用5种不同的“视图” （ UML定义的五类图，共 9 种图形），它们从可以从软件开发的不同阶段、不同视角 和不同层次对所开发的系统进行描述。每个视图由一组图定义。 用户模型视图：使用use-case建模 结构模型视图：对静态结构（类、对象和关系）建模 行为模型视图：使用表示系统的动态或行为 实现模型视图：表示系统的结构和行为 环境模型视图：表示系统将实现的环境的结构和行为

87 UML的5种视图 1 2 3 4 5 视图名称 视图内容 静态表现 动态表现 观察角度 用户模型视图 （用例视图） 系统行为，动力 用例图
交互图、状态图、活动图 用户、 分析员、 测试员 2 结构模型视图 （设计视图） 问题及解决方案 类图、 对象图 类、 接口、 协作 3 行为模型视图 （进程视图） 性能、可伸缩性，吞吐量 线程、 进程 4 实现模型视图 （实现视图） 构件、文件 构件图 配置、 发布 5 环境模型视图 （实施视图） 部件的发布、交付、安装 配置图 (实施图) 拓扑结构 的节点

88 标准建模语言UML的主要内容可以归纳为两大类： 静态建模机制 动态建模机制

89 UML 发展历史

90 The Current Version of UML
Like all modern computer languages, UML is constantly changing At the moment, UML 2.0 is in the final stages of acceptance UML is under the control of the Object Management Group (OMG) Check for updates at the OMG Web site,

91 用例图 use-case diagram 从本质上讲，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用。
用例描述了用户提出的一些可见的需求； 用例可大可小； 用例对应一个具体的用户目标。

92 用例图 use-case diagram 用例图描述系统外部的执行者与系统的用例之间的某种联系。
所谓用例是指对系统提供的功能（或称系统的用途）的一种描述； 执行者是那些可能使用这些用例的人或外部系统； 用例和执行者之间的联系描述了“谁使用哪个用例”。

93 用例图 use-case diagram 用例图着重于从系统外部执行者的角度来描述系统需要提供哪些功能，并且指明了这些功能的执行者是谁；
用例图在UML方法中占有十分重要的地位，人们甚至称UML是一种用例图驱动的开发方法。

94 用例图 use-case diagram 用例图中的图符： 执行者 关联 actor 用例 系统
Student 用例 执行者 actor 系统 关联 系统：用于界定系统功能范围，描述该系统功能的用例都置于其中，而描述外部实体的执行者都置于其外。 关联：连接执行者和用例，表示执行者所代表的系统外部实体与该用例所描述的系统需求有关。

95 用例图 use-case diagram 用例图中的图符： 注释体 注释链接
<<extend>> 注释体 注释链接 使用：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能。 扩展：由用例A连向用例B，表示用例B描述了一项基本需求，而用例A则描述了该基本需求的特殊情况。 注释体：对UML实体进行文字描述。 注释连接：将注释体与要描述的实体连接，说明该注释体是针对该实体所进行的描述。

96 用例图 use-case diagram 用例模型表示法 执行者 用例 系统 通信 关系

97 用例图 use-case diagram 设置边界 贸易经理 更新帐目 记帐系统 风险分析 交易估计 进行交易 超越边界 评价 营销人员
销售人员 <<use>> <<extend>>

98 用例图 use-case diagram 用例模型的获取： 获取执行者 actor 获取用例 use-case

99 用例图 use-case diagram 获取执行者： 谁使用系统的主要功能（主要使用者）？ 谁需要系统支持他们的日常工作？
谁来维护、管理系统使其能正常工作（辅助使用者）？ 系统需要控制哪些硬件？ 系统需要与其他哪些系统交互？ 对系统产生的结果感兴趣的是哪些人？

100 用例图 use-case diagram 获取用例： 执行者要求系统提供哪些功能？
执行者需要读、产生、删除、修改或存储系统中的信息有哪些类型？ 必须提醒执行者的系统事件有哪些？ 执行者必须提醒系统事件有哪些？怎样把这些事件表示成用例中的功能？

101 类图 Class Diagram 在面向对象的建模技术中，类、对象和它们之间的关系是最基本的建模元素。
对于一个系统，其类模型、对象模型以及它们之间的关系揭示了系统的结构。 类图描述了系统中的类及其相互之间的各种关系，其本质反映了系统中包含的各种对象的类型以及对象间的各种静态关系（关联，子类型）。

102 类图 Class Diagram 类图中的图符： 类：表示一个类，其中第一栏是类的名，第二栏是类的属性，第三栏是类的操作。
Operations Attributes Class 类 Package 包 关联 association 类：表示一个类，其中第一栏是类的名，第二栏是类的属性，第三栏是类的操作。 包：包是一种分组机制，表示一个类图集合。 关联：用于表示类的对象之间的关系。其特殊形式有组成关联和聚集关联。

103 类图 Class Diagram 类图中的图符： 聚集 aggregation：用于表示类的对象之间的关系是整体与部分的关系。
组成 泛化 聚集 aggregation：用于表示类的对象之间的关系是整体与部分的关系。 组成 composition：用于表示类的对象之间的关系：整体拥有各部分，部分与整体共存，如整体不存在了，部分也会随之消失。 泛化 generalization：泛化关系也称继承关系inheritance，定义了类和包间的一般元素和特殊元素之间的分类关系。

104 类图 Class Diagram 类图中的图符：
依赖关系 Values Object 对象 链接 依赖关系 dependency：有两个类或包元素X、Y，修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖于元素X。 对象 object：类的一个实例。 链接 link：用于表示对象间的关联关系的一个实例。

105 类图 Class Diagram 2004-03-12 订单项 Quantity:Integer price:Money
isSatisfied:Boolean 1 * 项 产品 订单 DateReceived isPrepaid number:String prce:Money Dispatch() close() 客户 Name address CreditRating():String 团体客户 ContactName creditRating creditLimit Remind() billforMonth(Intrger) 个人客户 CreditCard# {creditRating() =“poor”} 雇员 销售代表 0..1

106 对象图 Object Diagram 对象图是类图的一种变形。除了在对象名下面要加下划线以外，对象图中所使用的符号与类图基本相同。
对象图是类图的一种实例化。一张对象图表示的是与其对应的类图的一个具体实例，即系统在某一时期或者某一特定时刻可能存在的具体对象实例以及它们相互之间的具体关系。

107 对象图 Object Diagram 类图 对象图 Uses 2004-03-12 计算机 名字：String 内存：Ineger 作者
年龄：Integer 0..1 Uses 1..* 类图 对象图 小王：作者 名字 = “王小影” 年龄 = 32 小王的工作PC： 计算机 名字 = “Compaq X” 内存 = 32 名字 = “Dell486” 内存 = 64

108 Links structural relationships between objects
may be physical or conceptual Grady Booch works-for IBM Microsoft has-HQ-located-at Redmond Mathematically defined as a tuple (i.e. ordered list of objects) represented by a line joining the linked objects

109 对象图 Object Diagram 对象图并不象类图那样具有重要的地位，但是利用它可以帮助我们通过具体的实例分析，更具体直观地了解复杂系统类图的丰富内涵。 对象图还常常被用作协作图的一部分，用以展示一组对象实例之间的动态协作关系。

110 包图 Package Diagram 包是类的集合。 包图所显示的是类的包以及这些包之间的依赖关系。
如果两个包中的任意两个类之间存在依赖关系，则这两个包之间存在依赖关系。 包的依赖是不传递的。

111 包图 Package Diagram 订单获取 界面 应用 AWT 邮件发送 清单界面 订单 顾客 清单应用

112 包图 Package Diagram MFC类 用户接口 出错处理 教学管理 数据库 教学管理系统的包图

113 教学管理包 教学管理 学生登记 选课统计 选课管理 课程 课程登记 开设课程 人事信息 学生 教师 成绩管理 学生成绩登记 成绩统计
身份验证

114 包图 Package Diagram 何时使用包图：
依赖产生耦合，应该尽量将依赖性减少到最低程度； 包的概念对测试也是特别有用的。

115 状态图 State Diagram 状态图是对类的一种补充描述，它展示了此类对象所具有的可能的状态以及某些事件发生时其状态的转移情况。
在状态图中，状态由圆角矩形表示。状态的改变称作转移，状态转移由箭头表示，箭头旁可以标出转移发生的条件。状态转移可以伴随有某个动作，它表明当转移发生时系统要做什么。

116 状态图 State Diagram 上升 到达第一层 到达 下降 超时 2004-03-12 下降状态 在第一层 上升状态 向第一层下降
空闲状态 上升 到达 超时 下降 到达第一层

117 顺序图 sequence diagram 顺序图描述了对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。
顺序图由一组对象构成，每个对象分别带有一条竖线，称作对象的生命线，它代表时间轴，时间沿竖线向下延伸。顺序图描述了这些对象随着时间的推移相互之间交换消息的过程。消息用从一条垂直的对象生命线指向另一个对象的生命线的水平箭头表示。图中还可以根据需要增加有关时间的说明和其他注释。

118 顺序图 sequence diagram 2004-03-12 ：计算机 ：打印服务程序 ：打印队列 ：打印机 打印文件
打印文件[打印机空闲] 保存文件[打印机忙]

119 Sequence diagram A sequence diagram displays object interactions arranged in a time sequence

120 协作图 Collaboration 与顺序图作用相同，协作图也是用来描述系统中对象之间的动态协作关系。协作图侧重于描述各个对象之间存在的消息收发关系（交互关系），而不专门突出这些消息发送的时间顺序。 在协作图中，对象同样是用一个对象图符来表示，箭头表示消息发送的方向，而消息执行的顺序则由消息的编号来表明。

121 协作图 Collaboration ：打印机 ：计算机 ：打印队列 ：打印服务程序 2004-03-12 1. 打印文件
3. 保存文件[打印机忙] 2：打印文件[打印机空闲]

122 协作图 Collaboration 协作图的布局方法能更清楚地表示出对象之间静态的连接关系。
顺序图突出执行的时序，能更方便地看出事情发生的次序。 如果要描述在一个用例中的几个对象协同工作的行为，交互图是一种有力的工具。 如果想要描述跨越多个用例的单个对象的行为，应当使用状态图；如果想要描述跨越多个用例或多个线程的多个对象的复杂行为，则需考虑使用活动图。

123 活动图 activity diagram 活动图描述系统中各种活动的执行顺序，通常用于描述一个操作中所要进行的各项活动的执行流程。同时，它也常被用来描述一个用例的处理流程，或者某种交互流程。 活动图由一些活动组成，图中同时包括了对这些活动的说明。当一个活动执行完毕之后，控制将沿着控制转移箭头转向下一个活动。活动图中还可以方便地描述控制转移的条件以及并行执行等要求。

124 活动图 activity diagram 2004-03-12 找饮料 [没有咖啡] [没有可口可乐] 人 [找到可口可乐] [找到咖啡]
将咖啡放到 过滤器中 加水到容器中 取出咖啡杯 取一听 可口可乐 把过滤器放 到咖啡炉上 点燃咖啡炉 冲调咖啡 熄灭咖啡炉 倒咖啡 喝饮料

125 活动图 activity diagram 活动图最适合支持描述并行行为，这使之成为支持工作流建模的最好工具。
活动图最大的缺点是很难清楚地描述动作与对象之间的关系。

126 活动图 activity diagram 对于以下情况可以使用活动图： （1）分析用例； （2）理解牵涉多个用例的工作流；
（3）处理多线程应用。 在下列情况下，一般不要使用活动图： （1）显示对象间合作； （2）显示对象在其生命周期内的运转情况。

127 构件图 Component 构件图描述软件构件以及它们之间的依赖关系，从而便于人们分析和发现当修改某个构件时可能对那些构件产生影响，以便对它们做相应的修改或更新。 构件可以是源代码构件、二进制目标码构件、可执行构件或文档构件。

128 构件图 Component Diagram 教学管理.exe 财务系统.exe 成绩管理.dll 课程管理.dll 人事管理.dll 课程
教师 学生 开设课程 选课注册

129 构件图 Component 2004-03-12 Whnd.cpp： 窗口处理器 Whnd.obj： Comhnd.cpp： 命令处理器
Comhnd.obj： Main.obj： 主类 Main.cpp： client.exe： 客户程序 Graphic.dll： 图形库

130 配置图 Deployment Diagram
配置图描述系统中硬件和软件的物理配置情况和系统体系结构。 在配置图中，用结点表示实际的物理设备，如计算机和各种外部设备等，并根据它们之间的连接关系，将相应的结点连接起来，并说明其连接方式。在结点里面，说明分配给该结点上运行的可执行构件或对象，从而说明哪些软件单元被分配在哪些结点上运行。

131 ATM系统配置图： ATM应用 服务器 ATM客户机 Internet 银行储户 局域网 ATM数据 服务器

132 配置图 Deployment Diagram
个人电脑PC 客户B： 数据库服务器： VAX 服务器：02 «TCP/IP协议» «TCP/IP»协议 «DecNet协议»

133 UML支撑环境 Rational Rose 基于UML的模型驱动的软件开发环境 全面支持团队整体合作的开发形式 集成了最新软件开发技术和思想

134 UML框架下的软件工程 我们已经有了统一的建模语言UML 我们已经拥有统一软件过程RUP 下一步是什么？
A Software Component Marketplace Quality from the Beginning Give Soul to Software Process A Complete UML Based Software Platform Ivar Jacobson

135 UML用于软件开发 UML是一种建模语言，常用于建立软件系统的模型，适应于系统开发的不同阶段。 用户需求 系统分析 系统设计 系统实现 测试

136 UML用于软件系统开发的不同阶段 用户需求：可使用用例图来捕获用户的需求，用例图从用户的角度来描述系统的功能，表示了操作者于系统的一个交互过程。 系统分析：可使用类图来描述系统的静态模型。为了实现用例，类之间需要协作，可用动态模型的状态图、顺序图、协作图来描述。分析阶段只考虑问题域的对象建模。需要通过静态模型和动态模型来描述系统结构和系统行为。 系统设计：对类进行细化，如引入人机交互的接口类、处理数据类、处理通信类。

137 UML用于软件系统开发的不同阶段 系统实现：用构件图描述代码构件的物理结构以及构件之间的关系。用配置图来描述和定义系统中软硬件的物理通信结构。 测试：可使用类图进行单元测试；可使用构件图、协作图进行集成测试；可使用用例图进行确认测试。

138 完整需求定义要用五种图 用例图 类图 状态图 顺序图 协作图

139 OOA建模的步骤 不同面向对象分析方法的相似步骤： （1）获取系统的用户需求； （2）标识场景scenario和用例use－case；
（3）使用基本需求作为指南，选择类和对象； （4）为对象定义属性和操作； （5）定义类的结构和层次； （6）建造对象关系模型； （7）建造对象行为模型； （8）根据use－case来评审OOA模型。

140 基于用例的需求分析 当软件的使用者考察一个软件产品的功能时，其考虑的内容通常包括：
软件的功能的设置的合理性 软件的运行效率 软件功能使用的方便程度 这些内容是软件产品的外部特性，是软件系统通过其边界呈现给用户的特性。 外部特性通常是动态的。通过外部特性，软件系统的使用价值得到了体现。

141 基于用例的需求分析 呈现在软件系统的边界上的外部特征，是由软件系统的内部实现决定的。
但是，对于软件系统的使用者而言，软件功能的内部实现不是他们关心的问题，他们所关心的只是其所需要的功能是否以令其满意的方式得到了实现。

142 基于用例的需求分析 分析软件系统的功能设置时，应该把重点放在描述软件系统的外部边界上，即重点考虑用户对软件系统的功能设置的合理性、方便性和运行效率的要求，而不应该在需求分析阶段就过多地考虑软件系统的结构和内部实现机制。这是在对软件系统进行需求分析时，应该遵循的一个重要原则。

143 基于用例的需求分析 软件系统不是孤立存在的，它的使用价值是通过和它所存在的环境发生交互实现的，因此在描述软件系统的边界、分析软件系统应具备的功能时，应首先分析软件产品与外界环境的联系，发现外界环境中哪些对象将和软件系统产生交互。不但需要分析共有哪些用户将要使用软件系统，而且还需要分析软件系统的运行结果将要对哪些对象产生影响。

144 基于用例的需求分析 当提取出了软件系统运行的外部环境中与之交互的对象之后，需要为这些对象与软件系统进行的交互指定具体内容。这包括：
对交互中包含的动态行为进行详细描述 还包括对这些动态行为进行合理的分类和组织 这使得这些动态行为所代表的软件系统的功能能为用户提供其所需的价值，并具备令用户满意的易用性和效率。 媒介：交互图、状态图

145 基于用例的需求分析 为了确定系统的功能，必须回答下面的问题： 谁要使用待开发的系统？ 为了向用户提供价值，系统需要提供什么服务？
当用户为了特定具体目的与系统交互，用户期待的效果是什么？

146 基于用例的需求分析 对软件产品的需求分析就是定义软件系统的边界，包括两个方面的内容： 分析软件产品与外界的联系
确定软件产品与外界的联系时包含动态行为及其相互关系。 在UML中，下列建模元素为上述两方面提供支持： 执行者(actor) 用例(use case) 它们存在于用例视图中，所在模型图： 用例图(use case diagram)

147 用例图 use-case diagram 从本质上讲，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用。
用例描述了用户提出的一些可见的需求； 用例可大可小； 用例对应一个具体的用户目标。

148 用例图 use-case diagram 用例图描述系统外部的执行者与系统的用例之间的某种联系。
所谓用例是指对系统提供的功能（或称系统的用途）的一种描述； 执行者是那些可能使用这些用例的人或外部系统； 用例和执行者之间的联系描述了“谁使用哪个用例”。

149 用例图 use-case diagram 用例图着重于从系统外部执行者的角度来描述系统需要提供哪些功能，并且指明了这些功能的执行者是谁；
用例图在UML方法中占有十分重要的地位，人们甚至称UML是一种用例图驱动的开发方法。

150 用例图 use-case diagram 用例图中的图符： 执行者 关联 actor 用例 系统
Student 用例 执行者 actor 系统 关联 系统：用于界定系统功能范围，描述该系统功能的用例都置于其中，而描述外部实体的执行者都置于其外。 关联：连接执行者和用例，表示执行者所代表的系统外部实体与该用例所描述的系统需求有关。

151 用例图 use-case diagram 用例图中的图符： 注释体 注释链接
<<extend>> 注释体 注释链接 使用：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能。 扩展：由用例A连向用例B，表示用例B描述了一项基本需求，而用例A则描述了该基本需求的特殊情况。 注释体：对UML实体进行文字描述。 注释连接：将注释体与要描述的实体连接，说明该注释体是针对该实体所进行的描述。

152 用例图 use-case diagram 用例模型表示法 执行者 用例 系统 通信 关系

153 用例图 use-case diagram 设置边界 贸易经理 更新帐目 记帐系统 风险分析 交易估计 进行交易 超越边界 评价 营销人员
销售人员 <<use>> <<extend>>

154 用例图 use-case diagram 用例模型的获取： 获取执行者 actor 获取用例 use-case

155 执行者 用例 执行者：在系统建成后与系统进行交互的一类对象，包括用户（人）、其它计算机系统等。在UML中用执行者驱动建模。 系统 通信 关系

156 执行者 “交互”定义为使用软件系统获得某种结果的方式。包括：向系统提供或分发信息；接收或使用来自系统的信息。
“提供”信息：就是执行者是否输入加到由系统存储的剩余数据中的真实信息； “使用”信息：就是执行者是否使用系统获得信息。

157 执行者 软件系统的使用者 软件系统的使用者要通过使用软件和系统交互 使用者处于系统之外
随着软件系统的应用领域的不同，在用例视图模型中代表执行的数目也有可能不同 对于那些通用的软件产品，如：文字处理软件、网络通讯软件、图形绘制软件，它们的使用者通常是不需要分类的，只需要一个系统作用者就可以代表其所有的用户 对于那些专业化较强的专用软件系统，如，管理信息系统、工业生产流程控制系统等，它们的使用者随其在软件的应用领域的职责的不同，对软件的使用方式也会有所不同，例如，在一个公司的管理信息系统中，公司的管理者对信息系统的存取权限将高于公司的普通员工，有必要对软件系统的使用者进行分类，多个不同的系统作用者将同时出现在用例视图模型中。

158 执行者 执行者除了可以代表软件使用者之外，还可以代表直接和软件系统交互的软件系统赖以运行的软/硬件平台以及与软件系统有信息交换的计算机外部设备。 SRS系统的 系统执行者

159 基于用例的需求分析 获取执行者： 谁使用系统的主要功能（主要使用者）？ 对系统产生的结果感兴趣的是哪些人？ 谁需要系统支持他们的日常工作？
谁来维护、管理系统使其能正常工作（辅助使用者）？ 系统需要控制哪些硬件？ 系统需要与其他哪些系统交互？

160 用例 指定系统执行者后，需要详细描述系统执行者和软件系统交互的具体内容，对交互所代表的软件系统的功能进行分类，对这些功能详细指定其代表的软件系统的动态行为。 在UML中，软件系统的功能和其代表的动态行为是用用例use-case来建模的。

161 用例 用例代表系统为响应系统执行者引发的一个事件而执行的一系列的处理，而且这处理应该为系统执行者产生一种可见的价值。
用例描述了当系统执行者和软件系统进行交互时，软件系统所执行的一系列的动作序列，这些动作序列不但包含正常使用的各种动作序列，而且应包含对非正常使用时软件系统的动作序列的描述。 一个用例代表系统执行者和系统的一次交互，用例视图中用例的设置，就代表了软件系统的功能的划分。

162 用例 为了得到合理而方便的软件系统的功能设置，必须仔细考虑每个用例代表的动态行为的内容，使得每个用例都能产生一个有价值的结果。
通过用例考虑软件系统的功能划分时，应使得功能的分布较为均衡、易于理解、易于使用，这也是用例的定义中所谓“产生可见的价值”的含义。

163 基于用例的需求分析 获取用例： 执行者要求系统提供哪些功能？ 执行者需要读、产生、删除、修改或存储系统中的信息有哪些类型？
必须提醒执行者的系统事件有哪些？ 执行者必须提醒系统事件有哪些？怎样把这些事件表示成用例中的功能？

164 用例 系统执行者总是发起用例，系统自己发起的行为不能启动使用用例。
用例强调系统要做什么，即功能需求，不考虑内部如何完成。事实上，用例可以看作是系统整体的行为。

165 案例 学生注册系统（student register system, SRS）需求规范
当学生被大学录取后，学生所有SRS建立学习计划，即确定满足特定学位程序所需要的课程，并选择一名导师。SRS要检验所提出的学习计划是否满足该学生所希望获得的学位要求。

166 案例 cont. 一旦建立了学习计划，则在以后每个学期的注册期间，学生都可以在线查询课程计划，选择要选修的课程，如果课程由多名教授讲授，则还可以指定听课时间（即每星期几，每天什么时间听课）。 SRS要参考学生在线的所完成课程的成绩单（学生也可以随时查看自己的成绩单），检验学生是否满足所申请课程的必要的预修条件。

167 案例 cont. 假设：(a)所要求的预修课程已经满足；(b)课程满足该学生学习计划要求之一；(c) 每个课程如有空位，则学生可以参加听课。
如果学生以前所等待的课程可以提供（或者用于某个学生取消了听课计划，或者由于该课程的听课位置增加了），则该学生会被自动录取到所等待的课程中，并向该学生发送一个电子邮件。该学生如果不再对这个课程感兴趣，可以自行决定取消，否则学生要为该课程付费。 学生最迟可以在学期的第一个星期末决定退出所选的课程。

168 用例 例子：以SRS的执行者student为例，描述学生以什么方式使用系统。 SRS的一些用例，包括： 注册一门课程 删除一门课程
确定某个学生所选的课程 确定教师 建立学习计划 查看课程授课时间 查询给定学生的成绩单 维护课程信息 公布课程的学期最后成绩

169

170 用例 可以将任何用例进行分解，每个步骤代表一个过程。如“注册一门课程”可以分解为： 检查学生是否满足课程的预修课程要求
检查学生的学习计划，以保证确实需要选修这门课程 检查这门课程是否还有空位

171

172 用例与执行者匹配 执行者与用例之间的关系可能是多对多的关系，即同一个执行者可以启动多个不同的用例，同一个用例可以与多个不同的执行者交互。
通过两者交叉引用，保证： 在系统中没有根本不使用系统的执行者， 也不存在没有执行者的用例。 对于每对用例与执行者组合，确定系统执行者是否使用或提供信息是很有用的。

173 用例与执行者匹配 启动执行＝〉 用例： 学生 教师 注册员 工作人员 注册课程 √ × 选择教师 授课时间 确定学生选修课程 公布课程成绩
查询学生成绩 确定是否毕业 维护课程信息

174

175 场景 Scenario 用例代表系统和系统执行者之间发生的一系列的事件，这些事件流构成了用户对系统功能的一次使用。
一个用例可以有多个事件流，每一个事件流是一个完整的用户对系统的功能的使用。 它们出于同一个目的，由于事件流不同，使得系统产生的效果不同。 事件流是用例的实例（instance）。 用例的实例在UML中被称为场景（Scenario）。

176 OOA建模的步骤 不同面向对象分析方法的相似步骤： （1）获取系统的用户需求； （2）标识场景scenario和用例use－case；
（3）使用基本需求作为指南，选择类和对象； （4）为对象定义属性和操作； （5）定义类的结构和层次； （6）建造对象关系模型； （7）建造对象行为模型； （8）根据use－case来评审OOA模型。

177 静态和动态模型只不过是同一个问题的两个方面，两者结合起来构成面向对象系统的蓝图。
面向对象模型包括：静态模型和动态模型 需要创建和实例化什么类，以表示适当的提炼。就是选择类、定义类的属性和操作、类之间的结构关系。 需要这些对象如何协作，以执行系统的全部需求，也就是“使命”。详细说明对象之间的过程叫动态建模。 静态和动态模型只不过是同一个问题的两个方面，两者结合起来构成面向对象系统的蓝图。

178 系统静态和数据特性建模 问题： 如何标识适当的类及其属性 如何确定在这些类之间存在的层次关系和关联关系 如何通过使用UML标记表示这些信息

179 标识适当的类 使用“搜索收集”方法，在项目的所有文档中搜索并收集所有名词和名词短语，即所有候选对象(candidates)，构成一个清单，然后使用去粗取精的过程消减清单，形成一组适当的类。 候选对象可能是物理实体、人或组织、要处理的事件、对象间的活动、抽象概念等等。 根据规则筛选出正确的类和对象。 由筛选出的类产生数据字典。

180 标识适当的类 对于SRS系统的需求描述进行名词和名词短语分析，得到下表：
自动学生注册系统，系统，大学，课程，等待的课程，所需要的课程，预修课程，以前等待注册的课程，班级，以前等待注册的班级，星期几，上课时间，学位，学位要求， 消息，导师，先到先服务队列，得到成绩，成绩单，已完成的课程，学习计划，学期，学生，教授，教室，听课允许的人数。

181 标识适当的类 筛选的标准： 删除与系统无关的名词 删除笼统意思表达的名词 消除冗余 尽可能选择较短的等效表达方式。
尽管不是同义词，但表达的意义接近，应该选其一。 在选择类名时，应避免选择暗示对象间角色的名词。 属性：既可以作为一个类，又可以作为其它类的属性的名词，要考虑其在系统中的作用。 实现：将注意力集中到“领域类”，以免引入“实现类”。

182 标识适当的类 以“教室”名词，既可以定义Room类，也可以作为Section类的属性。 class Section {
// attributes Course offeringOf; String semester; char dayOfWeek; String timeOfDay; String classroomLocation; //etc. } Class Room{ // attributes int roomNo; String building; int seatingCapacity; // etc. } 选择哪个，取决于教室是否是应用系统的焦点。

183 标识适当的类 对于SRS系统的需求描述进行名词和名词短语分析，得到下表：
自动学生注册系统，系统，大学，课程，等待的课程，所需要的课程，预修课程，以前等待注册的课程，班级，以前等待注册的班级，星期几，上课时间，学位，学位要求，电子邮件消息，先到先服务队列，得到成绩，成绩单，已完成的课程，学习计划，学期，学生，导师，教授，教室，听课允许的人数。

184 标识适当的类 经过上述标准的筛选，得到类的清单： 课程 班级 先到先服务队列 学习计划 学生 教授 成绩单

185 标识适当的类 重新考虑用例中的执行者，检查是否有执行者应该添加到类的清单中。
确定方法是：如果与执行者A关联的用户需要在A登录到系统时，访问/修改有关执行者B的信息，则B需要在模型中作为一个类。 执行者： 学生 教授 注册人员 管理人员 收费系统

186 标识适当的类 经过重新考虑所有执行者角色后，候选类清单为： 课程 班级 先到先服务队列 学习计划 学生 教授 成绩单

187 产生数据字典 对于每个候选类，数据字典都应该包括一个在模型和系统背景下的有关这个类含义的简单定义，必要时可以提供一个例子。
目前为止完整的SRS数据字典。 数据字典可以结合其它SRS说明文档集合，构成模型的后续信息。随着模型不断进化，可扩展数据字典，以包括属性、关联及方法定义。

188 SRS数据字典 课程：一个学期的一系列授课、作业、考试等，都与特定专题领域有关，一般与一定的学分学时关联，它是获得学位的一个单位。如：“软件工程”是计算机科学与技术专业学士学位的必修课程。 班级：在特定学期每星期特定日期的特定时间提供的特定课程。如：课程“软件工程”在2004年春季学期每星期一3－4节和每星期三5－6节授课。 学习计划：学生为得到特定学位所要完成的必修课程清单。 学生：当前已经被大学录取，并且有资格注册课程的人员。

189 SRS数据字典 cont. 教授：一些为班级授课或指导学生的教职员工。
成绩单：特定学生到目前为止在大学所修所有课程的记录，包括在哪个学期完成的每门课程、课程成绩以及该课程得到的学分，还有所得到的总学分和学生的平均成绩GPA。

190 确定类之间的关联 (1)在初步确定关联时，大多数关联可以通过直接提取动词或动词短语而获得。同时在分析需求陈述中还可以发现隐含的关联关系。
(2)筛选： 删除已删去的类之间的关联； 删除与问题无关或应在实现密切相关的关联； 删除瞬时事件； (3)完善: 正名、分解、补充、标明多值。

191 确定类之间的关联 通过分析需求陈述，对下面动词短语仔细考虑： 学生注册课程； 跟踪学生的学习进展； 学生被大学录取； 建立学生学习计划；
学生选择导师； 学生能够在线查询课程计划；

192 确定类之间的关联 另一种确定关联的补充手段是创建n×n的矩阵。N表示已经找出的候选类个数。
如果行与列的类之间没有关联关系，则在单元中标记一个×。 关联一般是双向的，但在需求陈述中有些反关系不是可行的，那么在单元中标记一个√。 若两个类存在关联，则在单元中标记关联关系。

193 确定类之间的关联 × √ 班级 课程 学习计划 教授 学生 成绩单 实例化 被讲授 包含 预修 被要求 要求 被遵守 讲授 指导
注册，在队列中等待，以前选修过 计划选修 执行 被指导，在指导下学习 拥有 属于

194 确定类之间的关联 学生选择导师 学生选修班级

195 学习计划由很多课程组成，任何给定的课程可以包含在不同的学习计划中 学生执行自己的学习计划
学生在班级等待队列中 学习计划由很多课程组成，任何给定的课程可以包含在不同的学习计划中 学生执行自己的学习计划

196 确定类之间的关联 教授给多个班级讲授 学生拥有自己的成绩单

197 确定类之间的关联 课程的自反关联 关联作为属性： 课程作为班级提供

198 确定类之间的关联 关联类表示对象间链的属性 二者等价

199 确定类之间的关联 成绩单由多门课程的成绩组成

200 确定类之间的关联

201

202 确定类的属性 1.分析 通常修饰名次的形容词可以表示类的属性。同时还需要借助分析人员的领域知识，才能分析除需要的属性。在分析过程中，首先找出最重要的属性，以后再逐渐添加。 2.选择 从确定的属性中删掉不正确的或不必要的属性。

203 确定类的属性

204 确定类的属性

205 识别类之间的继承关系 对类进行组织。继承关系的建立实质上是知识抽取过程。通常需要由领域专家的参与配合。 一般说来，使用两种方法：
自底向上：范化 自顶向下：特殊化

206 识别类之间的继承关系 继承关系

207

208 更新数据字典 （类） 课程：一个学期的一系列授课、作业、考试等，都与特定专题领域有关，一般与一定的学分学时关联，它是获得学位的一个单位。如：“软件工程”是计算机科学与技术专业学士学位的必修课程。 个人：与大学有关的人员。 学习计划：学生为得到特定学位所要完成的必修课程清单。 学生：当前已经被大学录取，并且有资格注册课程的人员。

209 更新数据字典 （类） 班级：在特定学期每星期特定日期的特定时间提供的特定课程。如：课程“软件工程”在2004年春季学期每星期一3－4节和每星期三5－6节授课。 教授：一些为班级授课或指导学生的教职员工。 成绩单：特定学生到目前为止在大学所修所有课程的记录，包括在哪个学期完成的每门课程、课程成绩以及该课程得到的学分，还有所得到的总学分和学生的平均成绩GPA。 成绩单记录：成绩单中的一个记录行，表示课程编号和名称，提供的学期，学分，学时和得到的成绩。

210 更新数据字典 （关系） Advises: Attends: Call for: Maintains: Observes:
教师指导学生，指导其建立学习计划获得学位。 Attends: 学生选修班级，学生注册班级，参加学习，完成所有作业并参加考试，并获得相应的成绩。 Call for: 学习计划要求课程，学习只选择学习计划要求的课程，经过导师批准，并可以修改学习计划。 Maintains: 学生拥有自己的成绩单，学生每完成一门课程，都要在其成绩单中添加一条相关记录，包括课程和成绩记录。 Observes: 学习要遵守执行学习计划。

211 更新数据字典 （关系） Offered as: Prerequisite: Teaches: Waiting for:
课程以班级形式提供，同一门课程在给定学期中会讲授多次。 Prerequisite: 某一门课程是另一门课程的预修课程。学生只有在成功地完成预修课程，才可以选修相应的课程。 Teaches: 教师讲授具体的课程。 Waiting for: 学生等待班级，如果班级“已满”，如达到教室的最大容量或为保证教学质量所限制的最大人数，则要注册的学生安排在一个等待对列中，如果出现空位，则可以递补。

212 更新数据字典 （属性） person.ssn: 个人的唯一标识号 Person.name: 个人的姓名
Professor.title: 教师的职称 student,.major; 学生的主修专业 Student.degree: 学生正在攻读的学位 TranscriptEntry.grade: 学生获得的成绩 Course.courseNo: 课程编号 Course.courseName: 课程名称 Course.credits: 课程的学分数

213 更新数据字典 （属性） Section.sectionNo; 区分同一学期中提供的班级编号
Section.dayOfWeek: 每周授课的日期 Section.timeOfDay: 授课时间，如：上午3－4节 Section.semester: 提供班级的学期标识 section.room: 班级上课的教学楼和教室编号 Section.seatingCapacity: 注册某个班级所允许的最大学生人数。

214 反复修改 仅仅经过一次建模过程很难得到完全正确的对象模型。事实上，软件开发过程就是一个反复修改、逐步完善的过程。在建模中的任何一个步骤发生错误都必须返回进行修改。由于OOA采用UML语言，整个建模过程是一致的，比采用结构化的方法修改容易些。

215 OOA建模的步骤 不同面向对象分析方法的相似步骤： （1）获取系统的用户需求； （2）标识场景scenario和用例use－case；
（3）使用基本需求作为指南，选择类和对象； （4）为对象定义属性和操作； （5）定义类的结构和层次； （6）建造对象关系模型； （7）建造对象行为模型； （8）根据use－case来评审OOA模型。