面向对象分析与设计(8)-案例

合集下载

一个完整的面向对象分析与设计例子

一个完整的面向对象分析与设计例子首先说明,接下来这部分内容,跟面向对象没什么关系,只是描述出我们接下来"需要做什么".大家都知道电梯是怎么回事了,所以获取需求的过程我就不啰嗦了,直接把最后结果描述出来.(对于计算机专业学生或软件工程毕业设计的需求分析结果应该有些参考意义...起码可以看出怎么样的结果才真正有意义)电梯楼层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这个原型,又可以试用新的变化了....(今天的内容基本是面向新手级程序员和学校里的高手学生的,未完待续....接下来将会是一个完整的面向对象设计分析例子,真正体会面向对象的优势和如何面向对象分析设计)。

面向对象分析与设计

面向对象分析与设计面向对象分析与设计（Object-oriented analysis and design）是软件工程领域中的一种方法论，用于解决软件系统开发过程中的问题和需求。

本文将对面向对象分析与设计的基本概念、流程和常用方法进行介绍，并附带答案和解析。

第一部分：面向对象分析（Object-oriented analysis）面向对象分析是软件开发过程中的第一步，旨在理解问题域并建立领域模型。

面向对象分析有以下几个重要概念：1. 对象（Object）：对象是系统中的一个实体，包含数据和方法。

对象可以是具体的实物、虚拟的概念或一组相关的数据和行为。

2. 类（Class）：类是一种抽象的定义，描述了一组具有相同特征和行为的对象。

3. 属性（Attribute）：属性是对象的特征，用于描述对象的状态。

4. 方法（Method）：方法是对象的行为，用于描述对象可以执行的操作。

面向对象分析的主要流程包括以下步骤：1. 需求收集：收集系统的需求，与利益相关者沟通，了解系统的功能和性能要求。

2. 领域建模：对现实世界的问题域进行抽象和建模，识别出系统中的对象和它们之间的关系。

3. 需求分析与规约：通过使用用例、活动图和状态图等工具对需求进行分析和规约，明确功能和交互细节。

4. 领域模型验证：与利益相关者验证领域模型的准确性和实用性，确保模型能够满足系统需求。

第二部分：面向对象设计（Object-oriented design）面向对象设计是在面向对象分析的基础上，进一步细化领域模型，为系统的实现提供指导。

面向对象设计有以下几个常用方法：1. 类图（Class diagram）：类图用于展示类、属性和方法之间的关系。

类图包括类的名称、属性和方法，并通过关联、继承和聚合等关系展示类之间的联系。

2. 对象图（Object diagram）：对象图用于展示类的实例和对象之间的关系。

对象图是类图的实例化表示，展示了系统在某一时刻的对象及其特定的属性值。

面向对象分析与设计教学案例

面向对象分析与设计教学案例研究该案例示范了使用Rational Rose如何对系统进行建模。

使用用例和领域分析的方法来对系统进行分析并且设计一个分析模型。

然后把分析模型扩展成设计模型，此设计模型描述了一种技术方案。

最终，设计模型转变为用面向对象的编程语言创建的可以运行的程序。

这里将把某大学课程管理的问题作为本部分的示例。

【案例材料】1. 某大学背景学生登记在大学里是一种非常耗时的活动，学校还面临着给教室排课的问题。

在每个教师决定了他这个学期将讲授什么课程之后，教务处将这些信息输入到一个计算机系统，然后给每个教师打印一份报表，最后要打印一份课程目录给学生。

依照现有系统，学生填写注册表并确定他们所选的课程，然后将所有信息递交到教务处。

一个学生在一段时间内最多选四门课。

教务处将这些信息输入到计算机。

一旦输入了学生所选的课程，就会把学生安排到这些课程。

大多数时候，学生得到他们选课的课程，但是，当发生冲突时，教务处将询问学生以便得到其他的选择。

一旦给所有学生都排好了课，学生的课表将打印出来给学生以便得到他们的确认。

大多数学生登记将在一周内完成，但是有些特殊情况要花两周来进行。

当最初的登记周期结束时，教师会得到他们所讲的每一门课程的学生名单。

2. 课程登记问题的风险开发团队觉得这个系统最主要的风险是有效地存储和获取课程信息。

他们开发了几个原型来评价每一个备选的数据库管理系统的数据和访问机制。

