《第九章-系统分析课件》由会员分享，可在线阅读，更多相关《第九章-系统分析课件（93页珍藏版）》请在金锄头文库上搜索。
1、1第九章 系统分析主讲人：李玥系统分析开始规划开始规划确确定定新新世世界界的的万万物物2办理登机手续业务用例场景3确定系统用例n申请登记n分配勘察n现场勘察n是否符合用电条件n业务存档n用电审批n配电审批n业务收费n现场施工n安装电表4低压用电申请业务用例场景5申请永久用电系统用例6 描述系统用例的方法与描述业务用例的方法类似，描述系统用例的过程，就是系统建模的过程，对比业务建模过程，系统建模所采用的工具仍然是用例场景、用例规约、对象模型、用例实现、用例实现场景等等 与业务建模的区别是，我们的视角和建模的目的已经从原来的描述业务、理解业务变成了理解系统、描述系统描述系统用例7描述系统用例n用例
2、场景示例：申请登记用例场景示例n申请登记用例场景示例8描述系统用例n所谓系统建模，就是引入计算机系统以后，业务如何通过计算机得以实现的过程n活动图适于解释角色职责类场景n提问：采用时序图和交互图可以直接步入设计过程，为什么还要绘制活动图呢？n活动图相当于纲领；有纲领的引导，不容易因为要处理的信息过多而在设计过程中丢失内容n虽然是系统设计，系统用例仍然属于要向客户提交的文档范围；在UML的需求规格说明书里包含两部分内容，一部分是业务需求，这部分由业务建模来描述；另一部分是系统需求，这部分内容由系统建模来描述；活动图较易懂n黑盒测试用例的现成来源9描述系统用例n场景图只描述了过程，并未展示出系统实
3、现需求的所有细节，这些细节使用用例规约来描述10用例规约示例用例规约示例用例名称su_申请登记用例描述业务员创建新的申请单，录入用电客户申请资料，创建申请流程执行者业务员（代理用电客户操作）前置条件业务员成功登录系统后置条件1.创建新的申请单并生成唯一的申请编号2.创建新的永久用电申请流程实例3.推进至分配勘察流程环节4.提交后的申请单不得再修改描述系统用例11用例规约示例用例规约示例主事件流描述1.业务员选择创建申请单，计算机展示申请单录入界面，执行2；业务员选择继续编辑保存过的申请单，执行32.业务员录入用户名称，计算机自动查询该用户在历史上有无欠费记录，应用业务规则a；若有欠费记录，执行
4、异常过程2.1.1；无欠费记录执行主过程33.业务员录入其他资料，选择提交，执行主过程4；选择保存，执行分支过程3.1.1；选择放弃，执行分支过程3.2.14.计算机校验数据准确性，应用业务规则b；若有不符合的数据，执行分支过程4.1.1，否则执行主过程55.计算机生成唯一申请编号6.计算机保存申请单7.计算机将申请过程推进至下一环节8.计算机向业务员展示申请单最终结果，用例结束分支事件流描述3.1.1计算机保存目前录入的信息，生成临时编号3.2.1计算机不保存任何数据，用例结束4.1.1计算机提示错误数据详细情况，提示业务员，返回3描述系统用例12用例规约示例用例规约示例异常事件流描述2.1
5、.1该用户名历史上有欠费记录，计算机显示欠费情况2.1.2.1业务员确认该欠费情况属实，用例终止2.1.2.2业务员确认情况有误，返回3业务规则a.根据用户名从欠费历史中查询该户名有无欠费记录，若有记录，由人工判断该用户名欠费是否属实，若属实应停止申请（这是一条交互性业务规则，若该业务规则已经在业务规则文档中记录，此处可直接引用规则编号而无须文字解释）b.用户名、身份证号、地址、用电类别必填（这是一条内禀规则，应像现在这样写在用例规约文档里）涉及的实体Be_申请单；Be_现场勘察单；Be_业务收费清单；Be_电表安装工作单；Be_用户档案；Be_收费帐号；Be_结算帐号；Be_抄表台帐；Be_
6、监察档案；Be_计量档案这一栏中可以列出与该用例相关的实体；一般情况下，实体要在用例实现一节中经过对象模型建立过程后才填入讨论：n从业务需求到系统需求n业务用例和系统用例的粒度13从业务需求到系统需求14作业：15n根据前面的业务模型中的业务用例场景图分析业务用例场景中的活动，哪些是可以由系统实现的，哪些是需要人工完成的？n将系统实现的那些活动转化成系统用例，并说明转化过程采用了哪种方法n引入计算机，绘制出人机交互的用例场景图n编写用例规约，在编写过程中考虑到前置条件、后置条件、主事件流、分支事件流、异常流和业务规则分析业务规则16设定规则设定规则没没有有规规矩矩不不成成方方圆圆分析业务规则1
7、7n进行业务规则分析，前提是在获取需求时就将业务规则提炼出来，并且以文档的形式进行管理n分析业务规则的目的是从业务规则当中发现出那些将对系统构成重大影响的部分，将其转化为系统需求，并且针对一部分进行有针对性的架构、框架、程序的设计分析业务规则n分析全局规则全局规则是指那些对于系统大部分业务或系统设计都起约束作用的那些规则用例产生业务架构，而支撑起业务运行的是软件架构全局规则是跨用例的规则，也是跨业务架构的规则，因而全局规则在应用程序中就被反映到了软件架构当中，通过软件架构来对用例产生影响18历史数据管理框架示例 19创建历史数据过程20查询历史数据过程21分析交互规则22n交互规则产生于用例场
8、景当中n用例场景是由活动图、交互图等来描述的，不论是活动、状态还是业务对象，在活动转移、状态变迁和对象交互时必然会有一些限制性的条件，这些条件就是交互规则n一般而言，交互规则可以在业务用例场景、业务用例规约、系统用例场景、系统用例规约中找到n在低压用电申请业务用例场景中可以找到两条业务规则：是否符合用电条件？符合则继续办理流程，否则终止流程办理用电审批和配电审批是否都同意供电？是则继续办理，否则终止流程分析交互规则n由于交互规则不但可能由不同的开发人员来开发，还可能分属于不同的子系统、不同的程序包等n因此需要由设计师通盘考虑，避免不必要的依赖23欠费业务规则类示例24欠费业务规则实现示例25分
9、析交互规则n设计师可以设计一个业务规则库来管理和解决所有的交互业务规则26交互规则管理库类图27交互规则管理库实现图28分析内禀规则29n内禀规则指那些业务对象本身具备的，并且不应为外部的交互而变化的规则n内禀规则即使混合在业务逻辑中也不会产生太大问题n当业务规则变化时，受到影响的也仅仅是业务对象自己或者特定的一段程序，不会波及其他程序n保证职责单一特性，即一个方法或一个代码片段只做一件事情n可以将内禀规则代码单独写成一个方法，或一个类，养成好的变成习惯作业：30n找出你项目中的业务规则，将它们分为全局规则、交互规则和内禀规则，并试图用本节所介绍的方法来分析这些规则用例实现绘制蓝图绘制蓝图世世
10、界界将将这这样样运运行行31用例实现到系统用例关系图3233实现用例n 用例场景和用例规约是实现用例的基础，采用的工具则是分析模型n分析模型是采用MVC模式，将用例场景中描述的业务分解为边界（操作界面和展示界面）、控制（业务逻辑）和实体（业务数据），用这三个元素建立实现用例场景的对象模型n边界类对象、控制类对象、实体类对象就成为我们用来实现用例的关键对象2024/9/17实现用例n要为用例实现建模，需要经过以下三个步骤：在用例场景中发现和定义实体对象，这些实体对象代表了将要操作的业务数据需要用控制对象操作和处理实体对象中的数据；在初步实现用例的时候，可以简单地为每一个实体对象加上一个控制对象；
11、每个控制对象操作一个实体对象，默认地包含所有对该实体对象的处理逻辑需要用边界对象构建接收外部指令的界面；边界对象负责接收来自系统外部的指令，并将指令传达给控制对象，控制对象根据指令执行相应的逻辑程序，然后将结果返回给边界对象；最后再由边界对象将结果展示给外部34申请登记用例实现场景35申请登记用例实现场景36n创建新申请n展现新申请录入界面n录入申请人基本资料n校验用户欠费信息n提交申请n校验数据准确性n生成新申请编号n保存申请单n推进至下一环节n显示结果sur_申请登记用例实现37批量申请登记用例实现场景38批量申请登记用例实现场景n创建批量申请n展现批量录入界面n循环校验用户欠费情况n删除
12、欠费用户资料n提交批量申请n处理批量申请39sur_批量申请登记用例时新40申请登记分析类图41讨论：42n分析类是沟通需求和设计的桥梁n为什么用分析列而不是设计类来实现用例场景作业n根据前面项目中的用例场景图，分析用例场景中的活动，描述计算机应该如何处理该活动，从分析结果中找出边界对象，控制对象和实体对象n用找到的分析对象实现用例场景，绘制出时序图n根据时序图中的分析对象交互情况，绘制出分析类图43软件架构和框架设计架构设计架构新新世世界界的的骨骨架架44复杂需求45没有软件架构设计的结果46什么是软件架构n软件架构是一种思想，一个系统蓝图，对软件结构组成的规划和职责设定n软件架构的意义就是
13、要将这些可逻辑划分的部分独立出来，用约定的接口和协议将它们有机地结合在一起，形成职责清晰、结构清楚的软件结构n软件架构是一种逻辑性的框架描述，它可能并无真正的可执行部分；大部分的软件架构都是由一种设计思想，加上若干设计模式，再规定一系列的接口规范、传输协议、实现标准文档构成的n当一个软件架构形成以后，就会有厂商根据软件架构来实现这个架构，开发出若干可执行的半成品，例如某设计模式的实现框架、接口的实现框架、传输协议的开发包等等，这些半成品就是软件框架47什么是软件框架n软甲框架是软件架构的一种实现，一个半成品；n通常针对一个软件架构当中某一个特定的问题提供解决方案和辅助工具，是可执行的48软件架
14、构的基本构成n对于一个商业软件来说，由于其针对一类特定的业务，因此在描述软件架构时应当在软件架构文档里包含特定的业务解决方案n有时候一个业务系统可以采用不止一个的软件架构，也必须在软件架构文档里描述清楚n对于特定的软件产品来说，一个软件架构应当 包括软件层次、每一层次的职责、层次之间的接口、传输协议和标准以及每一层次上所采用的软件框架49软件架构的内容50用包图描述软件架构51框架实现示意图52查询数据架构实现示意图53应用软件架构 业务架构业务架构+软件架构软件架构=业务系统业务系统54作业：n请为你的项目绘制出软件层次架构图n说明每一个层次的职责n说明层次之间交互的接口定义规范和数据传输的
15、标准n说明项目中使用的软件框架是在哪一个层次应用的n绘制出该软件框架的实现交互图55分析模型设计功能零件设计功能零件让让世世界界初初步步运运转转起起来来56建立分析模型n建立领域模型时使用分析模型，可以获得针对某一问题领域的系统视角理解n建立概念模型时，使用分析模型可以获得针对核心业务的系统视角理解n建立用例实现模型时，使用分析模型获得针对系统需求的系统视角理解n现在将使用分析模型获得系统需求在软件架构各层次上的系统视角理解57建立分析模型n建立分析模型的过程，就是采用分析类，一步步将系统需求在软件架构和框架构成的骨架当中注入血肉的过程n分析模型建立完成，可得到一个非常接近于设计类的模型，距离
16、编码所使用的实现类仅一步之遥，可以真正进入系统设计阶段了58建立分析模型申请登记分析类图59申请登记WEB层分析模型实现60申请登记WEB层分析类图61申请登记BussinessControl层实现62申请登记BussinessControl层分析类图63申请登记Entity层实现64申请登记Entity层分析类图65申请登记用例最终分析模型66建立分析模型n通过用例确定系统需求n通过用例实现，得到了系统需求的计算机视角理解n规定了软件架构，确定了软件层次n在每一个层次上决定了适用的软件框架n分析了用例实现在每个软件层次上是如何动作的n根据每个软件层次上所使用的软件框架并使用分析类来实现用例n
17、综合各个软件层次得到的分析类，形成分析模型n最后，得到实现了系统需求最基本的类和类方法67讨论：n值得花精力做分析模型吗？n优化分析模型容易变化的需求结构化和耦合度调整交互集中点调整68作业：n从项目出发，根据系统用例确定软件架构和框架，分析该系统用例如何应用到软件架构的各个层次上n根据各层次上的软件框架，用分析类绘制出该系统用例在各软件层次上的实现过程n提取出获得的分析类，绘制出实现该系统用例的必要分析类图69组件模型设计功能部件设计功能部件构构建建世世界界的的基基础础设设施施70建立组件模型n用来组合类的UML元素成为组件，为组件建模使用的模型就是组件模型n组件用来容纳分析类或设计类，可以
18、理解为一种特殊的“包”n组件不是一种物理结构，它逻辑地引用、使用某些类，这些类组织起来的目的不是为了存放，而是为了完成一组特定的功能71建立组件模型n建立组件模型需考虑：这些组件将成为可复用的单位每个组件都完成了一个或一组特定的功能这些组件将成为可独立部署的单位每个组件将要遵循架构规范72申请登记业务运行环境73申请登记业务功能分布情况74申请登记服务组件工作方式75建立组件模型n使用组件来“包装”实现申请登记服务这些类，不代表这些类文件在物理上属于申请登记服务组件，而是申请登记服务组件通过接口将这些类提供的服务包装起来向外部暴露，并且在组件内部实现协调这些类来执行服务请求n这些类物理上还属于
19、原来的客户服务子系统包n当接收到外部请求时，组件通过某种方式将消息传达给这些类来执行76申请登记服务组件运行环境n组件只维护了服务接口和调用实现类的方式，事实上它是独立于调用者和实现者的，因此可以被独立维护、独立部署、独立调整n组件定义+组件实现才是一个完整的组件模型n传统意义上，组件也可当作模块、子系统、类库、程序包、资源包等使用77申请登记服务组件运行环境78低压用电申请业务用例组件集79组件实现关系图80用组件元素绘制程序包图81用包元素绘制程序包图82讨论：n组件是可复用单元n组件是可独立变化的单元n组件是可独立部署的单元n组件可在软件架构支持环境下自由组装83组件复用场景1-服务形式相同服务内容不同84组件复用场景2-服务形式不同服务内容相同85组件独立变化场景86组件独立部署场景87WPS环境下的组件安装和运行88作业：n为你的项目建立组件模型（可选做）89部署模型安装零部件安装零部件组组装装一一个个新新世世界界90建立部署模型n应用程序：基础软件结构软件架构外部接口n运行环境：安全环境数据环境外设91供电企业管理系统部署模型92作业：n为你的项目建立部署模型（可选做）93
