软件系统分析第七章

1、第七章第七章 UML分析与设计方法分析与设计方法概述n基于UML的分析与设计方法是在面向对象的方法上进一步规范与完善分析与设计，使其技能表示系统的静态特征又能表示动态行为；既能表示抽象逻辑特征，又能表示需求功能特征及物理特征。因此是一种较为全局、整体的反映系统分析、设计的工具。特点n统一性n二维模型n工具RUP的二维开发模型n传统的瀑布开发模型是一个一维的模型，开发过程被划分为多个连续的阶段。n实际过程中，在开发整个周期中，每个阶段均会产生改变，可以看成是开发全过程中的一种工作流。n在RUP中，软件开发生命周期根据时间和RUP的核心工作流划分为二维空间。n横轴表示项目的时间维横轴表示项目的时间

2、维， 通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构n纵轴以内容来组织纵轴以内容来组织，为自然的逻辑活动。体现开发过程的静态结构n基于二维模型的两种分析于设计方法n迭代n递增需求工作流需求工作流概述n需求工作流通过对应问题的理解和分析，确立问题涉及的信息、功能和系统行为，将用户需求精确化、完全化。 n需求的焦点主要在初始和精化阶段主要在初始和精化阶段，在精化阶段后期，需求捕获的工作量大幅下降。 n需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围n需求工

3、作流开始前，首先要对业务建模，业务建模就是对业务组织、业务内容和业务流程进行建模。业务模型为需求工作打下基础。(需求工作流开始的前提)n需求捕获通过对业务内容进行描述、整理，确立业务实体及其关系；确定业务系统的功能要求；确定实现功能要求的实体间的交互关系。将用户需求精确化、完备化内容n对问题域的理解n首要任务n包括n对系统功能、性能的了解n对业务流程的了解n对数据的了解n需求调研方法n个别调查、会议讨论、搜集书面资料n建立初始功能模型n在需求理解基础上，以功能为核心以功能为核心，建立初始功能模型nUML里的用例视图描述系统功能n优化模型n检验模型是否符合用户的要求n修改模型直到达到用户的要求为

4、止UML制品n在需求捕获工作流，主要的UML制品：n用例n角色n系统n联系n角色与用例之间的联系n用例之间的联系n角色之间的联系n用例之间的关系用例之间的关系n版类Include/Uses：包含/使用关系n有先后关系，执行B时，必须要执行A用例A用例BUsesn用例之间的关系n版类Extend：扩展关系n本质就是泛化用例A用例BExtendn角色之间的关联角色之间的关联n关联关系：关联关系：一般性联系n角色之间的关联角色之间的关联n继承关系：继承关系：一般与特殊n也存在单继承和多继承n场景场景n自然语言描述n不是一开始就很详细n如同其他工作流一样，随着迭代和递增过程会不断细化及明确例-用例图n

5、例7.2n图7.8n例7.3n图7.9n场景图7.10工作人员n参与需求捕获阶段的工作人员：系统分析人员（System Analyst）用例描述人员（Use Case Specifier）用户界面设计人员（User Interface Designer）构架设计师（Architect）需求工作流的活动n需求捕获的工作流主要包括五个活动：确定参与者和用例区分用例的优先级详细描述一个用例构造用户界面原型构造用例模型n确定参与者和用例：确定参与者和用例：确定参与者和用例的目的是界定系统的范围，确定哪些参与者将与系统进行交互，以及他们将从系统中得到哪些服务(用例)业务模型的建立是“确定参与者用例”前提

6、，而“确定参与者用例”又是用例模型（概要）的先决基础。n区分用例优先级：区分用例优先级：区分用例优先级是为了决定用例模型中哪些用例需要在早期的迭代中进行开发(包括分析、设计、实现等)，以及哪些用例可以在随后的迭代中进行开发n详细描述用例：详细描述用例：详细描述用例的主要目的是为了详细描述事件流。这个活动包括建立用例说明、确定用例说明中包括的内容、对用例说明进行形式描述。他最终的结果是以图或文字表示的用例的详细说明。n构造用户界面原型：构造用户界面原型：在系统分析人员建立起用例模型，确定了谁是用户以及他们要用系统做什么后。接下来的工作就是要着手设计用户界面。这个活动由逻辑用户界面设计、实际用户界