他们还开发了一些原型来研究学校运行联机登记系统的硬件需求。

3. 某大学课程登记问题状态在学期之初，学生会需要一份这个学期要开的课程列表。

每门课程的信息，如教师、部门和课程需要的前提条件将包含在这个清单里来帮助学生们选择课程。

新系统允许学生在每个学期里选四门课。

另外，每个学生还要提交两个备选课程以预防课程被选满或取消的情况。

少于三个学生选择的课将被取消。

一旦学生登记完成，登记系统将信息传入财务系统，学生就可以交这个学期的学费了。

面向对象分析(案例)

按下列标准删除不必要的和不正确的属性：
（1）误把对象当作属性：若实体的独立存在）误把对象当作属性：比它的值重要，那么这个实体不是属性而是对象。比它的值重要，那么这个实体不是属性而是对象。如在邮政目录中，城市”是一个属性，如在邮政目录中，“城市”是一个属性，然而在人口普查中，城市”则被看作是对象。口普查中，“城市”则被看作是对象。在具体应用具有自身性质的实体一定是对象。中，具有自身性质的实体一定是对象。（2）把限定误码当成属性：若属性值取决于）把限定误码当成属性：某种具体上下文，某种具体上下文，则可考虑把该属性重新表述为一个限定词。账号”“分行代码” ”“分行代码个限定词。如“账号”“分行代码” （3）名称：名称常常作为限定词而不是对象）名称：的属性，当名称不依赖于上下文关系时，的属性，当名称不依赖于上下文关系时，名称即为一个对象属性，尤其是它不惟一时。一个对象属性，尤其是它不惟一时。
系统分析的第一步是：陈述需求
分析者必须同用户一块工作来提炼需求，分析者必须同用户一块工作来提炼需求，因为这样才表示了用户的真实意图，其中涉因为这样才表示了用户的真实意图，及对需求的分析及查找丢失的信息。及对需求的分析及查找丢失的信息。下面以“银行网络系统”为例，下面以“银行网络系统”为例，用面向对象方法进行开发。对象方法进行开发。
3.确定关联
两个或多个类之间的相互依赖、相互作用的关两个或多个类之间的相互依赖、相互作用的关相互依赖系就是关联。系就是关联。可用各种方式来实现关联，可用各种方式来实现关联，但在分析模型中应删除实现的考虑，以便设计时更为灵活。删除实现的考虑，以便设计时更为灵活。关联常用描述性动词或动词词组来表示，描述性动词或动词词组来表示关联常用描述性动词或动词词组来表示，其中有物理位置的表示、传导的动作、通信、有物理位置的表示、传导的动作、通信、所有者关条件的满足等。系、条件的满足等。从问题陈述中抽取所有可能的关联表述，从问题陈述中抽取所有可能的关联表述，把它们记下来，但不要过早去细化这些表述。们记下来，但不要过早去细化这些表述。

面向对象软件开发的设计模式案例分析

面向对象软件开发的设计模式案例分析在面向对象软件开发中，设计模式是一种解决常见设计问题的可复用解决方案。

通过采用设计模式，开发人员可以更加高效地开发出可维护、可扩展、可重用的软件系统。

本文将通过分析几个常见的设计模式案例，来展示设计模式在软件开发中的应用。

1. 单例模式（Singleton Pattern）单例模式用于确保一个类只有一个实例，并提供一个全局访问点。

这种模式常用于创建独一无二的对象，例如数据库连接对象或日志记录器。

案例：线程池线程池是多线程编程中常用的技术，可以提高系统性能和资源利用率。

在线程池实现中，为了保证线程池全局唯一且只被创建一次，使用单例模式对线程池进行封装。

这样，整个系统中任何一个模块都可以方便地获取线程池实例，并执行任务。

2. 工厂模式（Factory Pattern）工厂模式是用来创建对象的一种设计模式，通过工厂类来统一创建具体的产品对象，而不需要直接实例化产品类。

案例：图形绘制假设我们需要在一个绘图软件中绘制不同类型的图形，如圆形、矩形、线段。

我们可以定义一个抽象的图形类，然后创建三个具体的图形类分别继承自抽象类。

然后，通过一个工厂类来根据用户的选择创建相应的图形对象。

这样，我们可以避免在客户端直接实例化具体的图形类，使得系统更加灵活和可扩展。

