信息系统分析与设计 第6章系统分析.ppt

《信息系统分析与设计 第6章系统分析.ppt》由会员分享，可在线阅读，更多相关《信息系统分析与设计 第6章系统分析.ppt（66页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、第6章系统分析第第6章章 系统分析系统分析 6.1 概述概述 6.2 逻辑模型逻辑模型 6.3 逻辑结构分析逻辑结构分析 6.4 用例分析用例分析 6.5 概念类分析概念类分析 第6章系统分析6.1 概概 述述6.1.1 系统分析的含义及特点系统分析的含义及特点系统分析(SystemAnalysis)是信息系统开发的第三项工作。该项工作是在业务分析和需求分析的基础上，从抽象的概念层次上确定信息系统的要素、构成和结构，得出信息系统的分析模型，并为系统设计提供依据。第6章系统分析系统分析工作的特点如下：(1)内在性。系统分析是站在信息系统内部的角度，分析信息系统的要素、构成和结构。需求分析则具有外

2、在性。系统分析从内在角度，考虑信息系统应该具备哪些要素，要素之间的关系，要素的构成方式等问题。(2)概念性。第一，面向业务领域，反映业务概念；第二，在较宏观和抽象的层次进行分析工作，一般不过多涉及具体细节；第三，不涉及信息系统的实现环境。(3)一致性。系统分析所确定逻辑模型应该具有逻辑一致性，它要纠正需求模型中存在的冗余及错误。第6章系统分析6.1.2 系统分析的主要工作系统分析的主要工作1逻辑结构分析信信息息系系统统逻逻辑辑结结构构是从抽象的概念层次和功能需求角度，根据信息系统的需求结构确定的信息系统模型结构。信息系统逻辑结构由分析包按照组成关系或依赖关系构成。逻辑结构分析(LogicStr

3、uctureAnalysis)要经过确定初步逻辑结构、分解并确定分析包、确定分析包关系等步骤。第6章系统分析2用例分析用用例例分分析析(UseCase Analysis)是从概念层次上对分析包中的用例进行的分析。用例分析包括提取用例的概念类，确定概念类之间的关系，以及绘制用例分析类图和用例分析交互图三项工作。3概念类分析概概念念类类分分析析(Conception Class Analysis)是对所提取的各概念类的职责、属性、关系和特殊需求所进行的分析。第6章系统分析6.2 逻辑模型逻辑模型6.2.1 逻辑模型的含义逻辑模型的含义逻辑模型逻辑模型(Logic Model)是对信息系统要素、构成

4、和结构的抽象描述，它是系统分析的结果，因此也被称为分析模型分析模型，其构成见图6.1。逻辑模型由逻辑系统构成，逻辑系统是顶层分析包。逻辑系统又被分解为多个分析包、概念类以及用例分析，允许分析包嵌套。第6章系统分析图6.1逻辑模型第6章系统分析6.2.2 概念类概念类1概念类的含义和特征概概念念类类(Conception Class)是在概念层次上，对信息系统的抽象要素的一种称谓。概念类主要来源于业务领域中的客观实体、系统与外界的交互处理和对系统要素的控制三个方面。概念类面向功能需求，一般不考虑性能要求，具有突出业务领域、突出概念性及大粒度的特征。第6章系统分析2概念类的内容1)职责：概念类在信

5、息系统中的作用和责任。主要从应用需求角度描述概念类的职责，一般不细化到操作和接口级别。2)属性：概念类的性质和特征，应从概念层次描述该概念类的主要性质，不需要指定属性的类型、可见性等。3)关系：概念类相互之间存在的关联、聚合、泛化等关系。4)特殊需求：在后续阶段细化或实现该类的某些特殊的性能需求。第6章系统分析3概念类的类型UML把概念类分为实体类、边界类和控制类三种类型，并表示成为图6.2所示的两种形式。图6.2概念类的表示第6章系统分析1)实体类实体类实体类(Entity Class)是信息系统表示客观实体的抽象要素。书店中的“书目”、“书单”、“书款”等都属于实体类。实体类一般对应着在业

