面向对象需求分析实例_200910
面向对象需求分析——用例图和活动图【优质】
面向对象需求分析——用例图和活动图面向对象软件开发的方法有：a，面向对象分析（OOA）b,面向对象设计(OOD）c,面向对象实现（00I）d，面向对象测试（OOT）,e，面向对象维护（OOM）这几个主要大步骤。
下边我们就从面向对象的角度来学习UML的相关图。
这里介绍面向对象分析阶段的用例图和活动图。
面向对象分析阶段，我们要明确系统的职责，范围和边界；确定软件的功能和性能；构建需求模型（用例模型）。
首先在这里说一下，为什么将这两个图放在一起，主要原因就是活动图的一个目的是更细致的描述用例图，和文档的配合使用，使用例图更加清楚明了。
先介绍一下：用例图1，概念：用例是系统的一个功能单元，是对用户需求的描述。
2，组成：参与者，用例及其之间的关系（包括关联关系，泛化关系，包含关系，扩展关系）：3，用例建模的步骤：a,确定系统的范围和边界；b,确定系统的用例和参与者；c,描述用例；d，对用例分类，并确定用例之间的关系；e,建立用例图，并定义用例图的层次结构；f,评审用例模型。
下边我们看个例子：这是一个教务管理系统的总用例图和一个子一级用例图，当然还可以再分：在上述6个步骤中，我简单总结一下：a,系统边界，就是一个系统内部所有元素与系统外部事物的分界线。
b,用例和参与者，需要我们根基实际情况去抽象。
c,描述用例，这个我重点写一下（举例，选课注册）：用例编号：0101用例名称：选课注册执行者：学生功能：实现学生选课注册的过程类型：主要用例，基本用例级别：一级过程描述：1，学生输入系统账号和密码，系统进行验证；2，查询课程信息3，查询个人选课信息4，若可以选课，则进行选课注册，并将选课信息写入数据库中5，返回选课注册是否成功异常事件流处理：1，学生的账号和密码错误，允许重新输入（3次）2，学生未按时交纳学费，不可选课3，学生人数已达到上限，不可选课。
（当然在这里在把下边的活动图，添加进来即可）d,用例分类和确定之间的关系，有端点用例，基本用例，主要用例，辅助用例等，关系弄准确就可以。
面向对象分析实例
4
学生ID 自选习题,
5
习题解答 核对答案
练习本类的属性和方法
确定对象类
属性: 方法:
01
习题号 编写习题,
02
题目内容 编写答案,
03
答案 习题入库
04
所属课程
02
筛选对象原则:
发现对象
2
3
从需求中找名词作为侯选对象:
教师,系统,习题,答案,作业,时间,学生,试题,系统管理员,权限,学校,班,学期,课程,习题板,考试板,练习本,习题库.
共18项
具体做法:
发现对象
系统:太大的抽象,不能作为对象.
时间:只有考试板要求,可作为考试板属性处理.
作业:是习题的同义词,可舍弃.
系统需求说明按三方面描述:
01
系统问题域说明:应用系统的业务范围
02
系统边界说明:确定系统与用户之间接口
03
系统功能说明:系统需要实现的责任
04
实例描述:习题管理系统
对象
系统问题域说明:
在一个公共习题库的支持下, 负责各科习题的教师: 可用系统编写习题及答案,并存入习题库; 从习题库中选择一组习题去组成作业,并在要求时间公布习题答案; 从习题库中选择一组习题组成考试题公布; 可以批改学生的作业; 学生答题后收卷,阅卷评分.
用系统完成作业或答题并提交给系统; 可在习题库中选择习题自己练习; 可以在公布答案后核对自己的作业;
每个学生:
负责习题,编班和权限管理和维护习题库.
一名系统管理员:
壹
贰
系统问题域说明:
系统的用户有本校教师,学生,系统管理员.
学校以班组织学生,每班每学期有若干课程.
面向对象的需求分析
第六章 面向对象的需求分析
2. 用例建模
定义
识别 确
定建
立书
写
系统边界 确 定 用 例 用例间关系 完整用例图 用例描述文档
参与者
举例： 对于大家都非常熟悉的自动取款机（ATM）系统来说，它 的主要参与者有哪些呢？
首先 银行卡用户要通过ATM取款、查询、转账
其次 银行营业部金融系统要和ATM系统交互使 ATM能够获得有关帐户信息并进行账目数 据操作
二是分割了各项系统功能的应用环境，从各项功能项入手 很难了解这些功能如何相互关联实现一个系统服务。
CHENLI
4
回目录
第六章 面向对象的需求分析
2. 用例建模
用例建模——使用用例的方法来描述系统需求的过程。 ❖ 使用 用例图 给出系统的总体功能需求 ❖ 使用 用例描述 说明每个用例的业务规则、用户系统交换序列 ❖ 最终成果是完整准确的系统用例图和详细的用例描述文档
确定系统边界，即定义系统的范围，哪些功能是系统应该实现的，
哪些不是系统应该做的，明确系统目标范围。例如，对于银联网络
的自动取款机网络系统来说，其系统边界范围就是和自动取款机相
关的功能，如用户通过自动取款机取款、查询帐系统户、转账等，以及
银联网络中各个银行之间的帐务结算，而对于各个用银例1的注行释 内部的各营 用例1
❖ 完整的、与用户真正需求一致的用户需求描述，说明用户使用 该系统完成的任务
❖ 用户对系统非功能性需求要列举清楚，例如系统界面要求，性
能要求及系统可靠性要求等CHENLI
3
第六章 面向对象的需求分析
1. 需求分析简介
建议采用 用例(Use Case) 描述系统需求
通过描述用户使用系统的过程，体现系
一个完整的面向对象分析与设计例子
一个完整的面向对象分析与设计例子首先说明,接下来这部分内容,跟面向对象没什么关系,只是描述出我们接下来"需要做什么".大家都知道电梯是怎么回事了,所以获取需求的过程我就不啰嗦了,直接把最后结果描述出来.(对于计算机专业学生或软件工程毕业设计的需求分析结果应该有些参考意义...起码可以看出怎么样的结果才真正有意义)电梯楼层1-10 楼(也就是没有什么地下室也没有中间跳过某些楼层,最普通的情况),一共有2部电梯.如果一个在n楼(1 <n <10)的乘客按了下行按钮,那么下一个正在向下走的电梯到了n楼必须停下接收乘客.如果电梯里已经没有乘客了,电梯应该留在原位置直到再次投入使用.在将乘客送到目的地以前电梯不允许反向运动.(也就是电梯比如把乘客从9楼带到楼下,如果在走到4楼的时候5楼有人要下,电梯不能从4楼回5楼去,而要把乘客带到楼下再回来)满载的电梯不再收人.电梯里有个按钮面版,里面有10个楼层的按钮. 按下按钮表示该楼层变成一个目的地,按钮会发光,到达以后按钮不再发光.建筑物2-9楼层有一个按钮面版,上面两个按钮分别是向上和向下.1楼只有向上,10楼只有向下.电梯有一个控制中心来自动控制,不用人手干预. ...............(其他,略)第二部分到底上面的需求描述中,哪些东西可以成为我需要来"面向"的"对象"?首先,我们要选择出候选的对象,然后再在候选对象里选择真正为程序设计所使用的对象.候选对象的选择有很多方式,比方说"名词短语频率分析",对上面那段去分析看哪些名词出现次数很多,说明可能比较重要,可以直接拿来当候选对象. 比如楼层,电梯,按钮,乘客,都出现很多次. 当然还有另外的方式,比如"按方面建立" (PS: I 'm sorry,我是个实用主义者,只要目的达到了...我不喜欢像一些书本上那样用些概念糊弄人,上面红字的两个方法的名称是我临时取的.....也许不好听,也许他们有更优美的名字.....反正这不是我们该担心的,留给教材编写人员取操心吧...) 从人\组织\设备\物品\业务\事件\表格几个方面去找对象去.这里要注意的是对象的选择要看具体情况的,比如 .... 我们把"放飞希望" 作为一个具体的对象实例( ^_^ ), 如果在医疗系统中,可以抽象成"人" 这个类,由脑袋\身体\手\脚......等部分. 如果是在教育管理系统中, 就不能这么处理,可能要抽象成"老师" 这个类, 包括教学年限\工资\所教科目\..... 等内容.还有一点需要注意的是不要跨过系统边界. 系统之外的事情就不要管了,就说我们这个电梯调度, 电梯的生产日期啊什么的,还有乘客的姓名, 都根本雨系统无关,这些是不需要的.最后有一点被非常非常非常非常非常多的工程师们所忽视的就是建立面向对象分析模型的时候, 只应该考虑逻辑,而不要去考虑跟实现技术相关的东西. 比如按钮是塑料的还是金属的, (当然这个很明显是分外的事,大多数人在做调度分析的时候不会考虑这个,不过有些情况却很隐蔽..)现在回到我们具体问题,假设现在我们列出来的初步的清单是这样的(可能100个人有100个列法,不过没关系,这是正常的...): 电梯\电梯门\电梯位置\乘客\目的地按钮\大楼.....这离真正可以用的对象还差很多, 我们需要对每个词进行分析,看看到底是不是,值得不值得把这个当一个对象来考虑.我们分析从以下几个方面看:它在系统里有功能吗? (比如电梯天花板就该删除掉....如果有的话....)其他对象需要这个对象帮忙做点什么事吗? (比如乘客需要电梯把他带上去...)其他对象需要这个对象的数据吗?(比如控制中心明显需要知道电梯现在在哪..)这个对象是不是包含了有用却不对别的对象公开的内容.(比如电梯上面的吊链和发动机明显是有用的,不然电梯无法动也就无法调度了, 但是明显对于其他对象,都是不需要公开的, 不管是乘客还是控制中心都不需要控制电梯的马达---这里可能有人要有意见了, 控制中心不控制电梯马达么? 答案是不该控制,控制中心应该只告诉电梯你要向上还是向下还是停, 至于马达转多快怎么转,是电梯自己的电路来控制的才对, 责任分开明确有利于系统的维护.)这个对象有没有一个生存期,是不是描述了产生--各种运行状态--消亡的信息.比如一次电梯召唤-(谁想个好听点的名字? 呵呵....) 产生是用户按了向上或向下的按钮. 然后进入"电梯来" 这个状态, 再进入电梯停(包括开门,乘客进去,关门)的状态,然后又是"电梯走" 的状态,再之后是电梯再停给用户下去,然后这个电梯召唤以电梯停止移动等待下次召唤作为结束.如果向应用领域的专家(这里比如是电梯工程师)描述这个对象,他是否可以马上明白重要性? (比如如果你对一个电梯工程师说"调度工厂",他应该就不明白..因为工厂模式是面向对象设计的手段,跟电梯这个主题本身没多少联系)以上列出的6点,不一定要每点都符合,不过如果每点都不符合,那不用考虑...删掉吧........然后考虑系统以外的情况了. 这些对象中:系统能识别吗? (比如对于超重还是不超重...有些就可以识别,有些电梯就不能..)哪些是系统必须做出响应的(用户按的按钮明显就是一个...)对于发生的事件(比如按下按钮,比如电梯门打开) 哪些对象可以识别它?有没有没用上的?还需要其他对象吗?有没有不能识别又不需要响应的对象(比如用户的帽子???? ^_^) ,不过要注意,并不是绝对的,在极少数情况下,不能识别又不需要响应的对象是有用的.不过那是后话了,先不考虑它....系统需要跟其他系统相连么? (比如,跟火灾警报系统相连, 火灾发生时不准打开电梯门...这里当然我们不考虑这么复杂,但是毕竟是存在这样的东西)用于沟通两个对象的对象是不是不小心漏掉了? (这是常见的)在你删除一个候选对象的时候,问问: 去掉以后系统会怎样? 如果我要重用一个包含了这个对象的一大块功能,这个对象到底会给真的用上么?(注意重用是非常重要的,绝对不要为了一个地方而写程序,程序要可以在不同地方重用,就像不会有生产一个电视机的电视机厂一样)不断重复上面的过程,最终,你应该从不断增加新东西和不断删除东西后获得一个有些用的列表,假设如下面这样:到达事件: (就是表示电梯到了,包括开门,进电梯,关门..还有灯亮灯灭等一系列内容..)到达按钮面版(就是电梯里那10个按钮)电梯(这个没什么疑问了........)楼层...............................(其他略)然后要做的事情是给每个词一个文字描述,比如电梯的描述如下Elevator (类名一般请不要用中文.....虽然你要用中文也行....):执行电梯的控制(上走,下走)和报告功能(告诉控制中心现在自己在几楼..), 内部封装(就是不对外公开它是怎么做的,只公开结果)了控制电梯运行(马达怎么转..), 报告电梯位置,识别电梯是否准备就绪的各种服务. 他包括的属性是电梯的运动方向\位置\状态方面的信息.最后出来的对象不可能证明就是对的,也一般不会全错, ^_^ 人的问题.....注意最终用户也许会对这个有影响,所以最好还要问问他们,如果他们提出些比较麻烦的意见,如某种特定实现技术(比如如果电梯这个楼是一家生产音响的,也许老总有想法就要在电梯里有个音箱,电梯每到一层楼会报一次位置........-_- .....) 应该用专业角度劝他不要这样,如果他一定要.........那你也没办法了,谁让他是出钱的... ^_^这个模型可能会在后面被修改很多,做好心里准备.最后说一下命名, 对象的类名应该是个类而不是个功能.或一个属性. 比如可以叫"电梯" 却不好叫"电梯颜色"或"电梯上升". 对象类名最好全部都惟一,实在不好惟一了,就用不同的包分开,就像把相同文件名的不同文件放不同的文件夹里就行. 对象名称必须在应用领域有意义(也就是在这里必须在电梯界有意义, 而不能只在软件界有意义..) 用名词或形容词+名词, 不要用名词+动词的方式. 不要出现"和", "或", "与"之类的内容.(比如人就叫Humen 不要叫LadiesAndGentalmen.... ^_^ )现在,大家列出些什么对象了呢?ArrivalEventArrivalPanelDestinationEventDestinationPanelElevatorElevatorMotorFloorOverweightSensorSummonsEventSummonsPanel .......................................................大概是这样的一些东西,(可能跟我这个差十万八千里,不过没关系,那也是正常的.....如果照上面说的做了,那应该也错不到哪去..)好了,.....今天先到这,未完待续抛砖引玉, 思考面向对象是什么? (面向对象系列之二)上一个文章驳斥了别人误人子弟,不过深刻记得十几年前老师就教过, 如果你自己不能做得更好,就不要说别人不好.所以这篇聊聊跟面向对象有关系的话题,希望抛砖引玉.先考虑一个现实问题, 大家都熟悉的手机发短信. 来看看早期(A 大约是汇编语言时代),中期(B 结构化),现在(C 面向对象)三种思想下的不同实现.我说的是思想, 因为虽然现在大家使用着面向对象的工具,但是大部分程序员的思想依然没有面向对象. 比如现在我手下这群程序员里有面向对象分析和设计能力的也就一个..用最面向对象java和C#也可以写出杂乱无章完全不面向对象甚至不结构化的程序.注意到现在我们的手机号码分成移动和联通两种, 虽然对我们来说,不过是号码不一样收费不太一样,没多少区别,但是两家的短信接口可是完全不一样的.假设程序要求用户在界面上输入手机号码(TextBox1),输入一条短信内容(TextBox2),按确定(Button1),就可以把短信发到那个手机上A 一步一步走,该干什么就干什么...看看伪代码:st***号码= TextBox1.Text;st***内容= TextBox2.Text;int 第3位数字= int.Parse(号码.Substring(2,1)); //把第3位取出来,用来判断是不是移动的手机如1390000000 就取出一个9if(第3位数字> 3){............//这里是一堆长长的代码用来发送***的短信...省略,我们这里只说程序的思想..不涉及技术细节}else{..........//又是一堆长长的代码用来发送***的短信}B 写一个库,定义出发送***短信的函数和发送***短信的函数,还有判断的函数,假设函数原型分别是发送移动短信(st***手机号码,st***内容);发送联通短信(st***手机号码,st***内容);bool 是否是移动号码(st***手机号码);然后写程序如下:if(是否是移动号码(TextBox1.Text))发送移动短信(TextBox1.Text,TextBox2.Text);else发送联通短信(TextBox1.Text,TextBox2.Text);C 定义一个抽象接口"短信接收者", 由"*** "和"*** " 两个类分别实现接口. 各自实现发送短信方法.然后构造一个"手机工厂"(一时想不到好的名字,暂时叫这个吧) , 接收一个号码,返回一个"短信接收者"接口(里面根据接收的参数,可能是***或***)然后程序如下(一行..):手机工厂.获取接受者(TextBox1.Text).发送(TextBox2.Text);或写成这样清晰点:st***号码= TextBox1.Text;st***内容= TextBox2.Text;手机工厂.获取接受者(号码).发送(内容);OK,对于上面3段伪代码大家有什么想法? 第3种是不是看起来有点爽? 也许把,也仅仅是看起来那么一点爽,没什么大不了.没错,面向对象是在大型的地方更能体现优势,一小堆是展现不出来的. 我们假设程序中一共有100个这样的地方(比如一个是发短信的,一个接短信的,一个打电话的,一个上网的.....)那么对于A程序,很抱歉,非常要命,要在100个地方复制代码,复制100份,然后对其中99份做修改(或多或少,总要改点..)B程序只是在每个调用的地方加几行,可以接受.C程序在调用点也是加1行,同样也可以接受.这个时候,结构化和面向对象共同的优点体现出来了,复用性(教科书中讲面向对象总是说说复用是面向对象比其他方法的优势,其实结构化本身就是可复用的)A方法差不多该抛弃了........这就是结构化发展起来以后, 非结构化很快面临淘汰地步的原因,因为在软件稍微大点,就出麻烦,写写单片机小模块还行.软件在一天天变大变复杂,仅仅是变大变复杂而已? 当然不是. 也变得多变. 用户的需求时时在变.软件也容易变,.回到刚才的问题, 现在不是有小灵通么? 你又需要多一种类型,变成小灵通\移动\联通3种类型.那么对于 A ,灾难发生....修改程序的成本不比重新做一个少.对于B 需要去100个调用的地方多加一个if来判断,然后多加一个对应小灵通的函数. 修改量有点大,不过也不是不行,因为毕竟现在的工具发达,你可以查找--替换.不过程序是需要测试的,你替换一个地方,就需要多测试一个地方,成本高.对于C 多加一个实现接口的"小灵通" 类, 然后修改"手机工厂"的"获取接受者(st***号码) ". 一共2处,测试也只要再测试这个新类还有一个方法.C 方法面向对象的优势在这个时候体现出来了.有人这个时候出来抗议了,如果程序写的多了,经验丰富了,有人会看出我上面那些假设的漏洞,就是B 并不是最好的结构化方法, 因为其实有更好的用一个函数来实现判断类型那样就跟 C 一样,只要改很少的地方了.没错, 那样C和B又公平平等了,C还是没什么优势. 请注意2点第一: "面向对象" 不是指面向对象的编程语法, 而是一种思想. 那样写其实 B 已经拿到了一点面向对象的思想了只是封装在非面向对象的语法中. 第二不面向对象的确可以写出低耦合的,高效的,可维护的,很牛逼的程序. 但是那是需要很高造诣的人来做的事. 因为没有类的封装性,名字空间的隔绝还有全局性的变量在程序里走, 要靠程序员自己去避免这些"可以做,可以方便地做"却"会对未来维护带来灾难"的操作, 对程序员要求很高,你要自觉不用全局变量,就像以前自觉不用goto语句....还要自觉把功能分好摆好, 需要的分析设计技术是很高的. 而写出同样质量的面向对象程序,只要略知道设计模式的人就都可以了. 这就是面向对象大行的原因之一.有人说,面向对象就真的封装了?可重用了? 可是我看见很多C#和java程序错乱复杂, 根本拿不出一个"块" 出来用,你拿了"块A " 就调用到"块B ", 非要把"块B "也拿来..然后又要用到无关的C,D,E,F.....最后出来一大落,而且99.9999%是我不需要的,我就只需要那0.00001%而已....这是现实,的确,至少我看见的代码里垃圾代码占多数(这里是指可以实现功能却很"有臭味"的代码), 这主要有一个很大的原因是写代码的人没有面向对象的思想,有的只是面向对象工具包装的面向过程思想,而且连结构化都说不上. 不是面向对象的错.差不多,有些人现在认同面向对象了,也知道这不是书上随便说的那些苦涩的概念了,不过还是不明白怎么个面向对象法. 我再换个话题说说,不说手机吧,说衣服,服装厂生产衣服. 衣服有颜色,有大小,有款式.... 看看一个设计,在不同的人手里是什么不同的方法.现在服装厂要生产一批蓝色的, 小号的, 女款的...的衣服...A :衣服衣服1 = new 衣服();衣服1.颜色= 兰;衣服1.号码= 小;衣服1.款式= 女式;.....然后new 出好多件来.赋值好多下....现在问题是突然说不要兰的了要红的, 哎哟....改啊改.... 当然你可以在循环里做这个,但是如果每件衣服除了颜色和款式一样, 大小是不同的又如何?有个B想到了一个好的设计了.定义一个衣服类, 然后把大衣服作为一个子类,小衣服是另外一个子类. 那么方便了一些. 不过又有问题,如果再改需求.....要求大小跟男女固定的,颜色可以变,难道又再定义出兰衣服类和红衣服类.....那还有完没完啊........依然不是好设计.C面向对象有一个利器叫"设计模式", 学面向对象基本上这个是必修, 我们用用设计模式中的原型模式,构造出一个原型假设是一件大的男装, 然后通过Copy这个原型就可以得到一批大的男装,然后给各种颜色就行. 如果是再变化,那么我们不需要什么变,只要再构造另外一个原型,然后用代码Copy这个原型,又可以试用新的变化了....(今天的内容基本是面向新手级程序员和学校里的高手学生的,未完待续....接下来将会是一个完整的面向对象设计分析例子,真正体会面向对象的优势和如何面向对象分析设计)。
软件工程实用案例 第6章 面向对象的需求分析
(4) 对象之间通过消息传递相互联系。类具有封装性， 其数据和操作等对外界是不可见的，外界只能通过消 息请求进行某些操作，提供所需的服务。
6.1 面向对象的基本概念
软件工程学家Codd和Yourdon认为：
bus306.showG(); }
//执行自有方法showG
类的继承是软件重用的一种形式，通过继承的属性和行为扩充原有类的功能， 节省了程序开发时间。
6.1 面向对象的基本概念
3. 多态性(Polymorphism) 多态性的概念可以被说成“一个方法，多种实现”。
1) 重写(Overriding)
消息的基本格式为：对象名.方法名(参数)
Katie.shaketail()
在面向对象中，所有的功能都是通过对象之间互发消 息来实现的，消息机制可以像搭积木一样，快速开发 出一个全新的系统。
6.1 面向对象的基本概念
6.1.2 封装、继承和多态性
1. 封装(Encapsulation)
封装是面向对象方法的一个重要原则，它把对象的属 性和服务结合成一个独立的系统单元，是一种信息隐 藏技术，将对象的外部特征(可用的方法)与内部实现 细节(属性、方法如何实现)分开，对象的外部特征对 其他对象来说是可访问的，而它的内部细节对其他对 象是隐蔽的。
运行结果：
public class shapeTest
半径为：2 面积为：12.57 底为：3 高为：4 面积为：6
{ public static void main(String args[])
{ Shape c=new Circle(2);
需求分析-面向对象 PPT课件
描述 管理普通读者
管理书籍资料 管理书目
登记借书 登记还书
16
返回
MiniLibrary——识别实体类
实体类 BorrowerInfo
BookInfo LendRecord
itemInfo
描述 普通读者信息 书籍资料信息
借书记录 书目信息
17
ReturnForm
描述 管理普通读者的界面
管理书籍资料的界面 管理书目的界面
登记借书的界面 登记还书的界面
15
返回
MiniLibrary——识别控制类
控制类 ManageBorrowerCon
trol ManageBookControl
ManageBookitemCon trol
LendControl
13
返回
实体类
• 概述 —通常指用例中的参与对象，对应现实世界的“事物” —例如：人员、组织、物品、设备、事件或者表格
• UML的表示
14
返回
MiniLibrary——识别边界类
边界类 ManageBorrowerFo
rm ManageBookForm
ManageBookitemF orm
LendForm
第三章 需求分析
主讲：李晓蕾
1
患者监护系统
现有一医院病房监护系统，病症监视器 安置在各个病房，将病人的病症信号实时 传送到中央监视系统进行分析处理。在中 心值班室里，值班护士使用中央监视系统 对病人的情况进行监控，根据医生的要求 随时打印病人的病情报告。定期更新病历， 当病症出现异常时，系统会立即自动报警， 并实时打印病人的病情报告，立即更新病 历。
2
面向对象需求分析实例PPT
• 演示
19
北京北大方正电子有限公司
三、业务用例描述
• 内容提要
– 描述业务目标 – 描述业务现状、数据结果要求 – 描述业务分析视角、列出典型业务场景 – 业务用例描述，详细介绍
• 演示
23
北京北大方正电子有限公司
UML常用视图分类
模型视图
1
用例图
2
需求图
3
活动图
4
序列图
5
状态图
6
类图
7
组件图
8
协作图
9
部署图
需求分析 ★ ☆ ★ ★
系统设计
★ ★ ★ ★ ★
☆
详细设计
★ ★ ★ ★ ☆ ☆
24
北京北大方正电子有限公司
二、需求分析视图
• 用例建模的疑惑
– 快速原型，让用户先认同原型，再不断开发 – 软件就是设计很多功能，最终能满足需求 – 前期无法确定需求，先尽快完成再调整 – 用户不懂用例，我们也不懂，也没时间建模 – 直接告诉程序员要做什么，更准确快捷
5
北京北大方正电子有限公司
一、用例分析技术概述
• 快速原型法 vs 面向对象分析
– 快速原型法的前提是必须了解实际业务需求 – 前者是具体的一种实现方式，易丢失原始需求，
掺入过多细节、华丽功能、个人设计习惯 – 可结合起来，用后者来分析，当成编写电影脚
本，用前者来直观呈现和印证挖掘，佐证结果 按使用者角度记载下来，保留业务需求 – 不要以建模成本高而放弃OOA思想
• 用例
– 用例就是做一件事情，完成某个目标。 – 一件事要按一系列步骤完成活动 – 做事有不同的方式和相应的步骤用例场景
第4章__面向对象需求分析
• 在确定事件轨迹后，所有事件可以汇总成输入对象的事件 集和从对象输出的事件集。事件流图就是用于标记所有流入和 流出某对象的事件。
•
例：打印机对象—行为模型示例。
• 状态转换图表示了打印机的状态转换。图中的每个箭头代 表了从对象的一个状态到另一个状态的转变，箭头上标记的是 触发转变的事件。有时需要增加保护条件来满足对象的变迁， 例如，上图中打印机在故障状态时，故障修复事件只有在打印 队列不破坏的情况下才能使打印机进入打印状态，否则即使修 复也只能进入就绪状态。
工人
1..*
经理 管理
（1）关联
•限定关联 • 限定关联通常用在一对多或多对多的关联关系中，可以把 模型中的重数从一对多变成一对一，或从多对多简化成多对一。 在类图中把限定词放在关联关系末端的一个小方框内。 • 例如，某操作系统中一个目录下有许多文件，一个文件仅 属于一个目录，在一个目录内文件名确定了惟一一个文件。利 用限定词“文件名”表示了目录与文件之间的关系，可见，利 用限定词把一对多关系简化成了一对一关系。
（1）关联
•关联类 • 为了说明关联的性质可能需要一些附加信息。可以引入 一个关联类来记录这些信息。关联类也有属性、操作和其他 关联。
个人
0..*
授权
0..*
个人
授权 优先权 特权
用户和工作站的授权关联的关联类
3.对象-关系图
• （2）聚集
• 聚集也称为聚合，是关联的特例。聚集表示一类对象与 另一类对象之间的关系，是整体与部分的关系。
• 一.面向对象分析模型的组成结构 • 二.面向对象分析模型描述工具 • 三.面向对象分析的基本过程
• 四. 面向对象分析方法
• 五. 小结
一.面向对象分析模型的组成结构
面向对象的需求分析 - 成都信息工程学院-
状态转换图：仅对每个对象主动状态转换的描述
控制面板类状态图 比较password = 不正确 比较password = 不正确 重新进入状态 控制面板
控制面板
password 进入
控制面板
静止状态
划分状态
控制面板
比较password = 正确
确定系统行为 系统行为： 体现在作用于实体属性的操作上
9）通过顺序图、状态图、协作图标 识类的服务
面向对象的需求分析(实例)
1) 分析使用场景 (Use Case) 从参与者入手，提供参与者与系统交互功能的形式描述。 以SafeHome的软件为例，分析系统的三个参与者： 房主、传感器、监控响应子系统（控制警告和拨打电话）
激活成功
选择状态
9) 通过顺序图、状态图、协作图标识类的 服务
SafeHome软件使得房主能够在安装时配置安全系统、监控所有和安全系统连 接的传感器以及通过包含在SafeHome控制面板中的键盘和功能与房主交互。
在安装过程中，SafeHome控制面板被用于编程和配置系统，每个传感器被赋予 一个编号和类型，主人密码被编程以启动和关闭系统，而且当传感器事件发生时， 输入电话号码自动拨号，
下一动作准备
红灯停止
面向对象的需求分析(实例)
7）画Collaboration协作图
选择驻留/离开
系统准备 房主 下一动作准备 激活/失活准备 鸣响声音 传感器激活/失活 红灯停止 登录passsword
控制面板
启动鸣响
激活/失活传感器 红灯停止请求
系统
面向对象的需求分析(实例)
8）画State Transition状态图
(完整版)软件工程 第五章 面向对象的需求分析
第五章面向对象的需求分析面向对象的需求分析方法的核心是利用面向对象的概念和方法为软件需求建造模型。
它包含面向对象风格的图形语言机制和用于指导需求分析的面向对象方法学。
面向对象的思想最初起源于 20世纪 60年代中期的仿真程序设计语言Simula67。
20世纪80年代初出现的Smalltalk 语言及其程序设计环境对面向对象技术的推广应用起到了显著的促进作用。
20世纪90年代中后期诞生并迅速成熟的UML（Unified Modeling Language，统一建模语言）是面向对象技术发展的一个重要里程碑。
UML 统一了面向对象建模的基本概念、术语和表示方法，不仅为面向对象的软件开发过程提供了丰富的表达手段，而且也为软件开发人员提供了互相交流、分享经验的共用语言。
本章首先介绍面向对象的主要概念和思想。
在概述了UML的全貌之后，以“家庭保安系统”为实例，介绍与需求分析相关的部分 UML语言机制以及基于UML的面向对象的需求分析方法和过程。
第一节面向对象的概念与思想一、面向对象的概念关于“面向对象”，有许多不同的看法。
Coad和 Yourdon给出了一个定义：“面向对象 = 对象 + 类 + 继承 + 消息通信”。
如果一个软件系统是使用这样4个概念设计和实现的，则认为这个软件系统是面向对象的。
一个面向对象的程序的每一成分应是对象，计算是通过新的对象的建立和对象之间的消息通信来执行的。
1.对象（object）一般意义来讲，对象是现实世界中存在的一个事物。
可以是物理的，如一个家具或桌子，如图 5-1-1所示，可以是概念上的，如一个开发项目。
对象是构成现实世界的一个独立的单位，具有自己的静态特征（用数据描述）和动态特征（行为或具有的功能）。
例如：人的特征：姓名、性别、年龄等，行为：衣、食、住、行等。
图 5-1-1 对象的定义（1）对象、属性、操作、消息定义对象可以定义为系统中用来描述客观事物的一个实体，它是构成系统的一个基本单位，由一组属性和一组对属性进行操作的服务组成。
面向对象的需求分析 PPT课件
2. 用例建模
定 义 确 定 识别 确
定建
立书
写
系统边界 参与者 用 例 用例间关系 完整用例图 用例描述文档
用例间及其与参与者间存在着相互联系，将不同部分连接为一体：
关联：
参与者和用例之间的连线表示关联关系
关联“通讯” 表示参与者和用例间存在“通讯”关系，表示参与 者使用了系统中的“通讯”服务。
除与参与者之间存在关联外，用例之间还存在多种关系：包含、 扩展、泛化关系等。用例间关系可简化用例图模型，使之层次化。
➢另外谁，（分或析什人么员）可对以系通统过运回行答结下果面（的值问）题感来兴寻趣找？系统的参与者 ➢ 时间、气温等内部外部条件是否会触发系统某些功能执行？
第六章 面向对象的需求分析
2. 用例建模
定义
识别 确
定建
立书
写
系统边界 确 定 用 例 用例间关系 完整用例图 用例描述文档
参与者
举例： 对于大家都非常熟悉的自动取款机（ATM）系统来说，它 的主要参与者有哪些呢？
第六章 面向对象的需求分析
2. 用例建模
定 义确定
确
定建
立书
写
系统边界 参与者 识 别 用例间关系 完整用例图 用例描述文档
用例
识别用例最佳方法是从分析 参与者 开始，将每类参与者代表和需 求分析人员召集到一块进行讨论，每个参与者考虑自己是如何使用 系统的，提出自己的需求，然后大家再一块讨论确定。
参与者: 存在于被定义系统外部、透过系统边界与系统交互的客观 实体，如系统的使用者或外部设备。 常见三类 参与者：
第三二一类是为一其系些他统可的用运软户行、，的硬是进件真程系实统的，人例，，如例这时如是间，最系银常统行见。金的有融参些系与系统者统可，中能几，与乎需一每要些个在商 特场系定售统的货都时系要间统有周建人期立来性联使地 系 用触，。发进对系行于统银此执行类行卡参某刷与功卡者能消，，费主这。要时显根，然据时商用间场户系售在统货使就系用成统系了的统 系刷时统卡扮的系演参统的与就角者是色。银命例行名如 金，，融例在系如银统，行的银的一行金个的融参营系与业统者部中。的，另营客外业户，员的参，资与通料者常、也情交可况易能下记是 录一银行等些工信硬作息件人至设员关备，重但要例是， 如他所银自以行己要的要定安存期全取对监款客控的户系时的统候这在，些下其资班身料之份信后就息，变进如成行果了备有客份人户，进。 到入所以了金，设库在定，命的则名时进参间行与，红者系外时统检按自测照动而业执且务行进命资行名料报比备警按份，照功所人能 以的。对职因于位此安来，全命时监名间控更系稳统定也来。 是说对于系，一统红个的外银一探行个测的参设网与备络者 和系。报统警来的说硬，件其设参备与就者是我它们的就参可与以者看。作有营业员， 还有客户。
面向对象需求分析
面向对象需求分析目录1.1系统概述 (3)1.2人员信息管理子系统 (4)1.2.1概述 (4)1.2.2业务事件 (4)1.2.3报表 (9)1.3薪资管理子系统 (9)1.3.1概述 (9)1.3.2业务事件 (10)1.3.3报表 (13)1.4招聘管理子系统 (14)1.4.1概述 (14)1.4.2业务事件 (14)1.4.3报表 (17)1.5培训管理子系统 (17)1.5.1概述 (17)1.5.2业务事件 (17)1.5.3报表 (19)1.6考勤管理子系统 (20)1.6.1概述 (20)1.6.2业务事件 (21)1.6.3报表 (24)1.7系统管理子系统 (26)1.7.1概述 (26)1.7.2业务事件 (26)1.7.3报表 (26)功能概述1.1系统概述本系统由人员信息管理子系统，薪资管理子系统，招聘管理子系统，培训管理子系统，系统管理子系统，考勤考核管理子系统，这些主题域组成，它们之间的关系如图所示：(可后来实现的)登录身份 信息资料1.2人员信息管理子系统1.2.1概述该主题域的主要用户是员工，人力资源管理员，将对人员信息进行查看，变动（修改，添加，删除）提供支持。
其范围如下图所示：1.2.2业务事件1)员工信息查询员工成功登录人力资源管理系统，输入相关信息条件，进行员工信息查询。
其流程如图所示：员工对于自己的相关基本信息进行查看，以及相关人员查看员工的信息。
流程中主要涉及的业务实体以及它们之间的关系如图所示：在这个业务流程中，有两个直接与系统交互的用户：系统管理员，员工，涉及的业务活动如图所示：2)员工信息修改人力资源管理部门等相关人员根据情况对员工信息进行修改更新与维护，员工自身对于自己的信息的更正等。
整个流程如图所示：流程中涉及的的业务实体在上图的基础上增加了人力资源部门的员工，它们之间的关系如图所示：这个业务流程中有三个直接与系统交互的用户：系统管理员，员工，人力资源部门人员，他们涉及的业务活动如图所示：3)新员工信息添加当公司招聘进新的员工时，需要将新员工的信息存进系统中。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
–参与者：系统之外、直接与系统交互、人或 物、有责任和目标
–用例：执行者可见、有意义的目标、业务语 言、动宾、用户视角、交互完整
–粒度：操作者与计算机的一次完整交互
北京北大方正电子有限公司
五、功能需求描述
• 有了详细的系统用例，就不用再功能分解
–是对结构化分析和WBS的挑战
• 是功能需求，而不是功能 • 描述功能需求的要点
• 禁忌
–从里往外看、硬套解决方案
北京北大方正电子有限公司
1. 业务用例图
• 建模步骤
–根据业务目标界定边界，和计算机实现无关 –业务主角
• 边界之外、对系统有明确期望和回报、主动要求 • 不是系统强加的角色，是实际的岗位或人员
–业务用例
• 由参与者主动发起、可观测、完整的业务目标 • 粒度：边界要清楚，用例数在10~50个之间 • 用例≠功能，不是能做什么，而是要做什么
• 面向过程分析 vs 面向对象分析
–SA：顺藤摸瓜得到全貌，结构化分解为子系 统和各级功能，重点关注流程
• 例如：数据流程图、需求规格说明书的功能划分 • 问题：在随需应变的商业环境下，流程不再稳定
–OOA：着眼于个体和局部，了解个体的特征、 行为、需求，找到相邻的联系，按不同视角分 析，最终得到整体任务全景
一、用例分析技术概述
• 用例与需求调研
–面对的是局部个体，问对人，做份内之事， 看到关心的结果
• 请比较调研分析的角度：
–A. 您希望系统帮你做些什么事情？ –B. 您希望系统怎么做比较好？ –C. 系统这样做，你看如何？ –D. XX部门需要什么功能？提供这些功能如何？ –E. 我们有这些很有用的功能
北京北大方正电子有限公司
2.1 界定业务目标
• 目的
–时刻提醒需求分析的方向，不偏离边界范围
• 做法
–先将业务目标简明准确的概括出来 –对具体目标编号、标题+说明 –在业务建模图中标出各个业务目标
北京北大方正电子有限公司
2.1 界定业务目标
北京北大方正电子有限公司
2.2 划分业务视角
• 目的
–限定分析范围、业务边界，避免用例混乱 –在特定业务视角中满足业务需求
系统设计
★ ★ ★ ★ ★
☆
详细设计
★ ★ ★ ★ ☆ ☆
北京北大方正电子有限公司
二、需求分析视图
• 用例建模的疑惑
–快速原型，让用户先认同原型，再不断开发 –软件就是设计很多功能，最终能满足需求 –前期无法确定需求，先尽快完成再调整 –用户不懂用例，我们也不懂，也没时间建模 –直接告诉程序员要做什么，更准确快捷
uc 建立图书库的业务用例
uc 使用图书资源的业务用例
汇集图书资源
数字出版专员
录入书目信息 导入ERP书目信息
出版社编辑 出版科人员
选用图书素材 获取排版文件
北京北大方正电子有限公司
1. 业务用例图
• 使用场合
–来源于访谈，表达业务目标，按需定做 –多角色、业务流程复杂、长期发展
• 要领
–找出业务参与者、关心的问题 –站在客户角度看，忘掉系统，不要急于实现
北京北大方正电子有限公司
2. 业务场景活动图
北京北大方正电子有限公司
2. 业务场景活动图
• 使用场合
–描述复杂、核心的业务流程的各种场景
• 要领
–按角色划分泳道，明确职责和联系 –活动为业务用例或关键概念用例
• 禁忌
–强加系统流程、涉及用户不可见的内容 –非用户语言
北京北大方正电子有限公司
3. 系统用例图
北京北大方正电子有限公司
一、用例分析技术概述
• 快速原型法 vs 面向对象分析
–快速原型法的前提是必须了解实际业务需求 –前者是具体的一种实现方式，易丢失原始需
求，掺入过多细节、华丽功能、个人设计习惯 –可结合起来，用后者来分析，当成编写电影
脚本，用前者来直观呈现和印证挖掘，佐证结 果按使用者角度记载下来，保留业务需求 –不要以建模成本高而放弃OOA思想
uc 系统用例图
导入ERP书目信息
数字出版专员
录入书目信息 检查图书资源
出版社接口人 出版社编辑 出版科人员
确认采集情况 采集图书资源
«include» 查看采集任务
«include»
选用图书素材
«include»
查找图书
获取排版文件
«include»
北京北大方正电子有限公司
3. 系统用例图
• 使用场合
• 做法
–按照不同的业务目标分别建立用例“包” –每个包中一个用例图
北京北大方正电子有限公司
2.2 划分业务视角
北京北大方正电子有限公司
2.3 识别业务主角
• 业务主角（Business Actor）
–与业务系统有交互的人或事物，用于确定业 务范围，区分与业务工人
• 注意
–业务主角是客户实际业务里的参与者，没有 计算机系统这些业务主角也客观存在，没有抽 象的计算机角色
• 不适合的场合
–不是功能密集型，而是技术密集型，单用户
北京北大方正电子有限公司
知识回顾 Knowledge Review
• 演示
北京北大方正电子有限公司
三、业务用例描述
• 内容提要
–描述业务目标 –描述业务现状、数据结果要求 –描述业务分析视角、列出典型业务场景 –业务用例描述，详细介绍
• 演示
北京北大方正电子有限公司
四、系统用例分析
• 从业务用例映射到系统用例
–识别责任、边界、目标 –补充必需的系统用例，如系统管理
北京北大方正电子有限公司
面向对象需求分析实例
用例分析方法及需求描述介绍 张云贵
2009.10.31
北京北大方正电子有限公司
内容提要
• 用例分析技术概述 • 业务用例建模 • 业务用例描述 • 系统用例建模 • 系统用例描述 • 功能需求描述 • 方法讨论
北京北大方正电子有限公司
一、用例分析技术概述
北京北大方正电子有限公司
二、业务用例建模
• 区分概念
–功能、需求、业务需求、用例
–系统用例、业务用例、业务场景
• 为什么要进行业务建模？
–成为业务专家，全面了解业务目标和内涵 –在新领域内长期发展、拓展业务 –让团队成员了解需求、理解一致
北京北大方正电子有限公司
二、业务用例建模
• 内容提要
–界定业务目标、划分业务视角 –识别业务主角、业务用例，要点 –业务场景建模，要点 –修正业务用例和场景
–描述做什么，不描述如何实现 –对于界面示意图，必须有文字描述其需求点
北京北大方正电子有限公司
用例文档分析
• 用例文档分析（演示） • （后面为另一个PPT的部分内容）
北京北大方正电子有限公司
UML常用视图分类
模型视图
1
用例图
2
需求图
3
活动图
4
ห้องสมุดไป่ตู้
序列图
5
状态图
6
类图
7
组件图
8
协作图
9
部署图
需求分析 ★ ☆ ★ ★
• 如何扩展用例
–先完成所有业务边界包、主要业务用例 –不要急于扩展用例，现在还在边界外
北京北大方正电子有限公司
2.4 识别业务用例
北京北大方正电子有限公司
2.5 业务场景建模
• 业务场景活动图
–使用泳道来区分各个岗位的职责和关系 –用于核心或复杂业务流程、跨部门/岗位协作
• 注意点
–使用实际业务语言，不要抽象 –条件分支不要太多，可用多个场景来描述 –忘掉我们的系统，描述目前业务情况
–描述应实现哪些任务，系统范围
• 要领
–从业务用例场景中获取，排除、合并、补充 –粒度为操作者与计算机的一次完整交互为宜 –参与者：系统之外、直接与系统交互、人或
物、有责任和目标 –用例：执行者可见、有意义的目标、业务语
言、动宾、用户视角、交互完整
北京北大方正电子有限公司
3. 系统用例图
• 禁忌
–急于加入细节、具体的技术实现方法 –功能分解
北京北大方正电子有限公司
2.3 识别业务主角
北京北大方正电子有限公司
2.3 识别业务主角
• 先找业务主角，再找对应的业务用例 • 业务主角的特点
–在当前业务边界外，为其提供服务
• 建立该项目能对外提供什么服务？
–主动发起要求，有预期目的并得到结果 –业务工人在此无权提出业务用例
• 识别举例
北京北大方正电子有限公司
• 用例建模的实质
–以人为本，从参与者角度规定要做的事/规则
北京北大方正电子有限公司
二、需求分析视图
• 业务流程分析图 • 业务用例图 • 业务场景活动图 • 系统用例图 • 需求图 • 用例实现序列图
（演示）
北京北大方正电子有限公司
1. 业务用例图
pkg 业务用例图
本项目的业务目标： 1、建立图书库，历史图书信息从已有的ERP系统导入 2、将分散在各个出版社的图书资源统一管理起来 3、实现图书资源的共享和再利用，便于图书再版和图书资源选用
2.4 识别业务用例
• 用例
–用例就是做一件事情，完成某个目标。 –一件事要按一系列步骤完成活动 –做事有不同的方式和相应的步骤用例场景
• 业务用例
–用于描述客户现有业务，和新系统无关
北京北大方正电子有限公司
2.4 识别业务用例
• 业务用例的特点
–实现完整的业务目标 –由主角发起，有明确的结果 –动宾，避免弱动词和弱名称 –如果粒度太大或太小，需要调整边界
• 用例的场景仍是面向过程的