第6章-面向对象分析PPT学习课件.ppt

《第6章-面向对象分析PPT学习课件.ppt》由会员分享，可在线阅读，更多相关《第6章-面向对象分析PPT学习课件.ppt（59页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第6章 面向对象分析面向对象分析概述建立用例模型建立对象模型建立动态模型12024/7/86.1 面向对象分析概述确定系统边界22024/7/86.1 面向对象分析概述确定系统边界32024/7/86.1 面向对象分析概述面向对象分析的3个模型用例模型：用例和场景表示的功能模型；对象模型：用类和对象表示的静态模型；交互模型：由状态图和顺序图表示的动态模型。42024/7/86.2 建立用例模型建立用例模型的过程(1)确定业务参与者标识目标系统将支持的不同类型的用户，可以是人、事件或其他系统。(2)确定业务需求用例参与者需要系统提供的完整功能。(3)创建用例图标识参与者与用例之间、用例与用例之间

2、的关系。52024/7/8例例:选课系统。选课系统。给教师分配课程和学生注册课程。给教师分配课程和学生注册课程。n 在每个学期选课开始之前，在每个学期选课开始之前，系统管理员系统管理员需要对系统中的教需要对系统中的教师信息、课程信息和学生信息进行维护。学期结束后，将本师信息、课程信息和学生信息进行维护。学期结束后，将本学期成绩归档到学期成绩归档到学籍档案系统学籍档案系统。n 学生学生登录系统后会得到一份本学期将要开设的课程目录。登录系统后会得到一份本学期将要开设的课程目录。每门课程包含的信息有开课系别、教师、上课时间、教室、每门课程包含的信息有开课系别、教师、上课时间、教室、容纳的学生数量和学

3、生选择课程的先决条件。容纳的学生数量和学生选择课程的先决条件。n当学生选择了一门课程后，系统需访问学籍档案系统，查当学生选择了一门课程后，系统需访问学籍档案系统，查询是否符合选课的先决条件询是否符合选课的先决条件 。如果不符合，系统给出提示信。如果不符合，系统给出提示信息。息。n每个学期有一段时间让学生可以改变计划，学生可以在这每个学期有一段时间让学生可以改变计划，学生可以在这段时间内访问联机系统以增选课程或退选课程。段时间内访问联机系统以增选课程或退选课程。62024/7/8n教师教师可以访问在线系统，查看将要教授哪些课程和每门课可以访问在线系统，查看将要教授哪些课程和每门课程有哪些学生报名

4、，课程考试结束后可以提交成绩，系统可程有哪些学生报名，课程考试结束后可以提交成绩，系统可以生成带有成绩分布统计结果的成绩单。以生成带有成绩分布统计结果的成绩单。72024/7/81.确定业务参与者确定业务参与者通过关注系统的业务参与者，我们可以将重点放在如何使用系统，而不是如何构造系统上，并且有助于进一步明确系统的范围和边界。当系统比较庞大和复杂时，要搞清楚系统的需求往往比较困难，通过明确参与者，可以针对参与者确定系统需求，有助于保证系统需求的完整性。82024/7/81.确定业务参与者确定业务参与者可通过以下三个方面来识别参与者：人员或组织外部系统设备92024/7/81.确定业务参与者确定

5、业务参与者可通过以下资料来确定系统的参与者：标识系统范围和边界的环境图；现有系统（如果有的话）的文档和用户手册；项目会议和研讨会的记录；现有的需求文档、工作手册等。102024/7/81.确定业务参与者确定业务参与者还可以通过提出以下问题，明确系统的参与者：谁或者什么为系统提供输入？谁或者什么接收系统的输出？需要与其他系统连接的接口吗？是否存在在预定的时间自动触发的事件？谁将维护系统中的信息？112024/7/81.确定业务参与者确定业务参与者从选课系统的需求描述中，可以确定4类参与者：学生（Student）教师（Teacher）系统管理员（Administrator）学籍档案系统（Archi

