《面向对象分析案例银行储蓄系统》由会员分享，可在线阅读，更多相关《面向对象分析案例银行储蓄系统（82页珍藏版）》请在金锄头文库上搜索。
1、面向对象分析1 基本过程2 需求陈述3 建立对象模型4 建立动态模型5 建立功能模型6 定义服务1 面向对象分析的基本过程面向对象分析，就是抽取和整理用户 需求并建立问题域精确模型的过程。通常，面向对象分析过程从分析陈述 用户需求的文件开始；接下来，系统分析员应该深入理解用 户需求，抽象出目标系统的本质属性，并 用模型准确地表示出来。在面向对象建模的过程中，系统分析员必 须认真向领域专家学习。在面向对象建模的过程中，还应该仔细研 究以前针对相同的或类似的问题域进行面向对 象分析所得到的结果。由于面向对象分析结果 的稳定性和可重用性，这些结果在当前项目中 往往有许多是可以重用的。面向对象建模得到
2、的模型包含系统的3个 要素，即静态结构(对象模型)、交互次序(动 态模型)和数据变换(功能模型)。动态模型和 功能模型中都包含了对象模型中的操作(即服 务或方法)。 复杂问题（大型系统）的对象模型通常由下 述5个层次组成： 主题层、类与对象层、结构 层、属性层和服务层。3个子模型与5个层次复杂问题的对象模型的5个层次在概念上可以认为，面向对象分析大体上按 照下列顺序进行：寻找类与对象，识别结构， 识别主题，定义属性，建立动态模型，建立功 能模型，定义服务。通常，需求陈述的内容包括：问题范围 ，功能需求，性能需求，应用环境及假设条 件等。总之，需求陈述应该阐明“做什么”而 不是“怎样做”。它应该
3、描述用户的需求而不 是提出解决问题的方法。应该指出哪些是系 统必要的性质，哪些是任选的性质。2需求陈述2.1 书写要点对系统性能及系统与外界环境交互协议的描述 ，是合适的需求。此外，对采用的软件工程标准、模 块构造准则、将来可能做的扩充以及可维护性要求等 方面的描述，也都是适当的需求。系统分析员必须与用户及领域专家密切配合协同 工作，共同提炼和整理用户需求。在这个过程中，很 可能需要快速建立起原型系统，以便与用户更有效地 交流。2.2 ATM系统案例ATM系统某银行拟开发一个自动取款机系统，它是一个由 自动取款机、中央计算机、分行计算机及柜员终端组 成的网络系统。ATM和中央计算机由总行投资购
4、买。 总行拥有多台ATM，分别设在全市各主要街道上。分 行负责提供分行计算机和柜员终端。柜员终端设在分 行营业厅及分行下属的各个储蓄所内。该系统的软件 开发成本由各个分行分摊。银行柜员使用柜员终端处理储户提交的储蓄事务。 储户可以用现金或支票向自己拥有的某个账户内存款 或开新账户。储户也可以从自己的账户中取款。通常 ，一个储户可能拥有多个账户。柜员负责把储户提交 的存款或取款事务输进柜员终端，接收储户交来的现 金或支票，或付给储户现金。柜员终端与相应的分行计算机通信，分行 计算机具体处理针对某个账户的事务并且维护 账户。拥有银行账户的储户有权申请领取现金兑 换卡。使用现金兑换卡可以通过ATM访
5、问自 己的账户。目前仅限于用现金兑换卡在ATM 上提取现金(即取款)，或查询有关自己账户的 信息(例如，某个指定账户上的余额)。所谓现金兑换卡就是一张特制的磁卡，上 面有分行代码和卡号。分行代码惟一标识总行 下属的一个分行，卡号确定了这张卡可以访问 哪些账户。通常，一张卡可以访问储户的若干 个账户，但是不一定能访问这个储户的全部账 户。每张现金兑换卡仅属于一个储户所有，但 是，同一张卡可能有多个副本，因此，必须考 虑同时在若干台ATM上使用同样的现金兑换 卡的可能性。也就是说，系统应该能够处理并 发的访问。当用户把现金兑换卡插入ATM之后，ATM就与 用户交互，以获取有关这次事务的信息，并与中
6、央 计算机交换关于事务的信息。首先，ATM要求用户 输入密码，接下来ATM把从这张卡上读到的信息以 及用户输入的密码传给中央计算机，请求中央计算 机核对这些信息并处理这次事务。中央计算机根据 卡上的分行代码确定这次事务与分行的对应关系， 并且委托相应的分行计算机验证用户密码。如果用 户输入的密码是正确的，ATM就要求用户选择事务 类型(取款、查询等)。当用户选择取款时，ATM请 求用户输入取款额。最后，ATM从现金出口吐出现 金，并且打印出账单交给用户。3 建立对象模型3.1 确定类与对象1. 找出候选的类与对象对象是对问题域中有意义的事物的抽象，它 们既可能是物理实体，也可能是抽象概念。 具
7、体地说，大多数客观事物可分为下述5类：(1) 可感知的物理实体，例如，飞机、汽车、书、 房屋等等。 (2) 人或组织的角色，例如，医生、教师、雇主、 雇员、计算机系、财务处等等。 (3) 应该记忆的事件，例如，飞行、演出、访问、 交通事故等等。 (4) 两个或多个对象的相互作用，通常具有交易或 接触的性质，例如，购买、纳税、结婚等等。 (5) 需要说明的概念，例如，政策、保险政策、版 权法等等。 在分析所面临的问题时，可以参照上列5类常见事 物，找出在当前问题域中的候选类与对象。非正式分析：这种分析方法以用自然语言书写 的需求陈述为依据，把陈述中的名词作为类与 对象的候选者，用形容词作为确定属
8、性的线索 ，把动词作为服务(操作)的候选者。 下面以ATM系统为例，可以把它们作为类与对 象的初步的候选者： 银行，自动取款机(ATM)，系统，中央计算机 ，分行计算机，柜员终端，网络，总行，分行 ，软件，成本，市，街道，营业厅，储蓄所， 柜员，储户，现金，支票，账户，事务，现金 兑换卡，余额，磁卡，分行代码，卡号，用户 ，副本，信息，密码，类型，取款额，账单， 访问。通常，在需求陈述中不会一个不漏地写出 问题域中所有有关的类与对象，因此，分析员 应该根据领域知识或常识进一步把隐含的类与 对象提取出来。例如，在ATM系统的需求陈述 中虽然没写“通信链路”和“事务日志”，但是， 根据领域知识和常
9、识可以知道，在ATM系统中 应该包含这两个实体。2. 筛选出正确的类与对象筛选时主要依据下列标准，删除不正确或 不必要的类与对象：(1) 冗余如果两个类表达了同样的信息，则应该保留在 此问题域中最富于描述力的名称。以ATM系统为例，上面用非正式分析法得出了 34个候选的类，其中储户与用户，现金兑换卡与 磁卡及副本分别描述了相同的两类信息，因此， 应该去掉“用户”、“磁卡”、“副本”等冗余的类，仅 保留“储户”和“现金兑换卡”这两个类。(2) 无关现实世界中存在许多对象，不能把它们都纳入到 系统中去，仅需要把与本问题密切相关的类与对象放 进目标系统中。有些类在其他问题中可能很重要，但 与当前要解
10、决的问题无关，同样也应该把它们删掉。以ATM系统为例，这个系统并不处理分摊软件开 发成本的问题，而且ATM和柜员终端放置的地点与 本软件的关系也不大。因此，应该去掉候选类“成本” 、“市”、“街道”、“营业厅”和“储蓄所”。(3) 笼统在需求陈述中常常使用一些笼统的、泛指的名词 ，虽然在初步分析时把它们作为候选的类与对象列出 来了，但是，要么系统无须记忆有关它们的信息，要 么在需求陈述中有更明确更具体的名词对应它们所暗 示的事务，因此，通常把这些笼统的或模糊的类去掉 。 以ATM系统为例，“银行”实际指总行或分行，“访 问”在这里实际指事务，“信息”的具体内容在需求陈 述中随后就指明了。此外还
11、有一些笼统含糊的名词。 总之，在本例中应该去掉“银行”、“网络”、“系统”、 “软件”、“信息”、“访问”等候选类。(4) 属性在需求陈述中有些名词实际上描述的是其他对象的 属性，应该把这些名词从候选类与对象中去掉。当然 ，如果某个性质具有很强的独立性，则应把它作为类 而不是作为属性。在ATM系统的例子中，“现金”、“支票”、“取款额 ”、“账单”、“余额”、“分行代码”、“卡号”、“密码”、 “类型”等，实际上都应该作为属性对待。(5) 操作在需求陈述中有时可能使用一些既可作为名词，又 可作为动词的词，应该慎重考虑它们在本问题中的含 义，以便正确地决定把它们作为类还是作为类中定义 的操作。例
12、如，谈到电话时通常把“拨号”当作动词，当构造 电话模型时确实应该把它作为一个操作，而不是一个 类。但是，在开发电话的自动记账系统时，“拨号”需 要有自己的属性(例如日期、时间、受话地点等)，因 此应该把它作为一个类。总之，本身具有属性需独立 存在的操作，应该作为类与对象。(6) 实现在分析阶段不应该过早地考虑怎样实现目标系统。 因此，应该去掉仅和实现有关的候选的类与对象。在 设计和实现阶段，这些类与对象可能是重要的，但在 分析阶段过早地考虑它们反而会分散我们的注意力。在ATM系统的例子中，“事务日志”无非是对一系 列事务的记录，它的确切表示方式是面向对象设计的 议题；“通信链路”在逻辑上是一种
13、联系，在系统实现 时它是关联类的物理实现。总之，应该暂时去掉 “事 务日志”和“通信链路”这两个类，在设计或实现时再考 虑它们。在ATM系统的例子中，经过初步筛选， 剩下下列类与对象：ATM、中央计算机、 分行计算机、柜员终端、总行、分行、柜 员、储户、账户、事务、现金兑换卡。3.2 确定关联1. 初步确定关联在需求陈述中使用的描述性动词或动词词组， 通常表示关联关系。因此，在初步确定关联时，大 多数关联可以通过直接提取需求陈述中的动词词组 而得出。通过分析需求陈述，还能发现一些在陈述 中隐含的关联。最后，分析员还应该与用户及领域 专家讨论问题域实体间的相互依赖、相互作用关系 ，根据领域知识再
14、进一步补充一些关联。 以ATM系统为例，经过分析初步确定出下列关联 ：(1) 直接提取动词短语得出的关联 ATM、中央计算机、分行计算机及柜员终端组成 网络。 总行拥有多台ATM。 ATM设在主要街道上。 分行提供分行计算机和柜员终端。 柜员终端设在分行营业厅及储蓄所内。 分行分摊软件开发成本。 储户拥有账户。 分行计算机处理针对账户的事务。 分行计算机维护账户。柜员终端与分行计算机通信。 柜员输入针对账户的事务。 ATM与中央计算机交换关于事务的信息。 中央计算机确定事务与分行的对应关系。 ATM读现金兑换卡。 ATM与用户交互。 ATM吐出现金。 ATM打印账单。 系统处理并发的访问。(2
15、) 需求陈述中隐含的关联 总行由各个分行组成。 分行保管账户。 总行拥有中央计算机。 系统维护事务日志。 系统提供必要的安全性。 储户拥有现金兑换卡。 (3) 根据问题域知识得出的关联 现金兑换卡访问账户。 分行雇用柜员。2. 筛选 (1) 已删去的类之间的关联如果在分析确定类与对象的过程中已经删掉了某个 候选类，则与这个类有关的关联也应该删去，或用其 他类重新表达这个关联。以ATM系统为例，由于已经删去了“系统”、“网络” 、“市”、“街道”、“成本”、“软件”、“事务日志”、“现 金”、“营业厅”、“储蓄所”、“账单”等候选类，因此， 与这些类有关的下列8个关联也应该删去： ATM、中央计
16、算机、分行计算机及柜员 终 端组成网络。 ATM设在主要街道上。 分行分摊软件开发成本。 系统提供必要的安全性。 系统维护事务日志。 ATM吐出现金。 ATM打印账单。 柜员终端设在分行营业厅及储蓄所内。(2) 与问题无关的或应在实现阶段考虑的关联应该把处在本问题域之外的关联或与实现密切相 关的关联删去。例如，在ATM系统的例子中，“系统处理并发的 访问”并没有标明对象之间的新关联，它只不过提醒 我们在实现阶段需要使用实现并发访问的算法，以处 理并发事务。删掉： 系统处理并发的访问(3) 瞬时事件关联应该描述问题域的静态结构，而不应该是一个 瞬时事件。以ATM系统为例，“ATM读现金兑换卡”描述了 ATM与用户交互周期中的一个动作，它并不是ATM与 现金兑换卡之间的固有关系，因此应该删去。类似地 ，还应该删去“ATM与用户交互”这个候选的关联。 如果用动作表述的需求隐含了问题域的某种基本结构 ，则应该用适当的动词词组重新表示这个关联。例如 ，在ATM系统的需求陈
