信息系统分析与设计-第六章-面向对象的系统分析与设计课件

课堂讨论通过对结构化方法的学习，谈谈你的体会。结构化方法的基本原理；结构化方法的工作阶段；结构化方法工作的重点和难点；结构化方法的局限和不足。面向对象方法的基本原理

面向对象方法是分析问题和解决问题的新方法，其基本出发点就是尽可能按照人类认识世界的方法和思维方式来分析和解决问题。客观世界是由许多具体的事物或事件，抽象的概念和规则等组成的，因此，我们将任何感兴趣或要加以研究的事、物、概念都称为对象。面向对象的方法正是以对象作为最基本的元素，这也是分析问题，解决问题的核心。面向对象中的几个概念*对象（Object）：可以看作其自身所具有的状态特征及可以对这些状态施加的操作结合在一起所构成的独立实体。类：(Class)：类是具有相同属性和服务的一组对象的集合。消息（Message）：消息是面向对象发出的服务请求。封装（Encapsulation）：把对象的属性和服务结合成一个独立的系统单位，尽可能隐蔽对象的内部细节。继承（Inheritance）：即“自动地拥有”，特殊类可以自动地拥有其一般类定义的所有属性与服务。多态（Polymorphism）：描述同一个消息可以根据发送消息对象的不同，采用多种不同的行为方式。问题背景：

需要强调的是，面向对象不仅是一种程序设计方法，更重要的是，它是一种对真实世界的抽象思维方式。随着计算机应用的飞速发展，软件的复杂程度不断提高，源代码的规模越来越大，项目失败的可能性也相应增加。在长期的研究与实践中，人们愈来愈深刻地认识到，建立简明准确的（）是把握复杂系统的关键。表示模型模型可以使人们从全局上把握系统的全貌及其相关部件之间的联系，可以防止人们过早地陷入各个模块的细节。因此，面向对象的分析和设计应该从（）开始。建模BoochOMTOOSEUML面对众多的建模语言，用户没有能力区别不同语言之间的差别，因此很难找到一种比较适合其应用特点的语言。另外，在众多的建模语言中，实际上各有千秋，需要取长补短，日臻完善。第三，虽然不同的建模语言大多相同，但仍存在某些细微的差别。极大地妨碍了用户之间的交流。因此，在客观上，极有必要在精心比较不同建模语言的优缺点及总结面向对象技术应用实践的基础上，努力统一这些建模语言。例：使用Booch方法和OMT方法描述的系统用例图。面向对象的系统分析与设计一、UML简介二、基于UML的面向对象的系统分析1、定义基本用例－－需求分析2、建立概念模型－－概念类分析3、建立系统行为－－顺序图4、定义系统操作契约三、基于UML的面向对象的系统设计一、统一建模语言UML（Unifiedmodelinglanguage）定义：UML代表统一建模语言，是使用面向对象概念进行系统建模的一组表示法，它已成为面向对象领域标准的建模图形。*1、什么是UML？2、与面向对象方法之间有何关系？设计者为UML设定的目标：（1）运用面向对象概念来构造系统模型；（2）建立起从概念模型直到可执行体之间明显对应关系；（3）为复杂的系统建立衡量标准，同时应着眼于那些有重大影响的问题；（4）创建一种对人和机器都适用的建模语言。关于UML的几个要点：*1、UML是一种建模语言，而不是一种方法。2、UML统一了面向对象建模的基本概念、术语及其图形符号。3、UML能够有力地支持从需求分析开始的软件开发的全过程。4、UML是标准的语言，而不是标准的开发过程。5、UML采用的是一种图形表示法，是一种可视化的图形建模语言。6、UML包含静态建模机制和动态建模机制两大类。RUP（RationalUnifiedProcess）

RUP也称统一软件开发过程，统一软件过程。RUP是一个面向对象且基于网络的程序开发方法论。根据Rational公司的说法，好像一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针，模版以及事例支持。RUP把开发中面向过程的方面（例如定义的阶段，技术和实践）和其他开发的组件（例如文档，模型，手册以及代码等等）整合在一个统一的框架内。

规划分析设计实施运行传统的流水线过程瀑布模型高级分析细节分析设计开发测试部署重复性的开发方法开发过程中的各个阶段：*1．初始阶段2．细化阶段3．构造阶段4．交付阶段