6、务领域中的客观事物，或者是具有较稳定信息内容的系统元素。实体类来源于业务分析中所确定的实体，实体字典是确定实体类的依据。第6章系统分析2)边界类边边界界类类(Boundary Class)是描述系统与参与者之间交互的抽象要素。边界类只是对信息系统与参与者之间交互的抽象建模，并不表示交互的具体内容及交互界面的具体形式。例如，“售书界面”用来抽象地描述售书员与书店信息系统的交互处理，见图6.3。图6.3“售书界面”边界类第6章系统分析3)控制类控控制制类类(Control Class)是表示信息系统对其它对象实施协调处理、逻辑运算的抽象要素。例如，在书店信息系统中，“出售图书”就属于控制类，见图6

7、.4。图6.4“出售图书”控制类第6章系统分析6.2.3 用例分析用例分析1概述用例分析用例分析是指从概念层次上对一个用例的分析及分析的结果。用例分析有两个含义，一是从概念层次上对用例的分析工作及分析过程，二是表示对用例分析之后所得到的结果。用例分析需要从概念层次上，分析为了实现给用例规定的功能，共需要哪些概念类，这些概念类之间的关系，以及各概念类之间所交互的信息。用例分析用两种图来表示，一种是表示用例概念类结构的用例分析类图，另一种是反映各概念类之间动态交互信息的用例分析协作图。第6章系统分析在系统分析工作中，通过对需求模型中的每一个用例的分析，得到了对应于需求模型中用例的用例分析结果。用例

8、分析与用例之间存在一一对应的跟踪关系，可以从用例分析追踪到用例(见图6.5)。图6.5用例分析到用例的跟踪第6章系统分析2用例分析类图用例分析类图用例分析类图(UseCase Analysis Class Diagram)用来描述一个用例中的概念类之间的关系所呈现出的静态结构。用例分析类图抽象地描述各概念类之间的关系，不涉及过多的细节。图6.6是对第5章图5.9(e)中“售书处理”用例进行分析所得到的用例分析类图。与该用例发生交互关系的参与者是“售书员”；边界类是“售书界面”；实体类有“书目”、“架存图书”、“待售图书”和“售出图书”；控制类有“产生待售图书”、“开书单”和“出售图书”。第6章

9、系统分析图6.6“售书处理”的用例分析类图第6章系统分析3用例分析协作图用用例例分分析析协协作作图图描述为了实现用例的功能，参与者与信息系统以及信息系统中的各概念类之间所交互的消息。通过整个消息的传递来实现用例的功能。图6.7是对应于图6.6的用例分析协作图。第6章系统分析图6.7“售书处理”的用例分析协作图第6章系统分析6.2.4 分析包分析包分分析析包包(Analysis Package)是信息系统逻辑结构的结构单元，是对逻辑模型中的概念类、用例分析等要素进行组织和管理的一种中间模块。按照内容相关性，把多个聚合度强的概念类和用例分析划归到一个分析包中。一个分析包除了包括概念类和用例分析之外

10、，也可能包含其它分析包。分析包具有较强的聚合性和较低的耦合性。分析包一般根据某一应用主题得出，并可以作为设计模型中的子系统。第6章系统分析分析包分为专用包、通用包和服务包三种类型。1)专用包：为完成某种功能而设置，一般分析包都属于专用包。2)通用包：能够被多个分析包所共享。例如，在书店信息系统中，“书目”实体类会被多个分析包所共享，设置“书目管理”分析包来专门管理图书书目。3)服务包：专门向信息系统高层提供特定服务的分析包。例如，“文档预览包”、“文档打印包”、“远程调用包”、“查询代理包”等都向信息系统高层提供通用服务，因而它们都属于服务包。第6章系统分析6.3 逻辑结构分析逻辑结构分析6.

