信息系统分析与设计之面向对象建模

Entity Class (实体类): 实体类):
表示系统保存的信息 Note:在UML里面,Boundary 与 Interface 意义不同. : 里面, 意义不同. 里面 Interface 指一组操作(方法) 指一组操作(方法) Boundary 指系统的边界,指的是"类" 指系统的边界,指的是"
思考"销售管理"和"查询商品信息",找出 可加入的类:
消费者 店员 商品 发票 发票明细 成分 便利店
在"销售管理"里面,除了"成分"外,其余类皆会用 到.
图 Logical View/StoreClass1
发票 invoiceNO 1 Consumer
(from Ex02_Store)
发票 明细 n 1 1
商品 barcode goodsName price unit 0..n
age Gender 0..n 成分 nutritionID nutritionName unit
n 店员
(from Ex02_Store)
1
便利 店 storeID storeName startDate
以上每一种类均可对应到三层结构中的每一层
BCE分类与三层结构类似
三层结构下,会有三种类库: Us来自百度文库r Services:包含所有的边界类 Business Services:包含所有的控制 类 Data Services:包含所有的实体类
图 Logical/main
6.1 UML
Business Services Data Services
例:便利店购物流程
觉得好渴,进入便利店逛逛; 顺便翻翻架上的杂志; 到饮料柜,选了一罐可乐; 到柜台付账; 拉开拉环看有没有中奖,没中奖觉得好失望; 喝可乐,舒服!
如何做这个便利店管理信息系统?
传统的系统分析方式一看就知道要分析的是付账,扣除库存那一段流程.因此比较资深 的系统分析员就会想象出这样的画面:
面向对象与Use Case
未引入"Use Case"时,要找出软件系统的对象多半是个 人自凭本事.通过Use Case的分析,终于使软件系统的 对象寻找机制有了一定的参照标准.
Use Case:
由系统所执行的一连串操作顺序,其结果会对 特定的"Actor"产生可观察的结果值. 传统系统分析主要以"面向功能"的方式针对 系统的功能说明系统需求. Use Case分析则是先定义处系统的边界,将系 统范围理清楚,再通过后续的顺序图,类图找出 相关的对象,Interface或组件.
User Services
An alysis Mode l (from User Services)
Design Model (from User Services)
UML讲究的是以"交互式","渐进式"的方法作 分析,雏形出来之后,可以根据各种需要一步一步 进行分析修订. 目前Rational Rose已经和面向系统分析划上等号, 但进行OO分析为何会有正反两派不同意见?
Boundary Class(边界类): (边界类):
表示系统外部环境与内部运作之间交互的类 (系统与系统之间,人与系统之间,某个类于系统之间 系统与系统之间, 系统与系统之间 人与系统之间,某个类于系统之间)
Control Class (控制类): 控制类):
表示一个或多个Use Case 行为的类 表示一个或多个
Boundary Class, ――客户端,用户界面 Control Class Entity,――中间层:组件 Entity Class,――数据库端
Use Case Case运作机制
Use Case的范围(例如:进,销,存) Actor 异常事件流
通过这三者的相互运作以及精确分析,才可以规划出一套 信息系统的需求.光这样还不够,新手与老手所规划的Use Case 可能有所不同.
找出Use Case
就Actor而言,必须与所要分析的系统产生 交互 就Use Case而言,必须对特定Actor产生可 观察的结果值
图(候选Use Case)Store2
1.感觉到渴
4.付款
2.翻看杂志
5.打开可乐
3.挑选可乐
6.感觉舒服
原则上是不编号的 命名规则:动词+名词 命名规则:动词 名词
也可以根据Use Case说明书中的叙述,简单制作 相关的类.不要太贪心,一次加一堆类,或者一 次加很多属性,操作. 寻找Use Case名,说明书中比较重要的名词 不属于这个阶段该加入的类,勿强行加入.比如 某些控制类,因为以后自然会找出来. 针对Use Case的范围适当加入类. 加入类时,如该类已存在,则检讨该类是否恰当, 或者酌量加入新的属性及操作.
UML与面向对象分析
6.1 面向对象
面向程序 面向数据 面向对象 面向对象技术一定成功?
理论上是成功的,但需要实践上的配合.
面向对象开发软件的优点:
程序更容易重复使用 程序更容易测试 程序更容易维护 – 将程序分门别类,各司其 职
面向对象的缺点:
面向对象语言门槛较高 面向对象系统分析难度高 面向对象系统分析与设计所需的时间较长
图Store3
1.感觉到渴 5.打开可乐
顾客 2.翻 看杂志 6.感觉舒服
3.挑选可乐
4.付款
店员
总帐系统 库存管理系统
细线箭头代表与Use Case交互的方向,箭头来源 为输入端,目的为输出端.若不清楚输入输出, 可暂时不加. -泛化关系 ,与情境 – 都是可行的 (刷卡机与 收银机是否分离) 问题:光找出Use Case就可以写出程序了吗?就 有对象了吗?
外部系统
与此系统交互的其他系统,可以先采用假定的方式,说 不定分析到后面发现它也是本系统的一个子系统. 以付账,扣库存的角度来看,可能有
总帐系统 库存管理系统
这样分析出4个Actor
消费者 店员 总帐系统 库存管理系统
图Store0
顾客
总帐系统
店员
库 存管 理 系统
情境(Scenario):一连串的操作顺序
图Store7
下订单
店员
分销商
温度传感器
下建议订单
Store8
店员
进货管理
分销商
进货管理
6.3,Use Case 高级分析技巧
Use Case 说明书
与传统软件开发过程中惯用的"需求说明书"相比,是 类似的,都是要与用户确认的文件. 就概念上而言,用户的一项需求经过分析之后,可能会 是好几个Use Case. 在"说明"栏,指出使用时机,该操作何时执行,包括 涉及到用户之间的权限区分. 在进行Use Case分析时,最怕遇到明显的AUDI类型的操 作.以传统眼光来看,一般的Use Case均是新增,修改, 删除或查询交相混杂的.而目前的系统分析人员都是由 传统系统分析起家的,因此着手的角度很容易受到AUDI 的限制,所分析出来的Use Case就会失去对象的精神. 基本事件流 与 传统 的 操作流程类似.但是"流程图" 无法与后续文档或其他图形之间相互修改.
图Store6
Consumer age Gend er 库存管理系统
销售管理
总帐系统
店员
Use Case 与对象
前面已经在消费者下添加了两个属性,下面继续在"销 售管理"中查找其他对象
在Rational Rose中发现和定义对象:
将Actor 加入Logic View Actor Logic 根据Use Case,一个一个想象可选用的对象,这些候选 对象,将来可能是对象,也可能不是对象. 从顺序图中加入对象,也可将既有的对象加入顺序图. 根据Boundary Class,Control Class以及 Entity Class的概 念找出对象,其中Control Class在顺序图中比较容易出现, 要一边画顺序图,一边找对象.
问题:一个生手如何开始分析?
利用 Use Case 与Actor的方式,对流程进行分 析,而且后续可以针对Use Case找出相关的对象 与类 找出人为的Actor:
消费者 店员 翻看杂志的路人甲:如果未购买则与本系统无关,若 有购买,则也是消费者 店长:管理便利店资源.未发现与本系统有交互.若 店长值班,则也是店员.
查询商品信息:提供客户进行商品查询 销售商品:提供店家进行商品销售管理
程序 是根据功能得出来的,Use Case则是发展分析 而来的.
以"销售商品"子系统而言,可以具有以下的功能: 销售商品-〉 折扣 退回 变价 组合商品 批发 子菜单各为一个程序.而Use Case却不同,绝无所谓的 程序概念,只有"对象"或组件的概念,甚至在高层次 的分析阶段,连"对象"与"组件"都看不到,除了Use Case与Actor,什么都没有.
运用Use Case的目的在于合理订出系统的需求及 范围,以免后来徒劳无功
图Store4
顾客 查询商品信息 库存管理系统
销售商品
总帐系统 店员 现金付款 信用卡付款
Use Case与程序
图store4 目前仅发展到查询商品信息和销售商品两项,功 能有限,实在不宜称为"便利店"Total Solution. 我们需要明确定出现有Use Case的范围与功能, 其它功能将在后续分析中完成.
OO分析采用"交互式","渐进式"的开发方法,也就 是分析一点,设计一点,修改一点,再分析,再设计, 然后再修改,其目的为使整套系统的模型更加完整,清 晰.因此分析设计阶段会拉长.由此缺点,某些软件公 司认为前置时间比较长,成本较高,但实际上前面做的 好,可以省下后续程序设计,测试以及维护的时间,事 实上反而比较省成本.
软件系统的开发阶段:
需求分析阶段 系统分析阶段 系统设计阶段 程序设计阶段 测试阶段 安装阶段
向对象技术可以省掉的是后段的时间与成本,包括程序设 计,测试与维护都可以节省相当可观的成本.但前段时间 与成本要增加许多.
在类设计上,依据 在类设计上,依据RUP(Rational Unified Process) ( ) 的设计理念,一般会先找出三种类: 的设计理念,一般会先找出三种类:
由于对象里面一定包含有"操作" 由于对象里面一定包含有"操作"和"属性",Use Case中的动词 属性" 中的动词 部分,将来可以作为对象中的操作, 部分,将来可以作为对象中的操作,名词部分可以作为对象中的 属性" "属性" Actor与 将Actor与Use Case 联系起来
记账" 扣除库存" 分析 Use Case 4,是有用的,与"记账","扣除库存"有关 ,是有用的, 分析1, , ,产生的是心理作用,不符合"可观察的结果值" 分析 ,5,6,产生的是心理作用,不符合"可观察的结果值", 去掉 检讨2, 检讨 ,3 若仅是购买饮料的流程看, , 是与电脑系统无关的 是与电脑系统无关的. 若仅是购买饮料的流程看,2,3是与电脑系统无关的.但若考虑到 Total Solution,则是有意义的 ,
一个Use Case里面可能有相当多的操作,以不 同的顺序进行,每一串操作顺序都可以情境. 以"买饮料"的流程看,现金购买是一种情境, 刷卡购买也是一种情境.刷偷来的卡被逮到,也 是一种情境.
Use Case的情境分为三种:
主事件流(Main Flow) 其它事件流(Alternative Flow) 异常事件流(Exceptional Flow)
6.2 Use Case
以UML进行面向对象分析都非常偏重于Use Case的 分析.
在传统的软件开发过程中,流程图时最重要的,而在新 一代面向对象系统分析领域,Use Case则占了60%以上. 过去评估软件开发的成本时,常会以系统的功能数乘上 所需人数,再乘以系统分析人员,系统设计人员的成本, 或以程序的个数乘上程序设计人员的成本. 而在面向对象技术里,习惯以Use Case的数目乘以开发 的周期数(Iterations),再乘以每一周期的开发成本.
另外,从消费者的角度进行分析,消费者指向 "销售商品"也是不合理的(消费者哪里需要输 入什么数据?都是店家输入的),故销售商品应 改由店员的角度进行分析.
图Store5
Note: 原来消费者-〉销售商品的线,改成由 销售管理-〉消费者了.这是有意义的
图Store5
查询价格 查询成分
库存管 理系统 顾客 查询商品信息
销售管理
总帐系 统
店员 折 扣销售 网 上销售 商 品预售
发现销售管理-〉消费者的秘密了吗? 第二个特殊要求; Sell Goods要印出发票给消费者.
但是Sell Goods(销售管理)只是计算机,所以以上工作要由店 员来做.
修改图:
图Store6
-顺便画出了消费者的属性,强调消费者将被设计为一 个对象 -销售管理-〉消费者的虚线,"相关关系",表示销 售管理要向消费者要数据 -没有"打印发票",因为国家规定销货一定要打印发 票,所以包含在销售管理的流程里面了