7、面设计和构造原型两部分组成，它最终的结果是一个用户界面简图和用户界面原型。n构造用例模型：构造用例模型：构造用例模型的主要目的是：整理用例间的关系，分离出包含用例和扩展用例；补充用例场景。这个活动由确功能说明、确定用例之间的其他关系组成。在确定系统用例和参与者之后。系统分析人员可以重新整理用例之间的关系，使模型更易于理解和处理。图书馆信息系统需求工作流n系统描述图书馆信息系统主要处理要求是有关馆藏图书与杂志的借阅与保存系统基本要求n图书馆的所有图书、杂志必须在系统中登记、注册（case：增加）。由编目人员负责（actor：编目人员）n图书馆会采购新书，对旧书、过期期刊、破损及遗失书刊进行处理（

8、case：删除）由服务人员负责（actor：服务人员）n读者可以借阅与归还书刊（case：借阅、归还）（actor：读者）n管理员中的服务人员可以对所借书刊进行预订工作（case：预订、撤销预订）（actor：服务人员）n系统采用三层C/S结构，采用*系统和*数据库进行管理三层C/S结构n表示层n是应用的用户接口部分，它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据，显示应用输出的数据。一般使用图形用户接口，检查的内容也只限于数据的形式和值的范围，不包括有关业务本身的处理逻辑n功能层n应用的本体，它将具体的业务处理逻辑编入程序中n数据层n数据层作为DBMS独立出来n基于以上问题

9、域的要求及理解，得出n用例n角色n它们之间的关系n场景描述查找借书者查找书目标记已借出该书增加一条新借书记录删除预计记录标记借出该书增加一条新借出记录已借出否预订否YesNoNoYes借阅书刊活动图：需求工作流细化n以上是粗糙的初始功能模型，可以通过迭代和递增继续深入理解并修改完善，即细化过程。n需要修改的点：n实际情况中，某种书刊通常会购买多本，需要区分同一种书刊的多本书书题与书目n合并服务人员、编目人员为管理人员，系统不关注它们的信息n功能模型的改动n用例：n增加书题、删除和修改书题n角色：n合并为图书馆管理人员n关系：n场景：图7.15分析工作流分析工作流n分析的主要工作开始于初始阶段的

10、结尾，和需求一样是精化阶段的主要焦点。n精化阶段的大部分活动是捕获需求，分析工作与需求捕获在很大程度上重叠。n旨在给出系统的精确的抽象模型。分析工作流n建立静态模型n表示系统的结构信息，系统的主要框架，是必须要做的nUML中用类图表示n从用例图中在问题域和业务流程分析理解的基础上，从用例及角色挖掘对象。n建立动态模型n描述系统的活动规律，包括消息的活动及状态的变化n在UML中用并发视图表示n详细的活动规律可以从业务模型、用例场景中获知n检验及改进模型n检验：n是否满足用户需求n是否合理n修改n通过迭代与递增作进一步修改和补充UML制品n在分析工作流期间，主要的UML制品：n类图n四种动态图n以

11、时序图应用最为广泛图书馆信息系统分析工作流n类图n类n从用例图角色看，有“读者”和“管理员”(忽略)n从用例看，有对象“书目”和“书题”，他们与“读者”之间有“借阅”和“预订”的关联。n类间关系n确定联系类型：在关联、继承、聚合与依赖中，属于“关联”n确定重数：图书馆信息系统类图：借阅书刊时序图 : 读者 : 读者 : Item : Item : Title : Title : Borrower : Borrower : Loan : Loan1: find borrower2: 3: find item4: 5: find title6: 7: identify8: 9: create10:

12、 没有预订预订预订状态图问题域迭代理解n由于书和期刊的属性不同，因此，加以区分，稍作调整。n修改后的用例图n图7.19n最终的类图n图7.20设计工作流设计工作流n设计是整个分析模型的精化和扩充，即扩充模型元素的语义以及增加新的元素。n设计工作流类一般被组织成具有良好接口的设计包(Package)和设计子系统(Subsystem)，而描述则体现了类的对象如何协同工作，实现用例的功能。 n设计工作流的主要工作是位于精化阶段的最后部分和构造阶段的开始部分的主要建模活动。设计工作流n建立设计的静态模型n对类内部做细化，增加重要的属性和操作n对类进行区分：实体类、控制类、界面类n实体类是用于对必须存储

13、的信息和相关行为建模的类 ，用于保存和更新一些现象的有关信息，例如：事件、人员或者一些现实生活中的对象。实体类通常都是永久性的，它们所具有的属性和关系是长期需要的对应于C/S架构的数据层n控制类用于对一个或几个用例所特有的控制行为进行建模，它描述的用例的业务逻辑的实现，控制类的设计与用例实现有着很大的关系。在有些情况下，一个用例可能对应多个控制类对象。控制类有效将业务逻辑独立于实体数据和边界控制，专注于处理业务逻辑，控制类会将特有的操作和实体类分离，者有利于实体类的统一化和提高复用性。 对应于C/S架构的逻辑层n边界类是系统内部与系统外部的角色之间进行交互建模的类，角色通过它来与控制对象交互，

14、实现用例的任务。其形式可以是：为业务主角操作提供的一个GUI，或者系统与其他的系统之间进行一个交互的接口，所以当外部的GUI变化时，或者是通信协议有变化时，只需要修改边界类就可以了，不用再去修改控制类和实体类。对应C/S架构的界面层n根据需要，对类图中的类进行增补，使其更完善。n引入接口、tagged value，constraint，note等，对类间关系进行补充，语义进行深入描述。n划分子系统，组合成包n以上工作可以在原分析阶段类图上修改n建立设计的动态模型n对类间消息以及状态的变化等，继续细化与深化。n根据需要，引入tagged value，constraint，note等。n可以在分析

15、阶段动态图的基础上修改n检验和改进设计模型n检验标准同分析模型n引起修改：n与用户需求不符合，或用户需求变更。n对问题域有新的理解，更加深入。n优化逻辑视图。n根据实际需要，考虑具体实现以及环境等。UML制品n类图，以及并发视图里的四种图nUML的通用机制n便条/注释n修饰nUML扩展机制nTagged value，contraint，stereoType图书馆信息系统设计工作流n类图n增加类的属性及操作，标注属性的类型，以及可见性n根据C/S架构，确定3个子系统n补充数据相关类和界面相关类n增加persistent，封装数据库相关存储机制和操作，控制类从其继承n增加若干界面类，一般形式是主界

16、面+若干子界面用户界面包业务处理包数据库包n设置一些语义限制和约束，设置sterotype，加注note等。n业务处理包n图7.22 : 读者 : 读者 : Main window : Main window : Lending item : Lending item : Item : Item : Title : Title : Borrower : Borrower : Loan : Loan1: find2: find3: find borrower4: find5: find6: find item7: find8: find9: find title10: update11: upd

17、ate12: identify borrower13: create loan实现工作流实现工作流n实现工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式(源文件、二进制文件、可执行文件)实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。n实现是关于把设计模型转换成可执行代码的过程。n实现工作流是构建阶段的焦点。实现工作流n建立系统物理结构图n建立组件图：类的实现文件可以表示成一个组件n建立展开图：首先确定硬件环境和硬件之间连接关系，再描述节点内的组件n实现系统n编程n测试n安装部署n软件打包、发布、安装调试n检验系统并改进n改bugUML制品n在实现工作流中，主要有六种制品：n组件图软件系统实现的框