11、3.1 概述概述1逻辑结构信息系统逻辑结构由多个分析包按照组成关系或依赖关系构成。可以对分析包进行分解，高层分析包由多个低层分析包组成，可以层层分解，直到分析包的功能已经十分清楚，并且规模适中为止。信息系统逻辑结构的一般形式见图6.8。第6章系统分析图6.8信息系统逻辑结构第6章系统分析2逻辑结构分析的任务信息系统逻辑结构分析的任务是根据信息系统的需求结构，确定出信息系统的逻辑结构。信息系统逻辑结构分析主要包括分解并确定分析包，以及确定分析包之间的相互关系两方面的工作。第6章系统分析6.3.2 逻辑结构分析逻辑结构分析1逻辑结构分析的依据信息系统逻辑结构分析的依据是在需求分析中确定的信息系统需

12、求结构。在逻辑结构分析的开始，可以直接把需求结构作为要对之进行分析的初步逻辑结构，把需求结构中的需求包作为逻辑结构中的分析包，包的名称和组成关系都不改变。接下来在初步逻辑结构的基础上，通过对各个分析包的分解和优化，最后确定出信息系统的逻辑结构。例如，把图5.2所示的书店信息系统需求结构作为初步逻辑结构，见图6.9。第6章系统分析图6.9书店信息系统初步逻辑结构第6章系统分析2分解和确定分析包在逻辑结构中的不同位置，分析包具有不同的抽象度。其逻辑系统是抽象度最高的一个分析包，越处在逻辑结构的上层，其抽象度越高，越在下层，其抽象度越低。确定逻辑结构的过程就是从顶层分析包开始，逐层对分析包进行分解，

13、直到分解到底层分析包为止。第6章系统分析判断是否达到底层分析包有以下几个准则：(1)底层分析包支持一个具体并简单的业务过程的用例。底层分析包应该支持一个具体的业务过程，如果业务还比较复杂，就需要对这个业务进行分解，直到业务已经十分清楚、简单为止。例如，在书店信息系统的需求结构中，“计划订购”是一个需求包，这个包支持的“图书计划”和“图书订购”两个业务都十分复杂，因此，就需要进行分解。第6章系统分析(2)底层分析包支持一个具体系统参与者的用例。一个底层分析包不要支持多个系统参与者，如果发现一个分析包所提供的功能可能被多个系统参与者所使用，则需要对其进行分解。例如，“计划订购”分析包所提供的功能要

14、被计划员和采购员两个参与者所使用，因此需要对其进行分解。(3)底层分析包应该具有较强的内聚性。如果用例之间具有泛化、关联等关系，那么这些用例要尽量地放到一个分析包中。第6章系统分析3确定分析包之间的依赖关系在确定了分析包之后，还需要确定分析包之间的依赖关系。如果分析包A中内容的改变将会引起分析包B内容的改变，则这两个包之间就存在依赖关系，并且我们说分析包B依赖分析包A。依赖关系用带箭头的虚线表示。通用包和专用包之间经常会存在依赖关系。分析包之间的依赖关系见图6.10。图6.10分析包之间的依赖关系B分析包A分析包分析包B分析包A专用包通用包第6章系统分析4逻辑结构分析过程以书店信息系统为例，讨

15、论分析包的分解过程。图6.9是从书店信息系统需求结构转来的初步逻辑结构。在这个图中，书店信息系统被分解为“计划订购”、“书库管理”、“图书销售”和“事务管理”四个高层抽象分析包(见图6.11)，这四个分析包分别代表书店管理四方面的功能。图6.11书店信息系统顶层逻辑结构第6章系统分析下面我们对前三个分析包分别进行分解。1)“计划订购”分析包的分解图5.4所示的计划订购管理功能用例图把“计划订购”需求包分解为“计划管理”、“订单管理”、“合同管理”、“到货管理”、“书目管理”和“供书商管理”六个用例，这六个用例分别代表了计划订购管理的六方面相对独立的功能，因此，我们把图6.9中的“计划订购”分析