3. 观察者模式（Observer Pattern）观察者模式定义了一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都会得到通知并自动更新。

案例：股票行情假设我们有一个股票行情系统，其中包含多个股票信息，并且有多个观察者关注这些股票的行情变化。

当有股票价格发生变化时，股票行情系统会自动通知所有的观察者，并更新显示最新的股票价格。

这样，观察者模式可以提高系统的实时性和可维护性。

4. 策略模式（Strategy Pattern）策略模式定义了一族算法，并将每个算法封装在独立的类中，使得它们可以相互替换，且不影响客户端的使用。

面向对象分析与设计

面向对象分析与设计一、引言面向对象分析与设计（Object-Oriented Analysis and Design，简称OOAD）是软件工程中的一种方法论，用于解决复杂系统的设计与开发问题。

本文将介绍面向对象分析与设计的概念、原则和过程，并结合实际案例说明其重要性和应用。

二、概念解析1. 面向对象分析（Object-Oriented Analysis，简称OOA）：通过识别和描述系统所涉及的对象及其相互关系，以及对象的属性和行为，从而确定系统需求和问题领域的分析方法。

2. 面向对象设计（Object-Oriented Design，简称OOD）：基于面向对象分析的结果，通过定义类、抽象数据类型、方法、接口等概念，设计出系统的结构和组织，以及类之间的关系和交互方式。

三、面向对象分析与设计的原则1. 单一职责原则（Single Responsibility Principle，简称SRP）：一个类只负责一项职责，保证类的内聚性和高内聚性。

2. 开放封闭原则（Open-Closed Principle，简称OCP）：系统中的类、模块等应该对拓展开放，对修改封闭，通过继承、接口等方式实现。

3. 里氏替换原则（Liskov Substitution Principle，简称LSP）：所有引用基类的地方必须能透明地使用其子类的对象，即子类必须能够替换基类。

4. 依赖倒置原则（Dependency Inversion Principle，简称DIP）：高层模块不应该依赖于底层模块，二者都应该依赖于抽象；抽象不应该依赖于具体，具体应该依赖于抽象。

5. 接口隔离原则（Interface Segregation Principle，简称ISP）：客户端不应该依赖于它不需要的接口，接口应该进行细化拆分以适应不同的场景和客户端需求。

6. 迪米特法则（Law of Demeter，简称LoD）：一个对象应该对其他对象有尽可能少的了解，减少耦合性，降低系统的复杂度。

面向对象分析与设计_课程设计_08级

《面向对象分析与设计》课程设计任务书【设计目的】面向对象的分析与设计是当代软件工程领域的主流软件系统开发方法，不仅要从理论上了解和掌握面向对象的系统分析与设计的方法和步骤，并且要掌握如何实际开发一个面向对象的软件项目。

面向对象的系统分析与设计包括可行性分析、客户需求分析、系统分析、系统设计、系统实现和系统测试等几个阶段，产生的模型有系统用例模型、系统静态模型、系统动态模型和系统体系结构模型，产生的软件文档资料包括可行性分析报告、客户需求分析报告、系统分析报告、系统设计报告、程序代码文档、系统测试报告以及用户使用手册等。

只从理论上了解这些内容还远远不够，必须掌握实际开发一个面向对象系统的方法与步骤。

本课程设计的目的就是让学生通过一个具体软件系统实践，完成面向对象的分析与设计，使学生能够得到较系统的技能训练，从而巩固和加强所学的课程理论知识。

本课程设计还将达到以下目标：1．全面掌握面向对象系统开发各阶段的具体开发方法与步骤；2．掌握面向对象系统开发各阶段产生的文档资料的书写格式；3．掌握面向对象系统开发各阶段产生的系统模型；4．掌握用例驱动的面向对象的软件开发方法；5．掌握使用Rose进行面向对象软件开发设计的全过程。

【设计要求】1、要求独立完成，不能抄袭；2、课程设计时间为1.5周；3、课程设计期间，无故缺席按旷课处理；缺席时间达三分之一以上者，其成绩按不及格处理。

【题目】1．进销存管理系统进销存管理系统包括销售管理子系统、采购管理子系统和库存管理子系统，用文字描述各个子系统的大致的客户需求并给出各层用例图；每个子系统又可以分成很多子系统，如销售管理子系统包括销售计划制定、销售合同管理、售后服务等子系统，选择一个具体的子系统，选择部分用例进行文字描述和活动图细化；对选中的子系统进行系统对象类静态建模和系统对象类动态建模。