6、ve System）122024/7/8选课系统的环境图132024/7/82.确定业务需求用例（参与者角度）确定业务需求用例（参与者角度）以下问题可以帮助我们更好地标识系统的用例：每个参与者的特定任务是什么？在交互过程中参与者是怎样使用系统的服务来完成它们的任务以达目标的？是否每个参与者都要从系统中创建、存储、改变、移动或读取信息？是否任何参与者需要通知系统有关突发性的、外部的改变？哪些用例支持或维护系统？哪些事件引起了参与者与系统的交互？142024/7/82.确定业务需求用例（系统功能角度）确定业务需求用例（系统功能角度）我们可以通过其中用例中的线索来发现其他用例，可以通过下面的方法获取

7、：以穷举的方式考虑每一个参与者与系统的交互情况，看看每个参与者要求系统提供什么功能，以及参与者的每一项输入信息将要求系统做出什么反应，进行处理。看看目前的用例是否覆盖了所有的功能需求。一个用例描述个功能，但这个功能不能过大，如果过大则需要对其进行分解。一个用例应该完成一个完整的任务，通常应该在一个相对短的时间内完成。如果一个用例的各部分被分配在不同的时间段，尤其是被不同的参与者执行，最好还是讲各部分抽取出来作为单独的用例对待，这样有利于功能的复用。152024/7/82.确定业务需求用例（参与者角度）确定业务需求用例（参与者角度）利用场景获取用例：如果用例的描述遇到困难，可使用“角色扮演”技术

8、。该技术要求建模人员深入到现场去观察业务人员的工作，深入理解并记录具体的工作流程，形成用来说明完成特定功能的动作序列的场景（scenario）。场景应该仅关注具体的业务活动，要尽量详细。要确定谁是扮演者，具体做了什么事情，做这些事情的目的是什么。在描述场景时，还要指出其前驱和后继场景，并要考虑可能发生的错误以及对错误的处理措施。要考虑可能发生的错误以及对错误的处理措施。通过需求工程师的角色扮演活动，找出各具体 的场景；然后将本质上相同的场景抽象为一个用例，如图6-3所示。162024/7/82.确定业务需求用例确定业务需求用例环境图是分析参与者和发现潜在用例的极好来源，它不仅可以用在结构化分析

9、方法中，也可以用于面向对象的分析方法中。通过环境图，可以确定系统的主要输入输出，通过提交和接收输入输出的各方确定潜在的用例。172024/7/8选课系统的业务列表182024/7/8对用例的完整描述包括用例名称、执行者、前置条件、后置条件、一个主事件流、零到多个备选事件流。主事件流表示正常情况下执行者与系统之间的信息交互及动作序列，备选事件流则表示特殊情况或异常情况下的信息交互及动作序列。用例的规格说明用例的规格说明192024/7/8用例用例“选择课程选择课程”的规格说明的规格说明202024/7/8用例用例“选择课程选择课程”的规格说明的规格说明 212024/7/83.创建用例图创建用例

10、图用例图是若干个参与者和用例，以及它们间的关系构成的图形表示。每个系统通常都有一个总体视图（Global View of Actors and Use Cases），如果总体视图过于复杂，则可以创建多个用例图，每个用例图关注系统的某一方面。通常是围绕参与者创建用例图。222024/7/8创建用例模型添加了参与者与用例之间关系的用例图 232024/7/86.3 建立对象模型在系统分析阶段，对象建模的主要任务是建立问题域的概念模型。这个模型描述了现实世界中的“类与对象”以及它们之间的关系。在UML中，通过建立类图来表示对象模型。242024/7/8对象模型的5个层次Coad&Yourdon提出，

11、复杂问题(大型系统)的对象模型应该由下述5个层次组成：主题层(也称为范畴层)、类-对象层、结构层、属性层和服务层，如图所示。252024/7/8划分主题在开发大型、复杂系统的过程中，为了降低复杂程度，人们习惯于把系统再进一步划分成几个不同的主题。应该按问题领域而不是用功能分解方法来确定主题。此外，应该按照使不同主题内的对象相互间依赖和交互最少的原则来确定主题。主题可以采用UML中的包来展现。262024/7/8确定类与对象1.找出候选的类与对象 类与对象是对问题域中有意义的事物的抽象，它们既可能是可见的物理实体，也可能是抽象的概念。我们可以将客观事物分为以下五类：可感知的物理实体，如教学楼、教