16、包分解为对应的“计划管理”、“订单管理”、“合同管理”、“到货管理”、“书目管理”和“供书商管理”六个分析包。第6章系统分析图6.12计划订购分析包的分解第6章系统分析2)“书库管理”分析包的分解图6.9把“书库管理”分解为“入库”、“出库”、“盘库”和“报损”四个分析包(见图6.13)，这四个包已经分解得相对独立，无须再进行进一步的分解。图6.13书库管理分析包的分解第6章系统分析3)“图书销售”分析包的分解图5.8“图书销售”需求包包括“领书”、“图书上架”、“销售图书”、“结账”、“盘架”和“资金结算”六个用例。这六个用例分别分解为图5.9的(a)(f)六个功能用例图。因此，可以对应把图

17、6.9中的“图书销售”分析包分解为“领书”、“图书上架”、“销售图书”、“结账”、“盘架”和“资金结算”六个分析包。其中：“领书”分析包又分解为“编辑出库图书”、“查询出库信息”和“打印出库单”三个分析包；“图书上架”分解为“编辑上架图书”、“查询上架信息”和“打印架存报表”三个分析包；第6章系统分析 “销售图书”分解为“售书处理”、“浏览销售信息”、“打印销售报表”三个分析包，同时又从“售书处理”中分解出一个“收书款”分析包；“结账”分解为“销售汇总”和“打印销售账单”两个分析包；“盘架”分解为“编辑盘架信息”和“打印盘架单”两个分析包；“资金结算”分解为“收款汇总”和“打印结算单”两个分析

18、包。第6章系统分析图6.14图书销售分析包的分解对“图书销售”分析包分解的结果见图6.14。第6章系统分析逻辑结构确定之后，每一个分析包都对应着在需求分析中确定的一个或多个用例。例如，图6.15列出了图6.14的“销售图书”等分析包与图5.9中销售图书用例图中的用例之间的对应关系。图6.15分析包与用例的对应关系第6章系统分析6.4 用例分析用例分析6.4.1 概述概述确定了逻辑结构之后，接下来需要对每一个分析包中的用例进行分析。用例分析将逐一对分析包中的每一个用例进行分析，提取概念类，分析各个概念类之间的关系，确定用例分析类图和用例分析交互图。因为要对需求模型中的每一个用例进行分析，所以分析

19、的工作量很大，分析人员需要认真对待。第6章系统分析6.4.2 用例分析过程用例分析过程用例分析一般需要经过三个步骤：第一步提取用例的概念类。先确定实体类，再确定边界类，最后确定控制类。第二步确定用例中概念类之间的关系，并绘制用例分析类图。概念类之间有关联关系、泛化关系和依赖关系，其中主要是关联关系。第三步分析参与者与用例所交互的信息，以及用例中各概念类之间所交互的信息，并得出用例分析交互图。第6章系统分析以图5.9(e)“售书处理”用例为例，介绍用例分析过程。1“售书处理”用例分析售书的处理过程是：读者把从书架上选择的图书拿到售书员面前，售书员用条码扫描仪接收读者所选图书的书号，并启动系统打印

20、出三联书单。读者持书单到收款台交书款，收款员接收书款之后，自己留存一联书单，并在另外两联书单上盖章，交给读者，读者再持交款后的书单到售书员前领取图书。售书员见到盖章后的书单，自己留存一联，然后给图书盖章，并把图书和一联书单交给读者。第6章系统分析1)提取概念类边界类：“售书界面”。实体类：“书目”、“架存图书”、“待售图书”和“售出图书”。控制类：“产生待售图书”、“开书单”和“出售书单”。见图6.16。图6.16“售书处理”的概念类第6章系统分析2)用例分析类图“售书处理”的用例分析类图见图6.17。图6.17“售书处理”的用例分析类图第6章系统分析3)用例分析交互图“售书处理”的用例分析交

