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

第6章系统分析第6章系统分析6.1概述6.2逻辑模型6.3逻辑结构分析6.4用例分析6.5概念类分析第6章系统分析6.1概述6.1.1系统分析的含义及特点系统分析(SystemAnalysis)是信息系统开发的第三项工作。该项工作是在业务分析和需求分析的基础上，从抽象的概念层次上确定信息系统的要素、构成和结构，得出信息系统的分析模型，并为系统设计提供依据。第6章系统分析系统分析工作的特点如下：(1)内在性。系统分析是站在信息系统内部的角度，分析信息系统的要素、构成和结构。需求分析则具有外在性。系统分析从内在角度，考虑信息系统应该具备哪些要素，要素之间的关系，要素的构成方式等问题。(2)概念性。第一，面向业务领域，反映业务概念；第二，在较宏观和抽象的层次进行分析工作，一般不过多涉及具体细节；第三，不涉及信息系统的实现环境。(3)一致性。系统分析所确定逻辑模型应该具有逻辑一致性，它要纠正需求模型中存在的冗余及错误。第6章系统分析6.1.2系统分析的主要工作1．逻辑结构分析信息系统逻辑结构是从抽象的概念层次和功能需求角度，根据信息系统的需求结构确定的信息系统模型结构。信息系统逻辑结构由分析包按照组成关系或依赖关系构成。逻辑结构分析(LogicStructureAnalysis)要经过确定初步逻辑结构、分解并确定分析包、确定分析包关系等步骤。第6章系统分析2．用例分析用例分析(UseCaseAnalysis)是从概念层次上对分析包中的用例进行的分析。用例分析包括提取用例的概念类，确定概念类之间的关系，以及绘制用例分析类图和用例分析交互图三项工作。3．概念类分析概念类分析(ConceptionClassAnalysis)是对所提取的各概念类的职责、属性、关系和特殊需求所进行的分析。第6章系统分析6.2逻辑模型6.2.1逻辑模型的含义逻辑模型(LogicModel)是对信息系统要素、构成和结构的抽象描述，它是系统分析的结果，因此也被称为分析模型，其构成见图6.1。逻辑模型由逻辑系统构成，逻辑系统是顶层分析包。逻辑系统又被分解为多个分析包、概念类以及用例分析，允许分析包嵌套。第6章系统分析图6.1逻辑模型逻辑模型逻辑系统1分析包*概念类用例分析**第6章系统分析6.2.2概念类1．概念类的含义和特征概念类(ConceptionClass)是在概念层次上，对信息系统的抽象要素的一种称谓。概念类主要来源于业务领域中的客观实体、系统与外界的交互处理和对系统要素的控制三个方面。概念类面向功能需求，一般不考虑性能要求，具有突出业务领域、突出概念性及大粒度的特征。第6章系统分析2．概念类的内容1)职责：概念类在信息系统中的作用和责任。主要从应用需求角度描述概念类的职责，一般不细化到操作和接口级别。2)属性：概念类的性质和特征，应从概念层次描述该概念类的主要性质，不需要指定属性的类型、可见性等。3)关系：概念类相互之间存在的关联、聚合、泛化等关系。4)特殊需求：在后续阶段细化或实现该类的某些特殊的性能需求。第6章系统分析3．概念类的类型UML把概念类分为实体类、边界类和控制类三种类型，并表示成为图6.2所示的两种形式。图6.2概念类的表示实体类边界类控制类形式1：实体边界控制形式2：第6章系统分析1)实体类实体类(EntityClass)是信息系统表示客观实体的抽象要素。书店中的“书目”、“书单”、“书款”等都属于实体类。实体类一般对应着在业务领域中的客观事物，或者是具有较稳定信息内容的系统元素。实体类来源于业务分析中所确定的实体，实体字典是确定实体类的依据。第6章系统分析2)边界类边界类(BoundaryClass)是描述系统与参与者之间交互的抽象要素。边界类只是对信息系统与参与者之间交互的抽象建模，并不表示交互的具体内容及交互界面的具体形式。例如，“售书界面”用来抽象地描述售书员与书店信息系统的交互处理，见图6.3。图6.3“售书界面”边界类售书员售书界面第6章系统分析3)控制类控制类(ControlClass)是表示信息系统对其它对象实施协调处理、逻辑运算的抽象要素。例如，在书店信息系统中，“出售图书”就属于控制类，见图6.4。图6.4“出售图书”控制类售书售书界面出售图书架存图书售出图书第6章系统分析6.2.3用例分析1．概述用例分析是指从概念层次上对一个用例的分析及分析的结果。用例分析有两个含义，一是从概念层次上对用例的分析工作及分析过程，二是表示对用例分析之后所得到的结果。用例分析需要从概念层次上，分析为了实现给用例规定的功能，共需要哪些概念类，这些概念类之间的关系，以及各概念类之间所交互的信息。用例分析用两种图来表示，一种是表示用例概念类结构的用例分析类图，另一种是反映各概念类之间动态交互信息的用例分析协作图。第6章系统分析在系统分析工作中，通过对需求模型中的每一个用例的分析，得到了对应于需求模型中用例的用例分析结果。用例分析与用例之间存在一一对应的跟踪关系，可以从用例分析追踪到用例(见图6.5)。图6.5用例分析到用例的跟踪需求模型用例《跟踪》逻辑模型用例分析用例分析类图用例分析协作图第6章系统分析2．用例分析类图用例分析类图(UseCaseAnalysisClassDiagram)用来描述一个用例中的概念类之间的关系所呈现出的静态结构。用例分析类图抽象地描述各概念类之间的关系，不涉及过多的细节。图6.6是对第5章图5.9(e)中“售书处理”用例进行分析所得到的用例分析类图。与该用例发生交互关系的参与者是“售书员”；边界类是“售书界面”；实体类有“书目”、“架存图书”、“待售图书”和“售出图书”；控制类有“产生待售图书”、“开书单”和“出售图书”。第6章系统分析图6.6“售书处理”的用例分析类图售书员售书界面产生待售图书待售图书出售图书书目架存图书售出图书打印进程“售书处理”的用例分析类图开书单第6章系统分析3．用例分析协作图用例分析协作图描述为了实现用例的功能，参与者与信息系统以及信息系统中的各概念类之间所交互的消息。通过整个消息的传递来实现用例的功能。图6.7是对应于图6.6的用例分析协作图。第6章系统分析图6.7“售书处理”的用例分析协作图:售书员:售书界面:产生待售图书:待售图书:出售图书:书目:架存图书:售出图书:打印进程“售书处理”的用例分析协作图:开书单1:书号及册数3:取书目信息2:书号及册数4:图书信息5:待售图书6:待售图书7:书单8:待售图书9:减架存数量10:售出图书图书信息第6章系统分析6.2.4分析包分析包(AnalysisPackage)是信息系统逻辑结构的结构单元，是对逻辑模型中的概念类、用例分析等要素进行组织和管理的一种中间模块。按照内容相关性，把多个聚合度强的概念类和用例分析划归到一个分析包中。一个分析包除了包括概念类和用例分析之外，也可能包含其它分析包。分析包具有较强的聚合性和较低的耦合性。分析包一般根据某一应用主题得出，并可以作为设计模型中的子系统。第6章系统分析分析包分为专用包、通用包和服务包三种类型。1)专用包：为完成某种功能而设置，一般分析包都属于专用包。2)通用包：能够被多个分析包所共享。例如，在书店信息系统中，“书目”实体类会被多个分析包所共享，设置“书目管理”分析包来专门管理图书书目。3)服务包：专门向信息系统高层提供特定服务的分析包。例如，“文档预览包”、“文档打印包”、“远程调用包”、“查询代理包”等都向信息系统高层提供通用服务，因而它们都属于服务包。第6章系统分析6.3逻辑结构分析6.3.1概述1．逻辑结构信息系统逻辑结构由多个分析包按照组成关系或依赖关系构成。可以对分析包进行分解，高层分析包由多个低层分析包组成，可以层层分解，直到分析包的功能已经十分清楚，并且规模适中为止。信息系统逻辑结构的一般形式见图6.8。第6章系统分析逻辑系统分析包**图6.8信息系统逻辑结构第6章系统分析2．逻辑结构分析的任务信息系统逻辑结构分析的任务是根据信息系统的需求结构，确定出信息系统的逻辑结构。信息系统逻辑结构分析主要包括分解并确定分析包，以及确定分析包之间的相互关系两方面的工作。第6章系统分析6.3.2逻辑结构分析1．逻辑结构分析的依据信息系统逻辑结构分析的依据是在需求分析中确定的信息系统需求结构。在逻辑结构分析的开始，可以直接把需求结构作为要对之进行分析的初步逻辑结构，把需求结构中的需求包作为逻辑结构中的分析包，包的名称和组成关系都不改变。接下来在初步逻辑结构的基础上，通过对各个分析包的分解和优化，最后确定出信息系统的逻辑结构。例如，把图5.2所示的书店信息系统需求结构作为初步逻辑结构，见图6.9。第6章系统分析图6.9书店信息系统初步逻辑结构计划订购书店信息系统书库管理入库出库盘库报损员工信息管理工资管理员工勤绩管理日常事务管理图书销售事务管理第6章系统分析2．分解和确定分析包在逻辑结构中的不同位置，分析包具有不同的抽象度。其逻辑系统是抽象度最高的一个分析包，越处在逻辑结构的上层，其抽象度越高，越在下层，其抽象度越低。确定逻辑结构的过程就是从顶层分析包开始，逐层对分析包进行分解，直到分解到底层分析包为止。第6章系统分析判断是否达到底层分析包有以下几个准则：(1)底层分析包支持一个具体并简单的业务过程的用例。底层分析包应该支持一个具体的业务过程，如果业务还比较复杂，就需要对这个业务进行分解，直到业务已经十分清楚、简单为止。例如，在书店信息系统的需求结构中，“计划订购”是一个需求包，这个包支持的“图书计划”和“图书订购”两个业务都十分复杂，因此，就需要进行分解。第6章系统分析(2)底层分析包支持一个具体系统参与者的用例。一个底层分析包不要支持多个系统参与者，如果发现一个分析包所提供的功能可能被多个系统参与者所使用，则需要对其进行分解。例如，“计划订购”分析包所提供的功能要被计划员和采购员两个参与者所使用，因此需要对其进行分解。(3)底层分析包应该具有较强的内聚性。如果用例之间具有泛化、关联等关系，那么这些用例要尽量地放到一个分析包中。第6章系统分析3．确定分析包之间的依赖关系在确定了分析包之后，还需要确定分析包之间的依赖关系。如果分析包A中内容的改变将会引起分析包B内容的改变，则这两个包之间就存在依赖关系，并且我们说分析包B依赖分析包A。依赖关系用带箭头的虚线表示。通用包和专用包之间经常会存在依赖关系。分析包之间的依赖关系见图6.10。图6.10分析包之间的依赖关系B分析包A分析包分析包B分析包A专用包通用包第6章系统分析4．逻辑结构分析过程以书店信息系统为例，讨论分析包的分解过程。图6.9是从书店信息系统需求结构转来的初步逻辑结构。在这个图中，书店信息系统被分解为“计划订购”、“书库管理”、“图书销售”和“事务管理”四个高层抽象分析包(见图6.11)，这四个分析包分别代表书店管理四方面的功能。图6.11书店信息系统顶层逻辑结构计划订购书店信息系统书库管理图书销售事务管理第6章系统分析下面我们对前三个分析包分别进行分解。1)“计划订购”分析包的分解图5.4所示的计划订购管理功能用例图把“计划订购”需求包分解为“计划管理”、“订单管理”、“合同管理”、“到货管理”、“书目管理”和“供书商管理”六个用例，这六个用例分别代表了计划订购管理的六方面相对独立的功能，因此，我们把图6.9中的“计划订购”分析包分解为对应的“计划管理”、“订单管理”、“合同管理”、“到货管理”、“书目管理”和“供书商管理”六个分析包。第6章系统分析图6.12计划订购分析包的分解计划管理计划订购订单管理合同管理书目管理到货管理供书商管理计划单管理计划执行统计合同信息管理合同执行统计到货信息管理到货统计第6章系统分析2)“书库管理”分析包的分解图6.9把“书库管理”分解为“入库”、“出库”、“盘库”和“报损”四个分析包(见图6.13)，这四个包已经分解得相对独立，无须再进行进一步的分解。图6.13书库管理分析包的分解书库管理入库出库盘库报损第6章系统分析3)“图书销售”分析包的分解图5.8“图书销售”需求包包括“