2．教学管理系统教学管理系统包括课程设置管理、学生选课管理（包括生成学期课表、学生选课、课表调整、公布选课名单、查询等用例）、成绩管理（包括成绩录入、成绩查询、成绩统计等用例）、学籍管理、教室管理、教材管理、教学评估管理等。

面向对象分析设计案例

面向对象分析设计案例在软件开发领域，面向对象分析设计（OOAD）是一种常用的方法论，它将系统看作是一组对象的集合，这些对象之间通过消息传递进行通信和协作。

本文将以一个简单的图书馆管理系统为例，介绍面向对象分析设计的基本概念和流程。

首先，我们需要明确系统的需求和业务场景。

图书馆管理系统主要包括图书管理、读者管理、借阅管理等功能。

在面向对象分析阶段，我们需要识别系统中的各种对象，并分析它们之间的关系和行为。

在这个案例中，我们可以识别出图书、读者、图书管理员、借阅记录等对象。

接下来，我们需要对每个对象进行分析，包括属性和方法的识别。

以图书对象为例，它可能包括书名、作者、出版社、ISBN号等属性，而方法可能包括借阅、归还等操作。

通过对每个对象的分析，我们可以建立起对象模型，明确对象之间的关系和交互方式。

在面向对象设计阶段，我们需要将对象模型转化为类和接口，定义类的属性和方法，以及类之间的继承和关联关系。

在图书馆管理系统中，我们可以定义图书类、读者类、图书管理员类等，通过继承和接口实现来建立它们之间的关系。

同时，我们还需要设计相应的界面和交互逻辑，确保系统能够满足用户的需求。

除此之外，面向对象分析设计还强调系统的可扩展性和可维护性。

在设计阶段，我们需要考虑到未来可能的变化和扩展，尽量降低系统的耦合度，提高系统的灵活性和可重用性。

在图书馆管理系统中，我们可以通过设计插件机制和扩展接口，来支持新的业务需求和功能扩展。

总的来说，面向对象分析设计是一种强调抽象、模块化和分层的方法论，它能够帮助我们理清系统的结构和功能，提高系统的设计质量和开发效率。

通过本文的案例介绍，相信读者对面向对象分析设计有了更深入的理解，能够在实际项目中更好地应用这一方法论。

面向对象分析与设计(8)-案例讲解

识别概念策略
使用概念目录列表找出概念根据名词或名词性短语找出概念
建立概念模型的指导原则
在所考虑的范围内，运用概念目录列表或者名词性短语策略找出问题域中的候选概念将这些概念绘制到概念模型图中在概念之间添加必要的关联在记录概念之间的联系为概念添加属性
概念模型— 概念模型—添加关联
关联是概念之间的一个有意义或者使人产生兴趣的连接识别出概念之间的关联，可以帮助理解概念模型
找出关联
通过关联列表找出关联通过动词、动词短语找出关联
关联原则
找出问题域中的概念远远比找出关联更为重要。建立概念模型时要把主要时间花费在识别出问题域中的概念上，而不是花费在识别关联上。
概念模型— 概念模型—添加属性
属性是某个对象的逻辑数据值概念模型中的属性应该是取简单属性或纯数据值。
迭代开发周期阶段中的步骤
分析阶段—如果正在处理的用例还没用扩展的基本用例格式写出，那么就要用扩展的基本格式将它们写出。设计阶段—如果正在处理的用例还没用真实用例格式写出，那么就要用真实格式将它们写出。
找出系统边界
系统边界是定义由谁或什么（即参与者）使用系统，系统能够为哪些参与者提供什么特定的利益（即用例）定义系统边界是一项重要活动，目的是为了能够识别出什么在系统之内以及什么在系统之外，进而识别出什么是系统的职责。
找出系统边界（续）
如果开发的是一个应用软件或者硬件设备，那么用这个软件或硬件的边界作为系统边界通常是合理的选择。如果从事企业过程重组或业务过程重组— 对过程或者机构进行重新组织以提高产品质量和竞争能力—那么选择整个企业作为系统边界是可取的。
识别参与者
参与者是直接与系统交互的事物所扮演的角色。识别参与者

