书城计算机网络综合应用软件设计
8724600000013

第13章 软件需求分析(3)

3.4面向对象的方法(OOA)

3.4.1概述

面向对象方法是从对象的角度对系统进行分析和设计,它与传统的从功能和信息(数据)的角度对系统进行分析和设计的结构化方法和信息建模方法有着本质的区别。传统方法忽略了数据与程序之间不可分割的内在联系,而面向对象的方法能将数据和功能紧密的结合在一起,使开发出来的系统稳定性、可重用性及可维护性好。

不论采用结构化的方法还是面向对象的方法开发软件,软件产品建造的第一步就是进行需求分析:系统分析员通过与用户及领域专家的充分交流,力求完全理解用户需求和该领域中的关键性的背景知识,并用某种无二义的方式把这种理解表达成文档资料。需求可以用非形式的文本来表达,或者用形式化的文本表达,还可以用形式化程度位于此次两者之间的任意的方式来表达。

面向对象方法支持3种基本的活动:识别对象和类、描述对象和类之间的关系,以及通过描述每个类的功能定义对象的行为。什么是对象?所有的东西——包括物体、事物、活动、关系以及由它们组成的混合体,都可以看成对象。面向对象的建模,把系统分解成相互协作的对象,由定义良好的类来表达。

3.4.2UML分析设计实例

统一建模语言(Unified Modeling Language,UML)是一种通用的可视化建模语言,用于对软件进行描述、可视化处理、构造和建立软件系统的文档。

以一个具体案例为线索,采用UML/OO/UP的新技术,完成需求—建模—序列图—类图的建模过程。从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;其次根据需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为。其中在第一步与第二步中所建立的模型都是静态的,包括类图(包含包)、对象图、组件图和分布图等4个图形是标准建模语言UML的静态建模机制。第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。它包括用例图、状态图、活动图、时序图和协作图等5个图形是标准建模语言UML的动态建模机制。因此,标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。

1.需求分析

软件产品建造的第一步就是进行需求分析,根据用户对产品功能的期望,提取出产品外部功能的描述。从软件产品使用者的角度而不是开发者的角度,描述用户对待开发产品的需求,分析产品所需的功能和动态行为。对软件产品的需求分析就是定义软件系统的边界,包括两个方面的内容。

①分析软件产品与外界的联系。

②确定软件产品与外界的联系时包含动态行为及其相互关系。

在UML中,通常用支持产品外部功能描述的视图用例图来描述。

例子:通过用例描述软件系统的功能。

假定设计开发一个具有基本功能的ATM机软件:

客户可以存钱,取钱

客户可以查询余额

客户可以修改密码

客户可以使用信用卡付账

分析:需求分析的第一步是确定系统能够做什么?谁来使用这个系统?

用例图显示用例(表示系统功能)与角色(表示提供或者接收系统信息的人或系统)之间的交互。用户、项目管理员、分析人员、开发人员、质保人员都可以通过用例图来了解系统功能。

2.分析抽象用例

分析抽象用例时应从软件产品使用者的角度,而不是开发者的角度去描述开发产品的用例。UML是由系统的参与者和分析抽象的用例这两部分元素所组成。

首先,分析软件产品与外界的联系,识别出系统的参与者(代表位于系统之外并和系统进行交互的一类对象)。在任何系统中,会有一些事物存在于系统的内部,一些事物存在于系统的外部。例如该例中,账户、事物处理、验证密码都存在于系统内部,而客户、信用系统存在于系统外部并与系统有着交互。把这些存在于系统外部,并与系统有着交互行为的事物抽象出来作为参与者。系统的参与者除了可以代表作为人的软件使用者(如客户)之外,还可以代表直接和软件系统交互的软件系统赖以运行的软/硬件平台,以及与软件系统有信息交换的计算机外部设备(如信用系统)。

在指定系统参与者以后,需要详细描述系统参与者和软件系统交互的具体内容,抽象出用例(代表系统为响应系统参与者引发的一个事件而执行的一系列处理,而且这处理应该为系统作用者产生一种可见的价值)。一个用例代表系统作用者和系统的一次交互,用例的设置,就代表了软件系统的功能划分,因此必须仔细考虑每个用例代表的动态行为的内容,使得每个用例都能产生一个有价值的结果,而且使得功能的分布较为均衡、易于理解、易于使用。例如该例中存钱、取钱、付款、查询余额、改变密码。

3.画用例图

4.用例描述

用例是描述一个系统(或一个子系统)做什么,而不是说明怎么做。

1)分析角色

角色是指系统用户,与本系统交互的其他系统。

2)建立事件流

事件流的目的是建档使用案例中的逻辑流程,详细描述系统的工作。分主事件流(Main Flow of Events)和次事件流(Alternative Flow of Events),用来区分对系统功能的合法使用和非法使用。在描绘事件流时,必须用足够清晰的语言以使得一个普通的用户能够理解。

例:用例“取钱”

角色:客户

事件流:客户可以从ATM机上取出自己账目上的部分或者全部存款。

前提条件:

⑴主事件流:客户将卡插入ATM机,开始用例。

⑵ATM显示欢迎消息并提示客户输入密码。

⑶客户输入密码。

⑷ATM确认密码有效。如果无效则执行其他事件流A1。如果与主机连接有问题,则执行异常事件流E1。

⑸ATM提供以下选项:存钱,取钱,查询。

⑹用户选择取钱选项。

⑺ATM提示输入所取金额。

⑻用户输入所取金额。

⑼ATM确定该账户是否有足够的金额。如果余额不够,则执行A2,如果与主机连接有问题,则执行异常事件流E1。

⑽ATM从客户账户中减去所取金额。

⑾ATM向客户提供要取的钱。

⑿ATM打印清单。

⒀ATM退出客户的卡,用例结束。其他事件流A1:输入无效密码。

⒁ATM告诉客户该密码错误。

⒂ATM退出客户的卡,用例结束。其他事件流A2:余额不足。

⒃ATM告诉客户该账户余额不足。

⒄ATM退出客户的卡,用例结束。异常事件流E1:连接主机出现错误

⒅ATM告诉客户连接主机出现错误。

⒆ATM在错误日志记下错误。

⒇ATM退出客户的卡,用例结束。事后条件:无。