21、互图见图6.18。首先，售书员把读者要购买图书的书号扫描到“售书界面”中。接着，由“产生待售图书”控制类从“书目”和“架存图书”实体类中取出待售图书的有关信息，放到产生的“待售图书”对象之中。然后，由“开书单”控制类控制产生书单，并把书单信息送至“打印进程”打印出书单。待读者交款之后，由“出售图书”控制类产生“售出图书”对象。第6章系统分析图6.18“售书处理”的用例分析交互图第6章系统分析2“收书款”用例分析1)提取概念类边界类：“收款界面”；实体类：“待售图书”；控制类：“核对书单”、“收书款”。“收书款”的概念类见图6.19。图6.19“收书款”的概念类第6章系统分析2)用例分析类图“收

22、书款”的用例分析类图见图6.20。图6.20“收书款”的用例分析类图第6章系统分析3)用例分析交互图收书款的用例分析交互图见图6.21。“收书款”用例的交互过程是：收款员把待售图书的书单号输入给“收款界面”，由“核对书单”控制类把接收的书单号与已产生的待售图书对象进行核对，如果核对无误就可以收款，否则将拒绝收款。接下来由“收书款”控制类在待售图书对象中登记已收款标记。第6章系统分析图6.21“收书款”的用例分析交互图第6章系统分析6.5 概念类分析概念类分析6.5.1 职责分析职责分析概念类的职责概念类的职责是概念类在信息系统中的责任和作用。应该注意四方面的问题：第一，面向业务应用。着重根据概

23、念类在业务中所起的作用，确定概念类的职责。第二，具有概括性，不要过多陷入细节。第三，全面分析。全面分析概念类在各个用例中的作用。第四，用自然语言描述。第6章系统分析下面分析图6.17中“书目”、“售书界面”、“产生待售图书”三个概念类的职责。1)“书目”类：职责是存放书店所能处理的所有图书的基本信息，并提供对图书基本信息的共性管理功能。2)“售书界面”类：职责是提供售书员和系统在销售图书时的交互界面。3)“产生待售图书”类：职责是根据接收的待售图书书号，从“书目”类中取出该书号的图书信息，合成一个“待售图书”对象，放入到“待售图书”概念类中。第6章系统分析6.5.2 属性分析属性分析1属性的概

24、念一般讲，属性属性表示实体的特性或特征。在OO方法中，属性属性用来表示对象的静态特性。属性项属性项是构成对象静态特性的项目称。属性值属性值是每一个属性项中的具体值。例如，对象“人”的属性有：姓名、性别、出生年月、家庭住址、电话、体重、身高、血型、爱好、职业、毕业院校、专业等；属性项：姓名、性别等项目称为对象“人”的；属性值：赵晓，男，1966.10.12，西安石油学院11楼103号，8216381，63公斤等则是。第6章系统分析2属性命名和类型1)属性的命名(1)使用名词或带定语的名词。像“姓名”，“学生姓名”，“型号”，“产品型号”，“商品条形码”等。(2)尽量使用问题域中规范、通用的词语，

25、避免使用没有明确含义或自定义的词语。2)属性的类型属性的类型是指属性值的类型，一般有数字型、字符型、逻辑型、日期型等。在系统分析阶段一般不需要确定属性的类型。第6章系统分析3属性分析属性分析的一般途径：(1)从常理上看，概念类所表示的事物有哪些静态特性；(2)在业务领域中概念类所具有的属性；(3)信息系统要求概念类应具有的属性；(4)概念类需要记录和保存的信息；第6章系统分析(5)不同类型概念类的属性。实体类。实体类属性可以直接根据事物本身的性质来确定。例如，对于“图书”属性，就可以通过对图书性质的分析来确定。边界类。可以根据边界类所承担的交互信息项目来确定边界类的属性。例如，对于“收款界面”

26、边界类，输入的信息是“待售书号”和“书款信息”，输出的信息是“收款图书信息”和“已收款提示”，我们就可以把这四项信息项目作为“收款界面”的属性。控制类。控制类一般没有属性。第6章系统分析(6)属性和类的转化。如果一个类的某一属性项过于复杂，说明这个属性包容的内涵很丰富，属性本身就表示一个复杂的事物实体，可以把这个属性作为一个类来看待。如果一个类中因属性项目过多，使得类过于庞大，可以根据这些属性的相关性，把一个类分成多个类，以简化类的规模。第6章系统分析下面我们分析图6.20中“书目”、“售书界面”和“产生待售图书”三个概念类的属性。“书目”类：书号、书名、作者、出版社、单价、出版日期、图书类别