面向对象分析与设计的实践与案例

面向对象分析与设计的实践与案例面向对象分析与设计(OOA/D)是一种软件工程方法，重点关注系统中的对象，并基于对象的概念和关系来开发软件。

OOA/D的目标是提高软件的可重用性、可维护性和可扩展性。

本文将介绍面向对象分析与设计的实践和案例。

1. OOA/D概述OOA/D是一个以对象为中心的软件开发方法，它提供了一个有效的工具来进行复杂系统的分析、设计和实现。

OOA/D的核心思想是将系统视为对象的集合，并通过设计对象之间的交互关系来构建软件系统。

这种方法的优势在于将系统的复杂性分解为小的部分，并帮助开发人员在系统中建立清晰的边界和层次结构。

OOA/D中有三个相关的概念：对象、类和关系。

对象表示一个具体的实体，类表示对对象进行抽象的概念，而关系定义了类或对象之间的相互作用。

2. OOA/D的过程OOA/D的过程可以分为以下几个步骤：2.1 需求收集和分析在这个阶段，开发人员需要与用户沟通，以确定系统的需求。

这是一个重要的阶段，因为它将帮助开发人员理解系统的实际需求。

2.2 建立系统模型在收集完需求之后，开发人员需要建立一个系统模型。

这个模型描述了系统的整体结构，以及对象之间的关系。

这个过程中可以使用UML(Unified Modeling Language)来表示系统模型。

2.3 确定类和对象在建立系统模型之后，开发人员需要确定所有的类和对象，并定义它们的行为。

这是建立一个可重用和可扩展的代码库的关键。

2.4 设计交互关系开发人员需要确定对象之间的交互关系。

这些交互关系可以使用UML来表示，并且需要确保考虑到了系统的所有需求。

2.5 实现和测试代码在确定了类、对象和关系后，开发人员需要实现和测试代码。

这个过程可以采用面向对象的编程语言来完成。

3. OOA/D的案例下面是一个OOA/D的案例：图书管理系统。

3.1 需求分析这个系统有两类用户：管理员和普通用户。

管理员可以添加、删除、修改和查询图书信息，普通用户可以查询图书信息。

面向对象程序分析与设计08

软件学院课程设计报告书课程名称面向对象分析与设计设计题目网络选课系统专业班级学号姓名指导教师2013年6 月目录1 设计时间 (1)2 设计目的 (1)3设计任务 (1)4 设计内容 (1)4.1 用例图 (1)4.2 用例描述 (4)4.3 网络选课系统中的类图 (6)4.4网上选课系统顺序图及协作图 (7)4.5 网上选课系统活动图 (10)5 总结与展望 (12)参考文献 (13)成绩评定 (13)图1学生用例图(2)教师用例图：查询个人信息、修改个人信息、查看考勤信息、查看学生选课信息、录入成绩、查询课程信息、查询公告等，如图2所示。

图2 教师用例图(3)管理员用例图：发布公告、学生管理、教师管理、课程管理、教师考勤录入、管理课程表、统计学生分数等，如图3所示。

图3 管理员用例图(4)教务处管理员：学生档案管理、教师档案管理、修改账户信息、发布公告、维护、权限管理等，如图4所示。

图4 教务处管理员(5)总体用例图：如图5所示。

4.3 网络选课系统中的类图从用例图中和系统分析说明中采用名词和实体识别法识别出：学生、教师、系办管理员、教务处管理员、课程、公告、课程这几个类。

在确定类的基础上，再进一步标识类之间的关系，建立网上选课类图如图6所示和网上选课界面类图如图7所示：图6 网上选课系统类图图7网上选课界面类图4.4网上选课系统顺序图及协作图根据系统功能，UML文档绘制了教师成绩信息管理的的顺序图如图8所示及协作图如图所示、教务处管理员设置权限顺序图及协作图、系办管理员发布课程表顺序图如图9所示及协作图、学生选课的顺序图如图10所示及协作图如图11所示，教师成绩信息管理的的顺序图及协作图。

图8 教师管理成绩顺序图图9管理员修改信息顺序图图10学生退选课顺序图图11 学生选课协作图教师成绩信息管理的的顺序图如图4-12所示及协作图:: 教师登录界面成绩管理界面学生成绩信息2: 身份验证1: 登录3: 通过验证4: 进入成绩管理界面7: 提交成绩信息9: 退出成绩管理界面5: 录入成绩信息6: 查询成绩信息8: 存入数据库图4-12 教师管理成绩协作图4.5 网上选课系统活动图：（1）用户登陆界面活动图，如图13所示。