12、室等。人或组织的角色，如教师、计算机系等。应该记忆的事件，如演出、交通事故等。两个或多个对象的相互作用，通常带有交易或接触的性质，如购买、教学等。需要说明的概念，如保险法、政策等。272024/7/8确定类与对象1.找出候选的类与对象另一种更简单的非正式分析方法，是以自然语言书写的需求陈述为依据，把陈述中的名词作为类与对象的候选者，用形容词作为确定属性的线索，把动词作为服务(操作)的候选者。例如，在选课系统中，可以初步确定Teacher（教师）、Student（学生）、Course（课程）、CourseTask（课程任务，指一门课程划分为多个任务）、StudentList（学生名册）、Scor

13、eReport（成绩单）等类与对象。282024/7/8确定类与对象2.筛选出正确的类与对象 严格考察每个候选对象，从中去掉不正确的或不必要的类与对象，仅保留确实应该记录其信息或需要其提供服务的那些类与对象。292024/7/8确定类与对象3.区分实体类、边界类和控制类在类分析时首先从问题域的实体类入手，如果在建立分析对象模型时区分实体类、边界类和控制类，将有助于理解系统。实体类表示系统将跟踪的持久信息；边界类表示参与者与系统之间的交互；控制类负责用例的实现。其图形表示如图所示。302024/7/8确定关联标识关联的标准如下：(1)识别各类对象之间的静态联系；(2)识别关联属性与操作；(3)分

14、析关联的多重性；(4)进一步分析关联的性质；312024/7/8确定属性应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。在分析过程中应该首先找出最重要的属性，以后再逐渐把其余属性增添进去。在分析阶段不要考虑那些纯粹用于实现的属性。322024/7/8确定属性标识属性的准则如下：(1)每个对象至少需包含一个属性，例如_id。(2)属性取值必需适合对象类的所有实例。(3)出现在泛化关系中的对象所继承的属性必须与泛化关系一致。(4)系统的所有存储数据必须定义为属性；(5)对象的导出属性应当略去。例如，“年龄”是由属性“出生日期”导出，它不能作为基本属性存在。(6)在分析

15、阶段，如果某属性描述了对象的外部不可见状态，应将该属性从分析模型中删去。332024/7/8确定属性选课系统中类与对象的属性 342024/7/8确定服务在标识每个对象中必须封装的服务时要注意以下两种服务：(1)简单的服务。即每一个对象都应具备的服务，这些服务包括：建立和初始化一个新对象，建立或切断对象之间的关联，存取对象的属性值，释放或删除一个对象。这些服务在分析时是隐含的，在图中不标出，但实现类和对象时有定义。(2)复杂的服务。它分为两种：计算服务：利用对象的属性值计算，以实现某种功能；监控服务：处理对外部系统的输入输出，外部设备的控制和数据的存取。352024/7/8确定服务选课系统中类

16、与对象的服务 362024/7/8建立类图 本节以选课系统为例，介绍建立类图的过程。类图的建立和编辑过程与用例图类似，但有自己的特点。在建立类图之前，首先要创建类。1 创建类 在选课系统中，设计的类有学生、教师和课程等。因此，可以创建Student、Techer和Course类。在前面介绍用例图中的关系时涉及构造型的概念，类也有构造型，每个类最少有一种构造型。一些常用的构造型包括实体类、边界类、控制类、例外类等。显然，Student、Tencher和Course类应属于实体类。边界类可能包括RegisterForm（登记表格）、BillingInterface（计费接口）、CourseSche