UML的主要内容：（5类，共9种模型）*一、用例图。它从用户角度描述系统的功能，并指出各功能的执行者。二、静态图。包括类图、对象图。类图用于定义系统中的类，描述类之间的联系以及类的内部结构。在系统的整个生命周期都有效。对象图显示类的实例，其只能在系统某一时间段存在。三、行为图。描述系统的动态模型和组成对象间的交互关系。一种是状态图，它描述一类对象的所有可能的状态以及事件发生时的状态的转移条件，通常状态图是对类图的补充。另一种是活动图，它描述为满足用例要求所要进行的活动以及活动间的约束关系。使用活动图可以很方便地表示并行活动。例例例四、交互图，描述对象间的交互关系。一种是顺序图，用以显示对象之间的动态合作关系。它强调对象之间消息发送的顺序，同时也显示对象之间的交互过程。另一种是协作图，它着重描述对象间的协作关系。如果强调时间和顺序，使用顺序图。如果强调通信关系，使用合作图。五、实现图，包括构件图和配置图。构件图描述代码部件的物理结构以及各部件之间的依赖关系。配置图定义系统中软硬件的物理体系结构。例面向对象分析阶段的基本过程：*

1、基于用例模型从外部用户的角度捕获系统的行为，即系统应该响应的主要事件

2、使用类图定义系统领域主要概念之间的关系，形成系统的概念模型，它表达了系统对应的事物部分

3、采用顺序图对系统操作行为进行描述，系统行为描述了系统做什么，而不解释系统怎么做

4、基于概念模型、系统顺序图和系统操作建立系统操作的契约。二、基于UML的面向对象分析1、定义基本用例－－需求分析需求包括三个不同的层次：业务需求、用户需求和功能需求。*业务需求反映了组织机构或客户对系统高层次的目标要求，它们在系统的视图与范围文档中予以说明；用户需求描述了用户使用系统必须要完成的任务，它使用用例（usecase）及其用例场景予以说明；功能需求定义了开发人员必须实现的软件功能。业务需求视图与范围文档用户需求质量属性其他非功能需求约束条件功能需求用例文档需求规格说明需求分类

用包图来描述信息系统的业务需求结构。每一个需求用一个需求包来表示，包与包之间用组成关系关联起来，包可以逐层分解，构成分层信息系统需求结构。

※用户需求分析－－用例图*用例图：描述系统外部角色（执行者）与系统提供的用例之间的某种联系。用例的作用？－－面向对象的所有工作是用例驱动的。用例（UseCase）：是指对系统提供的功能的一种描述。用例按详细程度可以分为：高层用例和扩展用例。

高层用例以简洁的方式来描述一个过程，可快速获得对系统整体过程的理解。而扩展用例也叫用例场景，对一个过程的描述要比高层用例详细得多，在格式上具有典型的事件发生过程。

此外，用例按重要程度分为主要用例、次要用例和可选用例三种。主要用例：代表了那些主要的过程；次要用例：代表那些不重要的或者是不常见的用例；可选用例：代表那些可以处理也可以不处理的用例。用例注册选课角色学生（发起者）类型主要的描述学生从所开设的课程列表中选择课程，并生成课程表例：“注册选课”的高层用例用例图：显示了

、

和