27、。“售书界面”类：图书书号和图书信息。“产生待售图书”类：没有属性。第6章系统分析6.5.3 关系分析关系分析概念类之间存在关联、聚合、泛化和依赖关系。对提取的各个概念类，分析并确定它们之间的相互关系。概念类之间必须是客观存在的关系，不能强加赋予。下面我们给出前面书店信息系统“售书处理”用例所提取的部分概念类之间所存在的关系，见图6.22。第6章系统分析图6.22“售书处理”用例部分概念类之间的关系第6章系统分析6.5.4 确定通用概念类确定通用概念类通用概念类与多个分析包存在关联关系。通用概念类一般都是实体类。在图6.22中抽取的概念类中，“书目”应该是一个通用概念类。两种处理办法：一是把通

28、用概念类放到通用分析包中；二是从分析包中分离出来，作为系统重点关注的独立概念类。第6章系统分析6.5.5 特殊需求特殊需求提取的部分概念类可能会存在一些特殊的性能需求，在此，也需要捕捉这些特殊需求，以便在系统设计阶段进行考虑。例如，图6.23是“书目”概念类的特殊需求。“书目”类的特殊需求：范围：每个对象约100字节 容量：最大为100000 更新频率：创建/删除：50次/天,更新：创建后一般不更新,读取：访问50次/小时图6.23“书目”类的性能要求第6章系统分析6.5.6 概念类字典概念类字典概概念念类类字字典典(Conception Class Dictionary)用来记录系统分析中提

29、取的概念类，并对概念类进行说明。概念类字典由概念类目录和概念类条目两部分构成。在概念类目录中，按照确定顺序列出概念类名和概念类条目编号，一般按照实体名的汉语拼音字母顺序编排。概念类条目是对各概念类的详细描述，一个概念类对应一个概念类条目。在概念类条目中，应该描述概念类条目编号，概念类名，职责，属性，说明和特殊需求。下面给出书店信息系统的部分概念类字典。第6章系统分析1概念类目录书店信息系统概念类目录见表6-1。目录中列出了书店信息系统逻辑模型中的部分概念类。概念类条目编号的规则是：第1位表示该概念类的顶层分析包，用字母表示。其中，A表示计划订购，B表示书库管理，C表示图书销售，D表示事务处理，

30、Q表示公用概念类。第2位是概念类的类型。其中，1表示实体类，2表示边界类，3表示控制类。后两位是顺序号。例如，C-2-01表示“售书界面”属于“图书销售”分析包中界面类的第一个概念类。第6章系统分析表6-1书店信息系统概念类目录概念类名说明条目编号页号售书界面售书员与系统的交互界面C201产生待售图书产生待售图书类C301开书单打印书单C302出售图书把待售图书转变为售出图书C303书目图书的基本信息Q101架存图书书架上存放的图书C101待售图书等待销售的图书C102售出图书销售出去的图书C103第6章系统分析2概念类条目概念类条目应该包括每一个概念类的编号，概念类名，职责，属性，说明，特殊需求等信息。在此，我们以“书目”概念类为例，说明概念类条目的编制方法，见图6.24。第6章系统分析图6.24概念类字典例子编号：Q-1-01概念类名：书目职责：存放书店所能处理的所有图书的基本信息属性：书号，书名，作者，出版社，单价，出版日期，图书类别说明：该概念类中存放所有图书类的公用信息。它是“采购图书”、“入库图书”、“库存图书”、“出库图书”、“盘存图书”、“报损图书”，“架存图书”、“待售图书”、“售出图书”等概念类的公共超类特殊需求：范围：每个对象约100字节；容量：最大为100000；更新频率：创建/删除：50次/天，更新：创建后一般不更新，读取：访问50次/小时