C++面向对象程序设计举例

C++⾯向对象程序设计举例【例8.1】最简单的例⼦。

#include <iostream>using namespace std;class Time //定义Time类{public : //数据成员为公⽤的int hour;int minute;int sec;};int main( ){Time t1;//定义t1为Time类对象cin>>t1.hour;//输⼊设定的时间cin>>t1.minute;cin>>t1.sec;//输出时间:cout<<t1.hour<<":"<<t1.minute<<":"<<t1.sec<<endl;return0;}运⾏情况如下：1232 43↙12:32:43⼏点注意：1) 在引⽤数据成员hour，minute，sec时不要忘记在前⾯指定对象名。

2) 不要错写为类名，如写成Time.hour,Time.minute,Time.sec是不对的。

因为类是⼀种抽象的数据类型，并不是⼀个实体，也不占存储空间，⽽对象是实际存在的实体，是占存储空间的，其数据成员是有值的，可以被引⽤的。

3) 如果删去主函数的3个输⼊语句，即不向这些数据成员赋值，则它们的值是不可预知的。

【例8.2】引⽤多个对象的成员。

1）程序(a)#include <iostream>using namespace std;class Time{public :int hour;int minute;int sec;};int main( ){Time t1;//定义对象t1cin>>t1.hour;//向t1的数据成员输⼊数据cin>>t1.minute;cin>>t1.sec;cout<<t1.hour<<":"<<t1.minute<<":"<<t1.sec<<endl;//输出t1中数据成员的值Time t2;//定义对象t2cin>>t2.hour;//向t2的数据成员输⼊数据cin>>t2.minute;cin>>t2.sec;cout<<t2.hour<<":"<<t2.minute<<":"<<t2.sec<<endl;//输出t2中数据成员的值return0;}运⾏情况如下：1032 43↙10:32:4322 32 43↙22:32:43程序是清晰易懂的，但是在主函数中对不同的对象⼀⼀写出有关操作，会使程序冗长。

面向对象分析与设计大作业范例

《面向对象分析与设计》大作业范例(总91页)--本页仅作为文档封面，使用时请直接删除即可----内页可以根据需求调整合适字体及大小--《面向对象分析设计》大作业网上招聘系统分析设计专业：班级：学号：姓名：成绩：二〇一四年六月大连理工大学城市学院目录第一章网上招聘系统需求规格说明书...................... 错误!未定义书签。

第二章软件项目的概要设计说明书.......................... 错误!未定义书签。

第三章网上招聘系统详细设计 .................................... 错误!未定义书签。

第四章软件项目的编码案例说明............................... 错误!未定义书签。

第五章网上招聘系统客户端系统测试计划............. 错误!未定义书签。

第六章网上招聘系统客户端系统测试设计............. 错误!未定义书签。

第八章网上招聘系统客户端系统测试报告............. 错误!未定义书签。

第一章网上招聘系统需求规格说明书1.导言目的该文档是关于用户对于网上招聘系统的功能和性能的要求，重点描述了网上招聘系统的功能需求，是概要设计阶段的重要输入。

本文档的预期读者是：·设计人员；·开发人员；·项目管理人员；·测试人员；·用户。

范围该文档是借助于当前系统的逻辑模型导出目标系统的逻辑模型的，解决整个项目系统的“做什么”的问题。

在这里，没有涉及开发技术，而主要是通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的平台。

编写说明HR,Human Resource（人力资源管理）的缩写。

JSP,Java Server Page（Java服务器页面）的缩写，一个脚本化的语言。

UML,Unified Modeling Language（统一建模语言）的缩写，是一个标准的建模语言。

面向对象案例分析

案例分析：《图书馆管理系统》一．系统描述：图书馆管理系统使对书记的借阅即读者信息进行统一管理的系统，具体包括读者的借书、还书、书籍订阅；图书馆管理员的书籍借出处理、书籍归还处理、预订信息处理；还有系统管理员的系统维护，包括增加书目、删除或更新书目、增加书籍、减少书籍、增加读者帐户信息、删除或更新读者帐户信息、书籍信息查询、读者信息查询等。