的图形。各个部分的关系：（1）关联关系（2）包含（Include）关系（3）扩展（Extend）关系（4）泛化关系<<include>><<extend>>角色：是系统之外的人员或外部系统用例：是系统需要完成的各项功能＊掌握其图形表示及使用对象角色用例用例之间的关系用例中各种关系的说明：*1、关联关系是指两者之间有信息交流。只能用于角色和用例之间的“通信”。2、包含关系也叫使用关系，只能用于两个用例之间。一般是指一个用例使用了另一个用例的行为或功能，它允许将不同用例中的共同行为抽取出来放到另一个独立的用例当中。（例）3、扩展关系是指一个用例与另一个用例相似，但比另外一个所做的动作多一些，或者将常规的动作放在基本用例中，将非常规动作放在它的扩展中。扩展关系只能用于两个用例之间。4、泛化关系指抽象与具体的关系。既可以用在角色之间也可以用在用例之间。说明：“注册选课”用例使用了“登录”用例，它表示在执行“注册选课”流程过程中，同时执行了“注册选课”和“登录”两个用例。银行系统用例图扩展关系泛化关系练习：1：在很多业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那添加、编辑以及修改都要在用例详述中描述，过于复杂；如果分成添加用例、编辑用例和删除用例，则划分太细。这时（）关系可以用来理清关系。包含2：系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印，查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用（）关系来描述。扩展包含用例事件流的执行过程基用例事件流被包含的用例事件流说明：基用例中所包含中事件流肯定被执行，被包含的用例事件被看作是基用例的一部分。两者是包含的关系。基用例事件流扩展用例的执行过程A序列行为扩展点B扩展的用例事件流B序列行为扩展点A说明：1、系统将可选的新增功能放入扩展用例中，不影响基用例的执行。两者具有较高的独立性。2、扩展用例是对基用例增加的额外行为。3、扩展点过多，使基用例行为难以理解。高层用例图直观地描述了信息系统功能。但不能反映各功能的详细内容，以及用户在使用这个功能时与信息系统交互的内容和交互过程。而这些内容又是理解功能的必要材料，所以需要对每一个用例进行说明。用例描述是对用例图中的用例做出的说明。在用例说明中，需要描述用例的编号、名称、角色和用例的功能以及交互过程。想一想：以上绘制的用例图的作用是什么？是否还存在一定的缺陷。黑盒方法和白盒方法*对用例图绘制持有的两种观点：一种是认为仅需从“外部”视图描述系统即可，另外一种认为仅仅有外部描述还远远不够，用例中还必须包括一些重要的系统行为。仅从外部视图描述用例，采用的是黑盒方法（blackbox）。在用例描述中包括对支持达到外部角色的目标所需要的系统行为，采用的是白盒方法（whitebox）。通过黑盒方法绘制了高层用例后，还需采用白盒法在用例场景中采用文字书写该用例的实现过程。而对于复杂的用例，由于处理流程复杂，可以采用活动图来描述用例场景的内容。*带有备选流程的用例活动图起始动作状态决策结束转移活动1活动2活动3.1活动3.2活动4.1活动4.2活动5.1学籍管理系统查询成绩用例描述样例用例名查询成绩角色学生(发起者)描述描述学生查询成绩的过程.查询成功返回成绩列表;失败返回错误信息角色操作系统响应基本操作过程步骤1.学生提交查询成绩的请求,输入要查询的课程号步骤5.查询成绩完毕步骤2.确认学号与课程号的对应关系步骤3.对每门课程,确认成绩是否有效步骤4.打印有成绩的课程、学分和相应成绩可选操作流程步骤2.课程号与学号不匹配,输出错误信息”该生未选此课!”步骤3.课程成绩未出或被覆盖,输出信息”无成绩!”前置条件只有在校学生才能查询成绩后置条件学生获得成绩单假设不输入课程号,则认为是查询全部成绩黑盒视图白盒视图用例的开发过程（1）依据系统事件列出系统功能，定义系统边界，识别出角色和用例。例：以商店作为系统和以商店中的POS作为系统，角色是否一致？（2）用高层用例写出所有用例，将它们分成主要的、次要的和可选的三类。（3）绘制用例图。（4）使用例之间相互关联并在用例图中显示出来。（5）对于最关键、影响最大和最具开发风险的那些用例写出其主要的用例场景，以便能够更好地理解和估计出问题的性质和规模。（6）使用包含、扩展关系精化用例，并划分用例的层次。三、建立概念模型

概念模型用于对系统中的各个部分进行建模。在UML中，不使用“概念”这一术语，而使用“类”这个术语。类是具有相同的属性、操作、方法、关系和语义的一组对象的描述。

用例模型捕获系统的行为，而类、对象模型描述系统的静态结构。作为对用例模型的补充，由关联、聚集、泛化等概念组成的静态模型表示了系统需求的另一个方面。这两者是组成完整分析模型不可缺少的一部分。概念类的表示概念类的类型：*

UML把概念类分为实体类、边界类和控制类三种类型。1)实体类实体类(EntityClass)是信息系统表示客观实体的抽象要素。实体类一般对应着在业务领域中的客观事物，或者是具有较稳定信息内容的系统元素。实体类来源于业务分析中所确定的实体。

2)边界类边界类(BoundaryClass)是描述系统与角色之间交互的抽象要素。边界类只是对信息系统与角色之间交互的抽象建模，并不表示交互的具体内容及交互界面的具体形式。

3)控制类控制类(ControlClass)是表示信息系统对其它对象实施协调处理、逻辑运算的抽象要素。例：售书售货员通过售书界面，进行售书的控制，即：管理架存图书和售出图书。在UML中,类的可视化表示为一个划分成三个格子的长方形(下面两个格子可省略)。最顶部的格子包含类的名字。中间的格子包含类的属性,用以描述该类对象的共同特点。最下面一行表示类的操作(Operation)。*

类之间的联系：（1）关联(Association)。关联表示两个类之间存在某种语义上的联系。图形表示：用一根连接类的实线表示，用箭头表示关联的方向；如果不明确指明方向，则默认关联是双向的管理关联多重性的表示方法：*A和一个B关联A和一个或多个B关联A和零个或一个B关联A和零个、一个或多个B关联AB1AB1..*AB0..1AB*关联多重性：关联的一端可连接任意个数的对象实例。分析两者之间的关联，并进行描述多边形点3..＊（2）聚集（aggregation)

定义：类之间的一种整体与部分的关系。体现了一种层次结构，整体类位于部分类的上层，多个部分类处于并列的层次。图形表示：尾端带一个菱形的单箭头直线，菱形指向整体部分。当部分是整体不可分割的一部分时，称为组成（composition）关联。组成关系拥有其被关联的部分，两者之间可能拥有“终身关系”，即，它们被同时建立和清除。聚集和组成都具有传递性。银行账户雇员0..＊1..＊（3）泛化（generalization)定义：泛化关系是继承机制中产生的类与类之间的关系“isapartof”关系：一个事物是另一个事物的种类。图形表示：一条带有空心大箭头的有向实线，箭头指向父类。例：分析下面各类之间的关系。用类图表示出来。1、电脑、主板、CPU、内存之间的关系。2、动物、老虎、狗之间的关系。类图和对象图的区别：类图

