系统架构师论文-论基于UML的需求分析
论基于UML的需求分析
摘要
UML是集多种面向对象方法的优点于一身的统一建模语言，通过UML可以解决开发过程中存在的一些问题.包括解决人员交流 的障碍，响应需求的变化，利于构件的复用，保证软件项目开发周期等.釆用UML进行需求分析，主要是通过用例模型来捕获和 组织用户的需求，通过用例建模，描述对系统感兴趣的外部角色及其对系统（用例）的功能要求.2006年5月，我参与了某区贸 工局的电子政务系统的开发.在需求分析过程中釆用了基于用例的需求分析方法，取得了良好的效果.在用例建模过程中，通过 识别系统参与者，合并需求获得用例并绘制用例图，进行用例分解及细化用例描述等步骤，及各歩骤间的循环反复，成功完成 了需求分析，需求描述也得到用户的认可.当然,由于使用该方法还不很成熟，各种方法及工具的集成度还不高，未能充分发挥 其作用.在项目中，我担任系统分析员，主要员责系统分析和系统设计工作.
正文
2006年5月，我參与了某区贸工扃的电子政务系统的开发，项目历时七个月，于2007年1月正式上线.顼目组成员共7人，在 项目中，我担任系统分析员，主要负责系统分析和系统设计工作. 区贸工局已有近十年的信息系统使用经验，在本系统开发时，该局除一套采用VB+SQLServer2000。开发的二层C/S结构的核 心系统外,还有多套业务系统和数据交换系统，主要有，外资宙批管理系统、加工贸易电子数据交换平台、加工贸易联网监管电 子数据交换系统以及电子公文交换等.上述各系统基本是相互独立的，只在数据库端实现初歩的数据共享，但应用的集成性很差 . 区贸工局的电子政务系统是一个基于知识管理的全新的集成的管理系统，其应用范围涉及办公自动化、宙批业务管理、档 案管理、数据交换、互联网站等各个方面.该系统由门户网站、亦公自动理三个子系统构成.与原有的业务系统相比，区别主要 体现在三个方面：一是全新的体系结构，二是集成性，全面集成原有的各业务系统及数据交换系统；三是以知识管理为主要恃 征的应用层次上的全面提升，对业务审批的全过程进行监督管理，引入审批需要对相关业务进行智能辅助审批. 在核心的业务管理子系统的开发过程中，考虑到传统结构化开发方法的局限性和软件本身的易复用性、易扩展性和可维 护性，以及可能面对的需求变化，我们在开发时采用了面向对象的方法.UML是集多种面向对象的优点于一身的统一建模语言 ，它使用的统一表示法，呈现一致的风格，通过UML可以解决开发过程中存在的一些问题.首先，UML解决了人员交流的障碍. 它提供了一套通用的思维方式和交流的语言，既有助于分析人员与用户的交流，又有助于分析人员与设计人员的交流.其次， 利于响应变化.分析人员可以将对象作为构筑系统的基本单位，将容易发生变化的属性和操作封装在对象之内，对象之间通过 接口联系，使得需求变化的影响尽可能限制在对象的内部.再次，便于构件的复用,集成UML思想构建的系统模型能很好地支持 软件复用，类可以源生子类，类又可以产生实例对象，而对象具有封装性和信息隐蔽性，这就实现了对象类的数据结构和操 作代码的软构件的复用，最后，因开发人员的方法、工具及经验的差异，往往造成较大型或是较复杂的软件,項目开发周期得 不到保证，若运用UML进行系统的分析设计，利用规范化的表达方式优秀的CASE工具，问题可以得到较好的解袂. 釆用UML进行需求分析，主要通过用例模型来捕获和组织用户的需求，通过用例建模，描述对系统感兴趣的外部角色及其 对系统（用例）的功能要求.在用例建模过程中，首先是识别系统参与者，然后合并需求获得用例，并绘制用例图，最后进行 用例分解及细化用例描述. 1.识别參与者,我们从三个方面分析系统的參与者，一是系统的直接使用者，二是系统的管理维护人员，三是外部相关的 软硬件系统或人员. 系统直接使用者即是使用业务系统的相关业务人员.根据业务岗位，分别有收文、录入、打印、窗口 （一级）宙批、科长（二级）审批、局长（三级）宙批等角色，另外还有派单（针对个别不由系统自动分派任务的情况）、 宙批检查、査询统计和科室管理（执行科室内人中角色的分源业务智能宙批定义等）角色. 系统管理维护人员，主要进行科室管理员的角色分滴以及系统相关初始数据的设定等工作. 外部相关的软硬件系统，即与业务系统进行交互的一些外部系统.包括了外资审批管理系统、加工贸易电子数据交换平台 、加工贸易联网监管电子数据交换系统、电子监察系统、门户网站、办公自动化系统以及系统时钟等，其中门户网站和办公 自动化系统虽是整个电子政务系统的一部分，但相对于业务子系统来说属于外部系统.外部相关人员即申办各类业务的企业办 事人员. 2.合并需求获得用例，绘制用例图，在确定了参与者后，分析參与者希望系统供什么样的功能，为參与者确定用例.之 后画出用例图，通过用例图描述系统包含的参与者、用例以及两者之间的对应关系. 3.用例分解及细化用例描述. 绘制初步的用例图后，还需对用例给予细化，编写用例规约，或是根据情况进行用例分解.用例规约规定了系统需要完成 哪些步骤才能实现用例的功能，主要包括前萱条件、后萱条件和事件流.前置条件指明了执行用例之前系统须处于的状态；后 買条件指明用例执行完毕后系统可能处于的一组状态.事件流描述用例执行的步骤,它又包括基流、分支流和替代流.基流描述 用例执行的基本步骤，没有分支和选择；分支流描述用例在执行中根据不同条件或不同选择而可能执行的步骤；替代流描述 用例在执行中因异常或偶尔发生的一些情况而执行的相应替代步骤.其中基流是必需的，分支流和替代流是可选的. 整个用例的分析及用例图的绘制，需循环执行上述各步.通过参与者及其需求识别用例，通过用例（图）反过来印证识别 出的参与者；对用例进行细化描述，如该描述较复杂则对用例进行分解.这样识别参与者和识别用例交替进行，并结合用例的 细化与分解，直到识别出用例能够涵盖的用户需求.且用户的细化粒度需要保持在用户可以接受的范围.下面以较典型的“外商 投资企业设立“模块的用例图加以说明. 首先根据参与者及相关业务需求，识别出“业务收文”、“业务宙批"、“业务指派”、"信息录入"、“查询”、“数据写监察 系统”、“外资串批管理系统数据读写”等七个用例. 接着又对照系统参与者检查每一个用例，我门发现在“业务收文”漏了与门户网站子系统的交互，即企业先在网站录入资 料的收文受理没有考虑，因此加入了 “门户网站子系统“这一参与者，并添加相关事件（分支）流. 然后，根据用户需求，对部分用例进行细化与分解，从“业务收文,中又进一步分出“补交贫料受理“（即首次收文时资料 不全或不全要求时企业补交资料的受理），"信息录入”中进一步分出“企业资料存档”（即企业负责人签名等若干重要原始资 料的扫描存档），“业务审批”细分为“一级审批”、“二级审批”、“三级审批”，“一级审批”当中再分解出“补交吿知数据写监察 系统“用例的事件流则最复杂，分别与“业务收文“（发送"受理"状态及可选的“补交受理”状态）、“一级审批"（发送"承办"状 态及可选的“补交吿知"状态）、“外资宙批管理系统数据读写"（在外资系统打印批文后，发送“审核”、"批准"、“办结"状态 ）等三个用例相关. 我们使用基于UML的需求分析方法，取得了比较好的效果，特别是相对于传统的需求分析与描述方法其优点是明显的.但 由于我们使用该开发方法还不很成熟，在开发过程中也出现了一些问题.一是UML各图形的组合使用问题-用例分析的方法和用 例图无疑是需求分析的有力工具，但光是进行用例分析还不足够，如能很好地结合类图和活动图等图形，则会对需求的分析 和描述起到很好的辅助作用.另外就是UML与相关工具及开发方法的结合使用问题.UML并不是一套独立的方法或工具，要充分 发挥UML的效用，还须结合统一开发过程以及rose等相关case工具，而在此方面我们还有明显的不足.由于开发大型项目较少 ，因此还很少使用统一的开发过程，CASE工具的使用也还未达到系统化，这部限制了UML方法的效果.另外，由于传统的结构 化开发方法的思维习惯，我们在用例识别过程中有时还会按照DFD图的思維进行思考， 针对在项目开发过程中暴露出的问题，我们以渐进的方式改进我们的开发过程，向统一开发过程靠拢：改善开发环境， 逐步购置、逐步消化使用CASE工具，提高个人的开发水平，深入学习掌握面向对象思想和方法及UML等各类相关CASE工具.我 们不能指望通过一两个项目就完全掌握相关工具和方法，不论组织还是开发者个人，使用先进方法和工具的过程都是一个循 序渐进的过程，
