2、了n楼必须停下接收乘客. 如果电梯里已经没有乘客了,电梯应该留在原位置直到再次投入使用. 在将乘客送到目的地以前电梯不允许反向运动.(也就是电梯比如把乘客从9楼带到楼下,如果在走到4楼的时候5楼有人要下,电梯不能从4楼回5楼去,而要把乘客带到楼下再回来) 满载的电梯不再收人. 电梯里有个按钮面版,里面有10个楼层的按钮. 按下按钮表示该楼层变成一个目的地,按钮会发光,到达以后按钮不再发光. 建筑物2-9楼层有一个按钮面版,上面两个按钮分别是向上和向下.1楼只有向上,10楼只有向下. 电梯有
3、一个控制中心来自动控制,不用人手干预. ...............(其他,略) 第二部分 到底上面的需求描述中,哪些东西可以成为我需要来 "面向"的"对象"? 首先,我们要选择出候选的对象,然后再在候选对象里选择真正为程序设计所使用的对象. 候选对象的选择有很多方式,比方说"名词短语频率分析",对上面那段去分析看哪些名词出现次数很多,说明可能比较重要,可以直接拿来当候选对象. 比如楼层,电梯,按钮,乘客,都出现很多次. 当然还有另外的方式,比如"按方面建立" (PS: I'm sorry,我是
4、个实用主义者,只要目的达到了...我不喜欢像一些书本上那样用些概念糊弄人,上面红字的两个方法的名称是我临时取的.....也许不好听,也许他们有更优美的名字.....反正这不是我们该担心的,留给教材编写人员取操心吧...) 从 人组织设备物品业务事件表格 几个方面去找对象去. 这里要注意的是对象的选择要看具体情况的,比如 .... 我们把 "放飞希望" 作为一个具体的对象实例 ( ^_^ ), 如果在医疗系统中,可以抽象成 "人" 这个类,由 脑袋身体手脚......等部分.
5、 如果是在教育管理系统中, 就不能这么处理,可能要抽象成 "老师" 这个类, 包括 教学年限工资所教科目..... 等内容. 还有一点需要注意的是不要跨过系统边界. 系统之外的事情就不要管了,就说我们这个电梯调度, 电梯的生产日期啊什么的,还有乘客的姓名, 都根本雨系统无关,这些是不需要的. 最后有一点被非常非常非常非常非常多的工程师们所忽视的就是建立面向对象分析模型的时候, 只应该考虑逻辑,而不要去考虑跟实现技术相关的东西. 比如按钮是塑料的还是金属的, (当然这个很明显是分外的事,大多数人在
6、做调度分析的时候不会考虑这个,不过有些情况却很隐蔽..) 现在回到我们具体问题,假设现在我们列出来的初步的清单是这样的(可能100个人有100个列法,不过没关系,这是正常的...): 电梯电梯门电梯位置乘客目的地按钮大楼..... 这离真正可以用的对象还差很多, 我们需要对每个词进行分析,看看到底是不是,值得不值得把这个当一个对象来考虑.我们分析从以下几个方面看: 它在系统里有功能吗? (比如电梯天花板 就该删除掉....如果有的话....) 其他对象需要这个对象帮忙做点什么事吗? (比
7、如乘客需要电梯把他带上去...) 其他对象需要这个对象的数据吗?(比如控制中心明显需要知道电梯现在在哪..) 这个对象是不是包含了有用却不对别的对象公开的内容.(比如电梯上面的吊链和发动机明显是有用的,不然电梯无法动也就无法调度了, 但是明显对于其他对象,都是不需要公开的, 不管是乘客还是控制中心都不需要控制电梯的马达---这里可能有人要有意见了, 控制中心不控制电梯马达么? 答案是不该控制,控制中心应该只告诉电梯你要向上还是向下还是停, 至于马达转多快怎么转,是电梯自己的电路来控制的才对, 责任
8、分开明确有利于系统的维护.) 这个对象有没有一个生存期,是不是描述了 产生--各种运行状态--消亡 的信息.比如一次电梯召唤-(谁想个好听点的名字? 呵呵....) 产生是用户按了向上或向下的按钮. 然后进入 "电梯来" 这个状态, 再进入电梯停(包括开门,乘客进去,关门)的状态,然后又是 "电梯走" 的状态,再之后是电梯再停给用户下去,然后这个电梯召唤以电梯停止移动等待下次召唤作为结束. 如果向应用领域的专家(这里比如是电梯工程师)描述这个对象,