系统的总体信息确定以后，就可以分析系统的参与者、确定系统用例了。

二．确定系统的参与者：确定系统参与者首先需要分析系统所涉及的问题领域和系统运行的主要任务：分析使用该系统主要功能的是哪些人，谁需要该系统的支持以完成其工作，还有系统的管理者与维护者。

根据图书馆管理系统的需求分析，可以确定如下几点：✧作为一个图书馆管理系统，首先需要读者（借阅者）的参与，读者可以登录系统查询所需要的书籍，查到所需书籍后可以考虑预订，当然最重要的是借书、还书操作；✧对于系统来说，读者发起的借书、还书等操作最终还需要图书馆管理员来处理，他们还可以负责图书的预订和预订取消；✧对于图书馆管理系统来说，系统的维护操作也是相当重要的，维护操作主要包括增加书目、删除或更新书目、增加书籍、减少书籍等操作。

由以上分析可以得出，系统的参与者主要有3类：读者（借阅者）、图书馆管理员、图书馆关系系统维护者。

三．确定系统用例：1.借阅者请求服务的用例：1)登录系统；2)查询自己的借阅信息；3)查询书籍信息；4)预订书籍；5)借阅书籍；6)归还书籍。

2.图书馆管理员处理借书、还书等的用例：1)处理书籍借阅；2)处理书籍归还；3)删除预订信息。

3.系统管理员进行系统维护的用例：1)查询借阅者信息；2)查询书籍信息；3)增加书目；4)删除或更新书目；5)增加书籍；6)删除书籍；7)增加借阅者帐户；8)删除或更新借阅者帐户。

四．用例图：1)借阅者请求服务的用例：2)图书馆管理员处理借书、还书等的用例：3)系统管理员进行系统维护的用例：补充案例：《订货中心系统》一．系统简介：有这样一个订货中心，它接受客户的电话、传真、电子邮件、信件和web 主页表单形式的订货请求，形成货物订单，并告知客户订单的价钱。

案例--“图书管理系统”面向对象分析与设计

案例“图书管理系统”面向对象分析与设计例如，“图书管理系统”面向对象分析与设计大致过程如下：1.需求调查分析需求调查分析的结果一般用文字描述，必要时也可用业务流程图辅助描述。

“图书管理系统”需求陈述如下：在图书管理系统中，管理员要为每个读者建立借阅账户，并給读者发放不同类别的借阅卡（借阅卡可提供卡号、读者姓名），账户内存储读者的个人信息和借阅记录信息。

持有借阅卡的读者可以通过管理员（作为读者的代理人与系统交互）借阅、归还图书，不同类别的读者可借阅图书的范围、数量和期限不同，可通过互联网或图书馆内查询终端查询图书信息和个人借阅情况，以及续借图书（系统审核符合续借条件）。

借阅图书时，先输入读者的借阅卡号，系统验证借阅卡的有效性和读者是否可继续借阅图书，无效则提示其原因，有效则显示读者的基本信息（包括照片），供管理员人工核对。

然后输入要借阅的书号，系统查阅图书信息数据库，显示图书的基本信息，供管理员人工核对。

最后提交借阅请求，若被系统接受则存储借阅纪录，并修改可借阅图书的数量。

归还图书时，输入读者借阅卡号和图书号（或丢失标记号），系统验证是否有此借阅纪录以及是否超期借阅，无则提示，有则显示读者和图书的基本信息供管理员人工审核。

如果有超期借阅或丢失情况，先转入过期罚款或图书丢失处理。

然后提交还书请求，系统接受后删除借阅纪录，并登记并修改可借阅图书的数量。

图书管理员定期或不定期对图书信息进行入库、修改、删除等图书信息管理以及注销（不外借），包括图书类别和出版社管理。

2. 用况健模（1）确定执行者通过对系统需求陈述的分析，可以确定系统有两个执行者：管理员和读者。

简要描述如下：1)管理员：管理员按系统授权维护和使用系统不同功能，可以创建、修改、删除读者信息和图书信息即读者管理和图书管理，借阅、归还图书以及罚款等即借阅管理。

2)读者：通过互联网或图书馆查询终端，查询图书信息和个人借阅信息，还可以在符合续借的条件下自己办理续借图书。

基于UML的面向对象分析与设计案例

