基于uml的面向对象需求分析

基于uml的面向对象需求分析

1统一建模语言面向对照编程是经过工艺编程之后的恶意软件发展的一个重要变革。而综合了以Booch、Jacobson、Rumbaugh为代表人物的三种软件建模方法而成的统一建模语言（UnifiedModelingLanguage简称UML），就是这种面向对象编程的极致所成。UML用于确定、展示和记录软件系统，是一种用于系统软件规约化、可视化的构造及建模标识。而其中的图形标记，尤其适用于面向对象的软件设计。2流程分析需求分析的目标是建立可理解的现实世界模型，其主要任务是明确系统要完成的功能。因此，需求分析要解决问题可以归结为一个流程：系统要做什么—>谁去做—>如何去做—>何时做—>做的顺序又怎样。然而不适当的需求定义却常常忽略了某个环节或其中环节的必要联系，从而导致产品质量低下、开发周期漫长或遗漏关键功能等问题。3基于uml的对象分析方法UML为软件系统的需求分析提供了强大而较为全面的模型，该文着重分析用例图（UseCase），类图（ClassDiagram），包图（PackageDiagram），状态图（StateDiagram）和序列图（SequenceDiagram）等模型。这种面向对象（Object-Oriented简称OO）需求分析就是把对象作为一个整体，同时又以多态性与继承性的观点来对问题进行空间和时序上的研究，以便产生一个外部可观察的行为。基于UML的面向对象需求分析克服了传统的需求分析对问题领域受时效上的限制和对系统功能无法把握其精确程度等缺点；同时解决了数据流分析的层次复杂性，对信息模型的映射程度加强了；而且UML作为面向对象的可视化标准建模语言，采用图形符号表示系统中的对象和关系，从不同的角度描述待开发系统，为更好地理解业务流程提供有效的交流形式。一个系统不仅表现为静态结构，也有动态行为，而静态建模机制和动态建模机制也正是UML特点所在。该文将对UML的建模机制及其特点进行分析，从静态对象的设计模式，到动态对象模型的方案说明，并结合当代高速公路的征费系统软件去阐述UML在实际需求分析中的应用。图1是基于UML的需求分析的一般性的方案图，整个工作就是从这儿开始的。3.1系统与uml的交互用例（UseCase）即是使用实例，是从用户的角度出发来考虑计算机能实现哪些具体目标，从而帮助开发人员获取更多的需求。从需求角度来说，一个用例就是用户由于某种外部事件而与计算机之间进行的一次交互。笔者以道路征费系统为例来描述需求分析中用例图的使用，见图2。根据Jacobson的观点，用例是一个逻辑上相对完整的序列，只有保持其完整性，才有实际价值。同时UML扩展了用例的概念，用例不仅可以描述系统和子系统的外部行为，而且可以用来描述类的外部行为。从图2中可以发现用例图内部存在着三种关系：收费员与各个用例之间的关系，用例与用例之间的包含（Include）关系和扩展（Extends）关系，而正是靠这些关系去实现一个系统需求中的所有功能。3.2个需求分析静态模型是从系统的内部结构和静态角度来描述系统的视图，在整个需求分析中它定义了其中的对象和类，以及它们内部和彼此间的关系，如关联、聚合、依赖等关系，以及实体功能范围的约束和限定，最后建立系统粗略的静态模型，再逐步实现其内部详细的功能需求。3.2.1对象图的生成静态图（StaticDiagram）表示法，也就是系统需求分析的静态机制，包括类图（ClassDiagram）、对象图（ObjectDiagram）和包图（PackageDiagram）。在需求分析中类图描述系统中类与类之间的静态关系（在解决大系统问题时，常将许多类集合成一个更高层次的单位，形成一个高内聚、低耦合的类的集合），不仅定义类之间的联系，如关联、依赖、聚合等，也包括类的内部结构（类的属性和操作）；对象图是类的实例，几乎使用与类图完全相同的标识，其不同点在于对象图显示类的多个对象实例；包图由包或类组成，用于描述系统的分层结构。3.2.1.征费系统中的事务类道路征费系统软件开发项目，目的是建立一个道口征费后台管理的软件。整个系统包括道口收费机类（PC机）、中央服务器类（centralserver）、征费软件、以及有关的界面软件。征费软件的工作，是处理系统中道口收费机（PC机）和集控室中央服务器（centralserver）之间的事务（transaction），如上岗、登录、征费、打印、播音等。当然这些事务（transaction）的实现必须要求收费员（person）在对道口的收费机（PC机）输入正确的密码（password）和用户名（name）并成功登录后才能进行的，并完成与集控室中央服务器（centralserver）的交互，图3就是征费系统中的局部类图。用UML语言来描述图3的话，也就是把此事务看成两个类之间二元关联类，把收费员（person）类与收费机（PC机）类联系起来。其中属性有：password（号码），name（名字），location（地点），serialNumber（收费机序号），content（内容），日期（Date）等。相关的操作有：trx（代表一系列事务），类型包括时分秒的时间。3.2.1.设计并细化学习包的内容需求分析最高层设计是结构设计，UML此时的任务是定义包（也就是子系统），包括包间的依赖性和通信机制。当然从编程的角度来说，人们还是希望结构尽可能简单和清晰，各个包间的依赖关系也尽可能少，尽可能不用双向依赖。另一部分是详细设计，细化包的内容，使编程人员得到所有类的一个足够清晰的描述。图4给出了一种包的定义，注意，包实质上是类的集合。如果从需求分析的角度出发，用户接口包就是道路征费系统收费机（PC机）；而系统对象包是整个系统需求的核心，其给出开发一个对象模型所需的抽象和具体操作，为类的继承提供了依据；数据库包可以理解为征费站后台集控室的相关资料，包括道口征费每天的工作日志和预交过路费的记录，异常车辆监控等；包图中的实用包包含系统其他包要使用的服务。3.3状态图的记录对象的动态建模（dynamicmodeling），主要讲解对象间相互作用、消息的交换等，并主要以状态图（statediagram），序列图（sequencediagram）来记录。而高速公路征费系统本身又是客户机/服务器（client/server）模型和分布式对象（distributedobject）系统，它们系统内部各个对象间的通信完全可以用UML的动态机制加以描述。3.3.1转移的事件一个系统或对象，从产生到结束或从构造到清除，可以处于一系列不同的状态（state）中，状态图就是用来描述这一特定系统或对象所有可能状态（初态、终态、中间状态、复合状态）及其引起状态转移的事件，是对类图的补充。比如，在征费系统中，有一个事件，是帮用户办理汽车征费的月票（有的征费站是季票或年票）业务，这个事件就可以用状态图来描述。从图5的状态图看到，每个状态框中有两格，上格放置名称，下格说明处于该状态时，系统或对象要做的工作。状态之间发生的过渡事件，则在箭头旁边标明。可见，状态图总结了系统或对象所经历的状态，以及其间的过渡事件，这些过渡事件，通常与系统中的用例相呼应。例如，月票的用例有：买月票、月票卡充值、有余额等。当然，一个需求中可能有许多对象，人们无需给每个对象画状态图，而只要集中在可以体现整体系统的关键对象即可。3.3.2基于uml的对象序列序列图用来描述对象之间的动态的交互关系，其强调对象之间消息发送的顺序，同时显示对象之间的交互。顺序图中的消息可以是信号、操作调用等，当对象接收到消息后立即开始执行活动，也就是说该对象被激活了。其中的水平线表示不同的对象，垂直线表示时间，消息的箭头指明消息的类型（简单类型、同步类型、异步类型）。图6显示的是一个收费员登录过程，左上角的人形符号是道口收费员。带有<<client>>符号的是收费机（PC客户机），也是与收费员直接接触的机器。中央服务器（CentralServer），包括PCManager(PC管理器）和数据库（图中的小圆柱体）。右边的Information代表与征费系统联网的某一后台（例如集控室）服务器对象。整个图中含有两种客户机/服务器模型，即PC客户机/PC管理器，以及PC管理器/Information。PC客户机和Infor-mation都在中央服务器之外，其中PC客户机代表安装在收费机里的一个软件部件。PC管理器是中央服务器的主要对象。这种基于UML的对象序列图，是一种广泛地用于面向对象与组件的分布式和并发式系统交互需求设计的技术。在需求阶段，其直观性能帮助设计者直观地设计出软件系统组件的交互接口部件，帮助设计者将对组件交互序列的思考过程可视化地表现出来。4静态与动态建模方法的应用与评价综上所述，用户需求分析是软件工程中的一个重要阶段，其根本任务是确定系统必须具备的需求功能，包括目前尚不需要但今后可能要扩充的功能。基于UML的系统需求分析，可以帮助用户和分析人员对问题的描述和理解达到相同的理解，优点在于减少语义差异，使分析的正确性得到保障，而且UML的静态与动态建模机制还可以从系统的需求分析若干步