：类具有3个分栏：名称、属性和操作；在类的名称分栏中只有类名；类的属性分栏定义了所有属性的特征；类中列出了操作；类使用关联连接，关联使用名称、角色、多重性以及约束等特征定义；类代表的是对对象的分类所以必须说明可以参与关联的对象的数目。对象图：对象只有两个分栏：名称和属性

对象的名称形式为“对象名：类名”，匿名对象的名称形式为“：类名”

；

对象则只定义了属性的当前值，以便用于测试用例或例子中；对象图中不包括操作，因为对于同属于同一个类的对象而言，其操作是相同的；

对象使用链连接、链拥有名称、角色，但是没有多重性。对象代表的是单独的实体，所有的链都是一对一的，因此不涉及到多重性。类名属性服务类名类的完整和简化表示符号对象名：类名属性对象名：类名对象的完整和简化表示符号想一想，在我们通过黑盒方法绘制了高层用例后，还需采用白盒法在用例场景中采用文字书写该用例的实现过程。而对于复杂的用例，由于处理流程复杂，可以采用（）来描述用例场景的内容。活动图活动图被设计用于简化描述一个过程或操作的工作步骤。活动图既可以描述普通的顺序活动，也可以描述在不同条件下的分支选择活动，具体可以使用一个菱形的判断标志来实现。另外，活动图对表示并发行为也很有用。在活动图中,使用一个称为同步条的水平粗线可以将一条转移分为多个并发执行的分支,或将多个转移合为一条转移。此时,只有输入的转移全部有效,同步条才会触发转移,进而执行后面的活动。状态图(StateDiagram)用来描述一个特定对象的所有可能状态及其引起状态转移的事件。大多数面向对象技术都用状态图表示单个对象在其生命周期中的行为。一个状态图包括一系列的状态以及状态之间的转移。状态所有对象都具有状态,状态是对象执行了一系列活动的结果。当某个事件发生后,对象的状态将发生变化。状态图中定义的状态有:初态、终态、中间状态、复合状态。其中,初态是状态图的起始点,而终态则是状态图的终点。一个状态图只能有一个初态,而终态则可以有多个。状态名转移条件初态终态简化状态状态转移状态图模型元素的表示符号三、定义系统行为顺序图：顺序图是交互图的一种，用以显示对象之间的动态合作关系。它强调对象之间消息发送的顺序，同时也显示对象之间的交互过程。可以通过交互图来定义系统行为。它主要是用来描述对象之间的动态合作关系以及合作过程的行为次序。它常常用来显示用例中所涉及的对象和这些对象之间的消息传递情况。交互图有两种形式，即顺序图和合作图。它们分别从不同的侧面来描述对象间的交互关系。

顺序图有两个轴：水平轴表示不同的对象，垂直轴表示时间。在顺序图中，对象用一个带有垂直虚线的矩形框表示，在矩形框内标有对象名和类名。垂直虚线称为对象的生命线，它代表在对象之间的交互作用中该对象的生命周期。两根对象的生命线之间的箭头表示消息。消息的箭头形状指明消息的类型是发送还是返回。消息按发生的时间顺序从上到下排列。每个消息旁注明消息名称。返回自身生命线的消息箭头叫回授，表示对象发送消息给自己。一个申请贷款的顺序图选择座位递交服务请求完成贷款服务顺序图

和合作图之间的联系与区别＊顺序图和合作图适合描述单个用例中几个对象的行为。顺序图：强调事情发生的顺序；能明显地显示消息的顺序；更适于观察整个工作流，更适于实时、复杂的系统。合作图：强调对象的布局；显示交互关系；更适于协作模式

UML中用于描述系统动态行为的四个图(状态图、顺序图、合作图和活动图)均可用于系统的动态建模,但它们各自的侧重点不同,分别用于不同的目的。首先,不要对系统中的每个类都画状态图。尽管这样做很完美,但太浪费精力,其实你可能只关心某些类的行为。正确的做法是:为帮助理解类而画它的状态图。状态图描述跨越多个用例的单个对象的行为,而不适合描述多个对象间的行为合作。为此,常将状态图与其它技术(如顺序图、合作图和活动图)组合使用。

顺序图和合作图适合描述单个用例中几个对象的行为。其中顺序图突出对象间交互的顺序,而合作图的布局方法能更清楚地表示出对象之间静态的连接关系。当行为较为简单时,顺序图和合作图是最好的选择。但当行为比变复杂时,这两个图将失去其清晰度。因