17、dule(课程表）等。类创建之后，根据前面分析确定的属性和服务，将其增加到类的定义中。372024/7/8建立类图2.将类组织到包中如果系统仅仅包含少数的几个类，我们便可以很容易地管理。通常的系统都包含很多类，你需要一种机制来管理以便更方便使用、维护和复用。这就是包有用的原因。382024/7/8建立类图4.建立和编辑主视图在逻辑视图中的主视图（main）是系统的包图。每个包也有其自己的主要类图，通常显示包的公共类。也可能需要创建其它的类图。主视图是逻辑视图中典型的高级包视图。增加一个包图的过程是：在浏览器中双击主视图；在浏览器中选择包；把包拖到视图中。392024/7/8建立类图4.建立和编

18、辑主视图类的主视图是系统的包图。每个包也有自己的主要类图，通常显示包的公共类。对于选课系统，可以建立如图所示的5个包：界面（GUI）、数据访问包（DBAccess）、基础信息管理（BaisicInfoManagement）包、学生选课（StudentSeleCourse）和考试成绩管理（ExamResultManagement）包。402024/7/8以下是具有五个包的主视图：412024/7/8建立类图 建立和编辑分视图 需要时也可以加入类的分视图，类的分视图展现了模型中包和类的另一种“视图”。在选课系统中增加的分视图 422024/7/8建立类图6.为类添加关系(1)关联关系关联在类之间具

19、有双向语义。类关联关系意味着在对象和关联的对象之间存在连接。432024/7/8建立类图标识关联的数量：两个关联对象在数量上有一定的对应关系。在UML中，对象之间的多还有多重性关联可以直接在关联直线上用一个数字或一个数字范围表示。对象之间可以存在多种多重性关联关系：442024/7/8类之间的关联关系：452024/7/8建立类图(2)聚合关系聚合是关联关系的特殊形式整体和部分的关系。聚合是部分或包含的关系。例如：在一个学期中，很多班级的学生都需要上同一门课程（Course），通常会将此门课程的教学划分为多个教学任务（CourseTask）。Course和CourseTask可以认为是聚合关系

20、。462024/7/8建立类图(2)聚合关系聚合是关联关系的特殊形式整体和部分的关系。聚合是部分或包含的关系。例如：在一个学期中，很多班级的学生都需要上同一门课程（Course），通常会将此门课程的教学划分为多个教学任务（CourseTask）。Course和CourseTask可以认为是聚合关系。472024/7/8建立类图(3)关联类CourseTask和Student之间是多对多的关系，一个很容易想到的问题是学生选课的成绩存在哪里？显然，对于每个CourseTask对象（一份教学任务），选课结束后都有一份学生名单，也就是StudentList对象，是StudentList将CourseT

21、ask对象及Student对象关联在一起的，因此，应将StudentList作为关联类。482024/7/8建立类图(3)关联类CourseTask和Student之间是多对多的关系，一个很容易想到的问题是学生选课的成绩存在哪里？显然，对于每个CourseTask对象（一份教学任务），选课结束后都有一份学生名单，也就是StudentList对象，是StudentList将CourseTask对象及Student对象关联在一起的，因此，应将StudentList作为关联类。492024/7/8建立类图(4)泛化关系 在选课系统中，如在选课系统中，如果考虑到学生、教果考虑到学生、教师或系统管理员登

22、师或系统管理员登录系统时需要进行录系统时需要进行权限控制，可以增权限控制，可以增加加用户用户（UserUser）类。）类。502024/7/86.4 建立动态模型在开发交互式系统时，动态模型起着很重要的作用。在UML中动态模型的描述工具有顺序图、活动图和状态图。512024/7/8顺序图用例图中的事件流是由文本表示的，事件流描述的是用例实现的过程，也称为场景（scenarios），可以用顺序图表示场景。顺序图按照时间顺序显示对象之间的交互关系。它描述场景中的对象和类以及在完成场景中定义的功能时对象间要交换的信息。522024/7/8顺序图如在选课系统中，可以给Register for a co

23、urse用例增加顺序图，如图所示。532024/7/8通信图通信图也称协作图，是顺序图的另一种表示形式，用于描述相互协作的对象间的交互关系和链接关系。一般情况下，当表示涉及很多对象的模型时，协作图比顺序图更形象。另外，与顺序图不同，对象之间的实线可能表明这些对象的类之间需要关联。542024/7/8通信图如在选课系统中，可以给Register for a course用例的通信图，如图所示。552024/7/8状态图状态图由对象的各个状态和连接这些状态的转换组成。通常，用一张状态图描绘一类对象的行为，它确定了由事件序列引出的状态序列。不是任何一个类都需要有一张状态图描绘它的行为，只针对具有明显的状态特征并且具有比较复杂的状态事件响应行为的类，才需要画状态图。在选课系统中，CourseTask类的对象具有比较明显的状态特征，其状态有：初始状态、可选状态、人满状态、关闭状态。562024/7/8状态图在选课系统中，可以给CourseTask增加状态图。572024/7/8图书馆的书籍状态如下：582024/7/8Thanks!592024/7/8