基于UML的面向对象分析与设计案例摘要本文以实例的方式，展示了如何使用UML进行面向对象的分析与设计。

本文将假设读者对UML、面向对象等领域的基本内容已了然于胸，所以将不会过多阐述，而将重点放在应用过程上。

本文的目的是通过一个完整的实例，展现基于UML的OOA&D过程的一个简化模式，帮助朋友们更好的认识UML在OOA&D中起的作用。

前言经常听到有朋友抱怨，说学了UML不知该怎么用，或者画了UML却觉得没什么作用。

其实，就UML本身来说，它只是一种交流工具，它作为一种标准化交流符号，在OOA&D过程中开发人员间甚至开发人员与客户之间传递信息。

另外，UML也可以看做是OO思想的一种表现形式，可以说“OO是神，而UML是型”。

所以，想用好UML，扎实的OO思想基础是必不可少的。

然而，在UML应用到开发过程中时，还是有一定的模式可以遵循的。

（注意，是模式而不是教条，我下面给出的流程只是一个启发式过程，而不是说一定要遵循这个流程。

）下面，我们通过一个CMS系统的分析设计实例，看看如何将UML应用到实际的开发中。

1.从需求到业务用例图OOA&D的第一步，就是了解用户需求，并将其转换为业务用例图。

我们的CMS系统需求非常简单，大致课做如下描述：这个系统主要用来发布新闻，管理员只需要一个，登录后可以在后台发布新闻。

任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后可对新闻进行评论。

管理员在后台可以对新闻、评论、注册会员进行管理，如修改、删除等。

通过以上需求描述，我们画出如下的业务用例图：这里要注意三点：1.业务用例是仅从系统业务角度关注的用例，而不是具体系统的用例。

它描述的是“该实现什么业务”，而不是“系统该提供什么操作”。

例如，在实际系统中，“登录”肯定要作为一个用例，但是这是软件系统中的操作，而用户所关注的业务是不包含“登录”的。

2.业务用例仅包含客户“感兴趣”的内容。

3.业务用例所有的用例名应该让客户能看懂，如果某个用例的名字客户看不懂什么意思，它也许就不适合作为业务用例。

面向对象建模案例

《信息系统分析与设计》课程之面向对象建模案例案例1 座位预订系统【案例描述】本系统要完成对飞机航班座位的预订工作。

座位预订问题有两个并发的输入，中央数据库包含有飞机中空闲座位的信息。

处于南京和北京的两个终端可以查询并更新中央数据库，这两个终端可以并行地运行。

为简单起见，假设中央数据库中只包含一个座位的信息，该座位要么已经被预订，要么还处于空闲状态。

这个小系统应能保证该座位要么被南京预订处预订，要么被北京预订处预订。

但是不能被这两处同时预订。

【案例分析】本系统的参与者为预订飞机座位。

参与者查询数据库是否有空闲。

如果有，那么它就通知用户有空闲的座位，并代表用户预订座位；否则，该系统将返回一条表明座位已经被别人预订的消息。

座位预定系统的用例图座位预定系统的活动图《UML与软件建模》清华大学出版社。

P234案例2 银行储蓄系统——存取款业务状态图【案例描述】出处：《软件工程概论》机械工业出版社。

P49-52 例3-1【案例分析】出处案例3 银行储蓄系统——用例图和类图【案例描述】出处：《软件工程概论》机械工业出版社。

P170-171 例7.1【案例分析】出处案例4 银行储蓄系统——取款活动图【案例描述】出处：《软件工程概论》机械工业出版社。

P176【案例分析】出处案例5 教学管理系统——类图【案例描述】《软件工程概论》机械工业出版社。

P172 例7.2【案例分析】出处案例6 选课系统【案例描述】出处：《软件工程概论》机械工业出版社。

P180-201 例8.1【案例分析】案例7 饭店管理系统——用例图【案例描述】本饭店管理系统向旅客和旅行社提供预订房间的业务。

在旅客达到饭店后，通过饭店管理系统进行住房登记。

在旅客离开时，为其办理退房手续。

【案例分析】根据案例描述得知：旅客和旅行社需要使用本系统。

在使用过程中，会与饭店管理系统交换信息。

因此，参与者Actor是：旅客和旅行社。

饭店管理系统要提供预订房间、住房登记和退房三项服务。