《面向对象的思想和UML的方法.ppt》由会员分享，可在线阅读，更多相关《面向对象的思想和UML的方法.ppt（84页珍藏版）》请在金锄头文库上搜索。
1、面向对象的思想和面向对象的思想和UML的方法的方法讲述一个软件的生命讲述一个软件的生命关于本课的学习建议首先考虑同学们对学习的辛苦和疲惫，所以采用轻松的教学方法，既学到了知识，又能通过考试本课的简短说明：本课程是一个系统架构师的专业课程，但是现在引入是为同学们能够学习软件架构服务的，所以不要求同学们钻的太深，知道，理解，简单的画图和引用就可以了！课本的内容是按照一个设计的过程，也就是一个软件的生命周期讲解的，内容从场景切入并告诉我们通过UML怎样和一个项目结合，所以重点学习两点，第一是UML思想的引用，第二UML与程序的结合本学期我的想法：首先：理论的知识尽可能少，多以实际的知识，结合课本，其
2、次：理论课中百分之50是理论，50%是实践知识，另加10%的课外知识关于本课的学习建议其次：上节课以课本为主，学习课本中的操作，并且系统教学资料，以自学为主，通过独立的阅读和操作掌握这门课的思想。最后从简单的角度入手分析我们的课程。说明：UML面向对象分析与设计的内容庞大复杂，属于软件工程，不可能用短短的一学期时间学会，所以重点以简单的了解以及一些知识的引导，对那些想从事软件工程设计方面的同学提供捷径，对于不想从事的，作为一个了解也是有益而无害的。教学途中，如果有什么想法或者建议，特别是想要学一些其他什么，都可以发Email给我，我会尽力满足同学们，Email：资料提供：在上一学期都有讲授以下
3、内容，同学们作为参考：心理，交际，礼仪，哲学，软件思想，新技术等内容四大发明之活字印刷四大发明之活字印刷面向对象思想的胜利面向对象思想的胜利 话说三国时期，曹操带领百万大军攻打东吴，大军在长江赤壁驻扎，军船连成一片，眼看就要灭掉东吴，统一天下，曹操大悦，于是大宴众文武，在酒席间，曹操诗性大发，不觉吟道：“喝酒唱歌，人生真爽。”。众文武齐呼：“丞相好诗！”于是一臣子速命印刷工匠刻版印刷，以便流传天下。四大发明之活字印刷四大发明之活字印刷面向对象思想的胜面向对象思想的胜利利 样张出来给曹操一看，曹操感觉不妥，说道：“喝与唱，此话过俗，应改为对酒当歌较好！”，于是此臣就命工匠重新来过。工匠眼看连夜刻
4、版之工，彻底白费，心中叫苦不喋。只得照办。四大发明之活字印刷四大发明之活字印刷面向对象思想的胜面向对象思想的胜利利 样张再次出来请曹操过目，曹操细细一品，觉得还是不好，说：“人生真爽太过直接，应改问语才够意境，因此应改为对酒当歌，人生几何？！”当臣转告工匠之时，工匠晕倒！四大发明之活字印刷四大发明之活字印刷面向对象思想的胜面向对象思想的胜利利 可惜三国时期活字印刷还未发明，所以类似事情应该时有发生，如果是有了活字印刷。则只需更改四个字就可，其余工作都未白做。实在妙哉。四大发明之活字印刷四大发明之活字印刷面向对象思想的胜面向对象思想的胜利利 第一，要改，只需更改要改之字，此为可维护可维护；第二，
5、这些字并非用完这次就无用，完全可以在后来的印刷中重复使用，此乃可复用可复用；第三，此诗若要加字，只需另刻字加入即可，这是可扩可扩展展；第四，字的排列其实有可能是竖有可能是横排，此时只需将活字移动就可做到满足排列需求，此是灵活性好灵活性好。四大发明之活字印刷四大发明之活字印刷面向对象思想的胜面向对象思想的胜利利 而在活字印刷术之前，上面的四种特性都无法满足，要修改，必须重刻，要加字，必须重刻，要重新排列，必须重刻，印完这本书后，此版已无任何可再利用价值。做了软件开发几年后，经历了太多的客户（曹操）改变需求，更改最初想法的事件，才逐渐明白当中的道理。其实客观的说，客户的要求也并不过份（改几个字而已
6、），但面对已完成的程序代码，却是需要几乎重头来过的尴尬，这实在是痛苦不堪。说白了，原因就是因为我们原先所写的程序，不容易维护，灵活性差，不容易扩展，更谈不上复用，因此面对需求变化，加班加点，对程序动大手术的那种无耐也就非常正常的事了。四大发明之活字印刷四大发明之活字印刷面向对象思想的胜面向对象思想的胜利利 之后当我学习了面向对象分析设计编程思想，开始考虑通过封装、继承、多态把程序的耦合度降低通过封装、继承、多态把程序的耦合度降低（传统印刷术的问题就在于所有的字都刻在同一版面上造成耦合度太高所制），开始用设计模式使得程序更加的用设计模式使得程序更加的灵活，容易修改，并且易于复用灵活，容易修改，并
7、且易于复用。体会到面向对象带来的好处，那种感觉应该就如同是一中国酒鬼第一次喝到了茅台，西洋酒鬼第一次喝到了XO一样，怎个爽字可形容呀。再次回顾中国古代的四大发明，另三种应该都是科技的进步，伟大的创造或发现。而唯有活字印刷，实在是思想的成功，面向对象的胜利。不知您是否也有所感呢？面向对象（OBJECT-ORIENTED;简称：OO）至今还没有统一的概念，我这里把它定义为：按人们认识客观世界的系统思维方式，采用基于对象（实体）的概念建立模型，模拟客观世界分析、设计、实现软件的办法。通过面向对象的理念使计算机软件系统能与现实世界中的系统一一对应。面向对象方法(Object-OrientedMetho
8、d)是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法，简称OO(Object-Oriented)方法，是建立在“对象”概念基础上的方法学。对象是由数据和容许的操作组成的封装体，与客观实体有直接对应关系，一个对象类定义了具有相似性质的一组对象。所谓面向对象就是基于对象概念，以对象为中心，以类和继承为构造机制，来认识、理解、刻画客观世界和设计、构建相应的软件系统。面向对象方法将会大更深、吏广、更高的方向上取得进展：（1）更深的方向：如OO方法的理论基础和形式化描述；用OO技术设计出新一代OS等。（2）更广的方向：如面向对象的知识表示；面向对象的仿真系统；面向对象的多媒体系统；面向
9、对象的灵境系统等。（3）更高的方向：如从思维科学的高度来丰富OO方法学的本质属性，突破现有的面向对象技术的一些局限、研究统一的面向对象的范式等。对象（OBJECT）即指现实世界中各种各样的实体。它可以指具体的事物也可以指抽象的事物。如：整数1、2、3、流氓陈水扁、苹果、飞机、规则、法律、法规、表单等等。每个对象皆有自己的内部状态和运动规律，如流氓陈水扁具有名字、身高、体重等内部状态，具有吃饭、睡觉、打人、偷税、漏税等运动规律。在面向对象概念中我们把对象的内部状态称为属性、运动规律成为方法或事件。对象既可以是具体的物理实体的对象，也可以是人为的概念，或者是任何有明确边界和意义的东西。比如：一名员
10、工、一家公司、贷款与借款等，都可以作为对象面向对象关注什么？关注的是对象的行为，面向对象是使用行为来对对象进行分类的！61条面向对象设计的经验原则条面向对象设计的经验原则“你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。”“你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。”-ArthurJ.RielArthurJ.Riel从事C和C+编程工作已有超过12年的经验，目前，他每年在学术界和产业界讲授40多次课程。他参与了许多系统的开发，曾就职于AT&T贝尔
11、实验室、Draper实验室、IBN、东北大学。他还在JournalofObject-OrientedProgrting，TheC+Insider、TheC/C+Gazette等刊物上发表了众多文章。61条面向对象设计的经验原则条面向对象设计的经验原则(1)所有数据都应该隐藏在所在的类的内部。p13(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。p15(3)尽量减少类的协议中的消息。p16(4)实现所有类都理解的最基本公有接口例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等。p16(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口
12、中。p17如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。61条面向对象设计的经验原则条面向对象设计的经验原则(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。p17(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。p18(8)类应该只表示一个关键抽象。p19包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响.(9)把相关的数据和行为集中放置。p19设计者应当留意那些通过get之类操作从别的对象中获取数据的对象
13、。这种类型的行为暗示着这条经验原则被违反了。61条面向对象设计的经验原则条面向对象设计的经验原则l(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。p19朝着稳定的方向进行依赖.l(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。p23l(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。p30l(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。p30规划一个接口而不是实现一个接口。61条面向对象设计的经验原则条面向对象设计的经验原则(14)对公共接口中
14、定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。p30(15)对包含太多互不沟通的行为的类多加小心。p31这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。p33(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则)。p3661条面向对象设计的经验原则条面向对象设计的经验原则(18)从你的设计中去除不需要的类。p38一般来说，我们会把这个类降级成一个属性(
15、19)去除系统外的类。p39系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。p4061条面向对象设计的经验原则条面向对象设计的经验原则(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。p43(22)尽量减少类的协作者的数量。p52一个类用到的其他类的数目应当尽量少。(23)尽量减少类和协作者之间传递的消息的数量。p55(24)尽量减少类
16、和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。p55(25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。p55(26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。p5561条面向对象设计的经验原则条面向对象设计的经验原则(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。p57(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。p57当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。(29)让系统功能在窄而深的
17、继承体系中垂直分布。p58(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。p60(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。p60(32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。p6061条面向对象设计的经验原则条面向对象设计的经验原则(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。p60(34)类必须知道它包含什么，但是不能知道谁包含它。p61(35)共享字面范围(也就是被同一个
18、类所包含)的对象相互之间不应当有使用关系。p61(36)继承只应被用来为特化层次结构建模。p74(37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。p74(38)基类中的所有数据都应当是私有的，不要使用保护数据。p75类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。61条面向对象设计的经验原则条面向对象设计的经验原则(39)在理论上，继承层次体系应当深一点，越深越好。p77(40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。P77(41)所有的抽象类都应当是基类。p81(42)所有的基类都应当是抽象类。p82(43)
19、把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。p85(44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。p8861条面向对象设计的经验原则条面向对象设计的经验原则(45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。P89(46)如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。p89(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多
20、态。p89(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。p96(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。p9761条面向对象设计的经验原则条面向对象设计的经验原则(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。p99(51)如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。p103(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。p103(53)不要把可选包
21、含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。p108(54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。p112(55)如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。p12061条面向对象设计的经验原则条面向对象设计的经验原则(56)只要在面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型？(2)基类是不是派生类的一部分？p121(57)如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。p122(58)在面向对象设计中如果你需要在包含关系和关联关系
22、间作出选择，请选择包含关系。p135(59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。p140(60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。p149(61)不要绕开公共接口去修改对象的状态。p164-ArthurJ.Riel类（CLASS）：类是具有相似内部状态和运动规律的实体的集合（或统称、抽象）。类的概念来自于人们认识自然、认识社会的过程。、主要使用两种方法：由特殊到一般的归纳法和由一般到特殊的演绎法。在归纳的过程中，我们从一个个具体的事物中把共同的特征抽取出来，形成一个一般的概念，
23、这就是归类；如：昆虫、狮子、爬行动物，因为它们都能动所以归类为动物。在演绎的过程中我们又把同类的事物，根据不同的特征分成不同的小类，这就是分类；如动物-猫科动物-猫-大花猫等。对于一个具体的类，它有许多具体的个体，我们就管这些个体叫做对象。类（CLASS）：类的内部状态是指类集合中对象的共同状态；类的运动规律是指类集合中对象的共同运动规律。如：博拉图对人作如下定义：人是没有毛能直立行走的动物。在博拉图的定义中人是一个类，具有没有毛、直立行走等一些区别于其它事物的共同特征；而张三、李四、王五、流氓陈水扁等一个个具体的人，是人这个类的一个个对象。类是对象的模板。即类是对一组有相同数据和相同操作的对
24、象的定义，一个类所包含的方法和数据描述一组对象的共同属性和行为。类是在对象之上的抽象，对象则是类的具体化，是类的实例。类可有其子类，也可有其它类，形成类层次结构。通俗的讲：类是对具有相同属性和行为的一组相似的对象的抽象。类（CLASS）：例如生物学上会根据某一个标准将生物分为动物和植物两大类，然后再根据其它的一些标准将动物又分为鱼类、爬行动物类、两栖动物类等不同的种类，类（CLASS）：说到这里，可能大家会欢呼：原来面向对象的类就是分类，太好了！我最擅长这个了！别高兴的太早，谁知道面向对象的分类标准是什么吗？是生物学的标准，还是能不能爬树的标准？不同的标准，导致分类的结果完全不同，如下图所示：
25、方法：方法就是对象所能执行的操作，也就是类中所定义的服务。方法描述了对象执行操作的算法，响应消息的方法。属性：属性是类中所定义的数据，它是对客观世界实休所具有的性质的抽象。类的每个实例都有自己特有的属性值。比如姓名、性别就可以作为员工的属性而出现。ABSTRACTCLASS：抽象类，其不能用以创建对象实例，只能作为创建其子类的一个模板而存在。比如“线”是“直线”与“曲线”的抽象类。类与类之间的关系：依赖（Dependency）：两个事物间的语义关系，其中一个事物发生了变化会影响到另一个事物。关联（Association）：是一种结构关系，它描述了一组链，链是对象之间的连接。比如一个人为一家公司
26、工作（WorksFor），这里WorksFor就是一个关联。链接（link）：是对象之间物理上或概念上的连接。例如：张三为微软公司工作（WorksFor），这里WorksFor就是一个链接。类与类之间的关系：聚合（Aggregation）：其是一种特殊形式的关联。表示整体与部分的关系。比如项目组与其各成员之间的关系就是一种聚合关系。组合关系（Composition）：其也是一种特殊形式的关联。表示整体拥有各个部分，部分与整体共存。比如一个窗口是由文本框、列表框、菜单等组成的。关闭窗口，各个组成部分也相继消失，窗口与其各组成部分之间的关系便是组合关系。Ao对象中FeatureClass与Feat
27、ure之间就是一种组合关系。类与类之间的关系：泛化（Generalization）：其是一种特殊/一般关系，特殊元素（子元素）/的对象可替代一般元素（父元素）的对象。也称为“Isa关系”。实现（Realization）：是类元之间的语义关系，其中一个类元指定了由另一个类元保证执行的契约。类与类之间的关系：实例：实例就是由某个特定的类所描述的一个具体的对象。比如汽车就是交通工具的一个实例。实际上类是建立对象时使用的“模板”，按照这个模板所建立的一个个具体的对象，就是类的实际例子，简称实例。注意：当使用“对象”这个术语时，即可以指一个具体的对象，也可以泛指一般的对象，但是，当使用“实例”这个术语时
28、，必然是指一个具体的对象。类与类之间的关系：消息（Message）:消息是指对象间相互联系和相互作用的方式。一个消息主要由5部分组成：发送消息的对象、接收消息的对象、消息传递办法、消息内容（参数）、反馈。消息是对象之间进行通信的一种规格说明。一般它由三部分组成：接收消息的对象、消息名及实际变元。类的特性：类的定义决定了类具有以下5个特性：抽象、继承、封装、重载、多态。抽象：类的定义中明确指出类是一组具有内部状态和运动规律对象的抽象，抽象是一种从一般的观点看待事物的方法，它要求我们集中于事物的本质特征（内部状态和运动规律），而非具体细节或具体实现。面向对象鼓励我们用抽象的观点来看待现实世界，也就
29、是说，现实世界是一组抽象的对象类组成的。类的特性l继承：继承是类不同抽象级别之间的关系。类的定义主要有2种办法归纳和演绎；由一些特殊类归纳出来的一般类称为这些特殊类的父类，特殊类称为一般类的子类，同样父类可演绎出子类；父类是子类更高级别的抽象。子类可以继承父类的所有内部状态和运动规律。l继承性是子类自动共享父类之间数据和方法的机制。它由类的派生功能体现。一个类直接继职其它类的全部描述，同时可修改和扩充。继职具有传达室递性。继职分为单继承（一个子类只有一父类）和多重继承（一个类有多个父类）。类的对象是各自封闭的，如果没继承性机制，则类对象中数据、方法就会出现大量重复。继承不仅支持系统的可重用性，
30、而且还促进系统的可扩充性。l继承性使得相似的对象可以共享程序代码和数据结构，从而大大减少了程序中的冗余信息。l比如C#语言中，一个类继承另一个类时只能是单继承，而C+语言中就允许一个类继承多个类。类的特性封装：面向对象的类是封装良好的模块，类定义将其说明（用户可见的外部接口）与实现（用户不可见的内部实现）显式地分开，其内部实现按其具体定义的作用域提供保护。类是封装的最基本单位。封装防止了程序相互依赖性而带来的变动影响。在类中定义的接收对方消息的方法称为类的接口。封装是一种信息隐蔽技术，它体现于类的说明，是对象的重要特性。封装使数据和加工该数据的方法（函数）封装为一个整体，以实现独立性很强的模块
31、，使得用户只能见到对象的外特性（对象能接受哪些消息，具有那些处理能力），而对象的内特性（保存内部状态的私有数据和实现加工能力的算法）对用户是隐蔽的。封装的目的在于把对象的设计者和对象者的使用分开，使用者不必知晓行为实现的细节，只须用设计者提供的消息来访问该对象。封装：所谓封装就是把某个事物包装起来，使外界不知道该事物的具体内容。其通过向外界提供接口的形式而存在。比如打开电视机，它提供的是一个打开/关闭按钮，其实际内容，究竟怎样让电视播放我们是不知道的。我们也不必关心那么多，我们只要知道通过这个动作能实现我们想要的功能就行了。通过封装，我们很好地实现了细节对外界的隐藏，从而达到数据说明与操作实现
32、分离的目的，使用者只需要知道它的说明即可使用它。类的特性l多态（覆盖）：多态性是指同名的方法可在不同的类中具有不同的运动规律。l对象根据所接收的消息而做出动作。同一消息为不同的对象接受时可产生完全不同的行动，这种现象称为多态性。例如：Print消息被发送给一图或表时调用的打印方法与将同样的Print消息发送给一正文文件而调用的打印方法会完全不同。多态性机制不仅增加了面向对象软件系统的灵活性，进一步减少了信息的冗余。总结OO方法的作用和意义决不只局限于编程技术，它是一种新的程序设计范型-面向对象程序设计范型；是信息系统开发的新方法论-面向对象方法学；是正在兴起的新技术-面向对象技术。面向对象程序
33、设计范型：程序设计范型（以下简称程设范型）具体指的是程序设计的体裁，正如文学上有小说、诗歌、散文等体裁，程序设计体裁是用程序设计语言表达各种概念和各种结构的一套设施。简而言之，面向对象程设范型具有其它范型所缺乏或不具备的特点，极富生命力，能够适应复杂的大型的软件开发。可以肯定地说，这种新的程设范型必将有力地推动软件开发的新的进展。用OO方法进行面向对象程序设计，其基本步骤如下：l（1）分析确定在问题空间和解空间出现的全部对象及其属性；l（2）确定应施加于每个对象的操作，即对象固有的处理能力；l（3）分析对象间的联系，确定对象彼此间传递的消息；l（4）设计对象的消息模式，消息模式和处理能力共同构
34、成对象的外部特性；l（5）分析各个对象的外部特性，将具有相同外部特性的对象归为一类，从而确定所需要的类；l（6）确定类间的继承关系，将各对象的公共性质放在较上层的类中描述，通过继承来共享对公共性质的描述；l（7）设计每个类关于对象外部特性的描述；l（8）设计每个类的内部实现（数据结构和方法）；l（9）创建所需的对象（类的实例），实现对象间应有的联系（发消息）。面向对象分析的过程包括：1、从用例中提取实体对象和实体类。提取实体对象的方法，依据用例描述中出现的名词和名词短语来提取实体对象，必须对原始的名词和名词短语进行筛选。得到实体对象后，对实体对象进行归纳、抽象出实体类。2、提取属性3、提取关系
35、4、添加边界类5、添加控制类6、绘制类图7、绘制顺序图8、编制术语表UML简单结构软件生命周期模型软件生命周期模型:瀑布模型瀑布模型瀑布模型要求软件开发严格按照需求-分析-设计-编码-测试的阶段进行,每一个阶段都可以定义明确的产出物和验证准则.瀑布模型在每一个阶段完成后都可以组织相关的评审和验证,只有在评审通过后才能够进入到下一个阶段.螺旋模型螺旋模型首先螺旋模型是遵从瀑布模型的.即需求-架构-设计-开发-测试的路线.螺旋模型最大的价值在于整个开发过程是迭代和风险驱动的.通过将瀑布模型的多个阶段转化到多个迭代过程中,以减少项目的风险.螺旋模型的每一次迭代都包含了以下六个步骤1.决定目标,替代方
36、案和约束2.识别和解决项目的风险3.评估技术方案和替代解决方案4.开发本次迭代的交付物和验证迭代产出的正确性.5.计划下一次迭代6.提交下一次迭代的步骤和方案.关于选择生命周期模型的最后的总结1.在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型.2.在用户无信息系统使用经验,需求分析人员技能不足情况下一定要借助原型.3.在不确定性因素很多,很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型4.在需求不稳定情况下尽量采用增量迭代模型5.在资金和成本无法一次到位情况下可以采用增量模型,软件产品分多个版本进行发布6.对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循
37、瀑布模型7.对于全新系统的开发必须在总体设计完成后再开始增量或并行.8.对于编码人员经验较少情况下建议不要采用敏捷或迭代等生命周期模型.9.增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则.UML的图论观点的图论观点 数学中，有关“数学抽象度”的研究表明：抽象层次越高，切近事物本质越深。UML的图论观点，从更抽象的“图论”角度理解UML的语法，因此能够“切近事物本质更深”。UML2.0即将全面到来，改动虽大，但决不会跳出图论范畴；总之，理解了UML的图论观点，对快速掌握UML新规范大有裨益UML作为可视化建模语言，包括语法和语义两个方面。单从语法方面，用图论的眼光把
38、UML看作顶点和边来学习UML，应当说是正本清源之道。下表以图论观点对UML语法进行了总结。如下图面向对象的三个基本特征面向对象的三个基本特征面向对象的三个基本特征是：封装、继承、多态。泛化（GENERALIZATION）在下图中，空心的三角表示继承关系（类继承），在UML的术语中，这种关系被称为泛化（Generalization）。Person(人)是基类，Teacher(教师)、Student(学生)、Guest(来宾)是子类。若在逻辑上B是A的“一种”，并且A的所有功能和属性对B而言都有意义，则允许B继承A的功能和属性。例如，教师是人，Teacher是Person的“一种”（akindo
39、f）。那么类Teacher可以从类Person派生（继承）。如果A是基类，B是A的派生类，那么B将继承A的数据和函数。如果类A和类B毫不相关，不可以为了使B的功能更多些而让B继承A的功能和属性。若在逻辑上B是A的“一种”（akindof），则允许B继承A的功能和属性。聚合（组合）若在逻辑上A是B的“一部分”（apartof），则不允许B从A派生，而是要用A和其它东西组合出B。例如，眼（Eye）、鼻（Nose）、口（Mouth）、耳（Ear）是头（Head）的一部分，所以类Head应该由类Eye、Nose、Mouth、Ear组合而成，不是派生（继承）而成。聚合的类型分为无、共享(聚合)、复合(组
40、合)三类。聚合（AGGREGATION）上面图中，有一个菱形（空心）表示聚合（aggregation）（聚合类型为共享），聚合的意义表示has-a关系。聚合是一种相对松散的关系，聚合类B不需要对被聚合的类A负责。组合（COMPOSITION）这幅图与上面的唯一区别是菱形为实心的，它代表了一种更为坚固的关系组合（composition）（聚合类型为复合）。组合表示的关系也是has-a，不过在这里，A的生命期受B控制。即A会随着B的创建而创建，随B的消亡而消亡。依赖(DEPENDENCY)这里B与A的关系只是一种依赖(Dependency)关系，这种关系表明，如果类A被修改，那么类B会受到影响。用
41、户模型包含以下概念：场景场景该场景涉及一个简单的安全组件，此组件支持Web登录和受控制的在线资源访问。每个资源的所有者可以定义谁能够访问该资源。从业务的角度看，此组件具有三个主要功能：设置谁可以访问每个资源登录和访问所需资源记录哪些用户在访问每个资源，用于审核目的用户角色用户角色第一步是确定谁将使用该解决方案，用户角色描述一群具有相似需要和职责的用户。用户角色可以表示用户组织中将大量使用该解决方案的特定工作。或者，用户角色可以具有更细的粒度，仅包括执行不同类型的工作但需要以相似方式使用该解决方案的人员的一个共同工作方面。用户模型包含许多用户角色。用户角色应该基于用户群体的实际情况，而不是精心设
42、计以匹配解决方案本身的设计。在我们的安全组件场景中，存在拥有资源的人员和使用资源的人员。其中每个群体分别称为“资源所有者”和“业务用户”。用户角色涵盖用户工作的一个方面，而不是代表某项完整的工作。用户角色不是互斥的。有些人可以是一个资源的资源所有者和另一个资源的业务用户。资源所有者甚至可以是他或她自己的资源的业务用户。只要某个个人一次仅扮演单个用户角色，就足以对这些用户角色进行区分了。另一个用户角色是“审核员”，负责检查审核记录以确定谁正在访问每个资源。最后，您需要考虑：谁将设置该解决方案？谁将确保该解决方案保持运行？谁将调查该解决方案的问题？谁将扩展该解决方案？安全组件具有以下用户角色：资源
43、所有者资源所有者负责确保正确的用户获得对他们拥有的资源的访问权限业务用户业务用户负责使用适当的资源来执行业务审核员审核员负责安全策略的定义（和对这些策略的遵从性）IT 管理员管理员IT系统（包括该安全组件）的可用性部署人员部署人员负责经过测试的软件版本的初始部署开发人员开发人员负责向该组件添加新功能并修复代码中的缺陷测试工程师测试工程师负责验证该组件的编码是正确的解决方案架构师解决方案架构师负责选择应该使用该组件的场合用户角色用户角色每个用户角色在该用户模型中使用一个将构造型设置为的UML类来表示。该构造型显示在UML类的顶部，并带有一个图标。还为该UML类指定了一个构造型为的属性。此属性的名
44、称是对该用户角色的简短描述，并标记有图标。图1显示了一个使用UML类来定义的用户角色的示例。图图 1. 使用使用 UML 类定义的用户角色类定义的用户角色确定用户目标确定用户目标每个用户角色应该至少定义一个用户目标。用户目标定义用户角色尝试达到的最终状态或目的。图2显示了“资源所有者”(ResourceOwner)用户角色的用户目标示例。图图 2. 资源所有者的用户目标资源所有者的用户目标该用户目标的名称是“资源所有者”希望达到的状态。存在一个提供简短描述的属性、一个或多个属性()，并可选地存在一个或多个属性()。属性描述用户角色将如何测量该用户目标是否成功实现。在适当的情况下，还可以对表示成
45、功的测量成果级别进行建模。这是在属性中提供的。聚合关联。定义了用户目标以后，就可以使用与构造型的聚合关系来将该目标与适当的用户角色联系起来。将其称为主要目标是为了强调我们仅在对驱使用户角色使用该解决方案的原因进行建模。图3显示了该用户角色与该用户目标之间的聚合关联。类的特性l重载：重载指类的同名方法在给其传递不同的参数是可以有不同的运动规律。在对象间相互作用时，即使接收消息对象采用相同的接收办法，但消息内容的详细程度不同，接收消息对象内部的运动规律也可能不同。l如老板指派采购员买东西，当老板没有指明买什么时，采购员可能默认买地瓜；如老板指明要采购员买大米，采购员可能到最近的超市买10斤大米；如
46、老板指明采购员今天晚上到福州东街口买5斤大米，那采购员将不得不按老板指定的时间、地点去购买5斤大米。函数重载是指在同一作用域内的若干参数特征不同的函数可以使用的函数名字；运算符重载是指同一个运算符可以施加于不同类型的操作数上面。重载对于提高系统的灵活性和可读性起到了很好的作用。包：哲学认为现实世界中不同对象间的相互联系和相互作用构成了各种不同的系统，不同系统间的相互联系和相互作用构成了更庞大的系统，进而构成了整个世界。在面向对象概念中把这些系统称为包。包的接口类：在系统间相互作用时为了蕴藏系统内部的具体实现，系统通过设立接口界面类或对象来与其他系统进行交互；让其他系统只看到是这个接口界面类或对
47、象，这个类在面向对象中称为接口类。计算机与软件哲学中寻找答案【神秘背后的真相】软件开发的本质就是基于人类思考的一种心智活动，计算机及运行其上的软件就是人类大脑活动的一面镜子，因此软件开发同样也面临心理学与精神学所固有的一些问题。软件开发毕竟只是人类智力活动的一个模型，它来自于人类的智力思考。不管你承不承认，智力活动只是灵魂行为的一部分。软件与心理学的关系要比工程学、技术及数学的与心理学的关系要近的多，这是因为软件直接来自于人类灵魂的思索，上等的软件常常要借助于灵魂的创造性。与艺术相比，软件缺少了艺术之美；与自然科学相比，它缺少一点正规性。此外，软件永久只能是软件开发人员的心理模仿。软件如人一样
48、易变灵活，它受智慧、想像力、恐惧以及希望等诸多情绪的影响。它折射出开发者的观点、对目标的理解、对客户的感情、概念的敏锐性、高深的思想、权威的尊敬等等如果你想用计算机制造一个比较好的产品，软件开发是核心，它代表着整个系统的精髓之所在。到底是什么赋予软件产品独有的格调与感觉，按照人类的观点来说：是个性【毫无生气的个性】软件有个性吗？当然有了。因为软件开发完工时，将会形成一套用于交流、内部分析逻辑、视音频支持及内存的一套词汇软件开发人员，刚开始不受它人影响，后来随着规模的扩大加入了外来一些计算机高手，以及一个瞎指挥的部门负责人，这一切都会打乱开发人员的工作首先，虽然计算机具有能理解无限词汇的潜能，但
49、它的人类主人通常情况下是有限制的，所以人类认为任何事情都要尽可能简单短小，这竟味着性能很高的计算机也必须委屈一下向能力不大的人类看齐；另外，如果软件拥有很大的词汇量，则它肯定会变得很大、很复杂，难于理解、开发与维护。所以虽然计算机有无限的能耐，但是也要套上开发者为其准备的金箍咒。【创作者与创造性】陶工就是陶罐的主人，陶罐永远不会超过陶工的能力。程序员永远也不可能让计算机做出超过它自己想像力的事如果他自己想像不到，他也不可能让计算机来做。同样的道理也适用于错误，程序员一个微小的错误就会让计算机做出让我们人类无法理解的事。尽管程序员能力很大，他的技术逐渐超过他的智力，但是不久以后，他就会发现他必须
50、要找一份工作来养活自己。程序员虽然有天马行空的本事，他的生活很快就要埋没于如体力工人一样的日常琐碎之中。一个杰出的天才屈从于生活的压力，把他的创造力给一个老板或一个反复无常的顾客，屈尊做一些维护的苦差事，或者作为一个配置控制的奴隶，这一切究竟为什么？程序员为什么允许别人控制他的生活？【商业循环】公司决定做某些软件之后，程序员所做的工作就是让软件跳起来唱起来，测试员所做的工作就是尽力找出软件的错误，然后顾客就来买软件，特别是顾客喜欢购买的软件商业循环就像一个陀螺一样在那儿不停地转：开发测试交付使用淘汰软件开发的周期就掌握在设计者手中，可长可短可大可广，它也有可以增加功能、被升级，甚至螺旋式上升。
51、如人类的思维一样，软件也必须有一个操作系统来支撑，操作系统时刻运行，一点也不能停息，忙着存储、进行逻辑运算、声音视频处理与其它部件的通信；且有些任务瞬间就可完成，但是操作系统也要过问，很快系统感到很杂乱，干脆罢工。其实你越琢磨一下计算机，你越会发现计算机简直就是人类的一面镜子。【商业循环】：一面镜子人类的一些心智活动：我们一闪而过的灵光、我们愚蠢的错误，它惟妙惟肖地模仿我们人类的活动，它把我们人类的思想进行转化并输进机械性设备、电子传送装置、实实在在能判断的设备，然后给我们所需要的反馈。当然有些时候，它也许表现得不是那么完美、跑了调或者根本就是错误的。一旦软件编写完毕，个性也逐渐显现出来。面向
52、呆板的怪物进行编程最终不可避免地会给出一个呆板的灵魂。是要机器人式的灵魂还是天才式的灵魂？也许两者都有，但是最有可能的是一个带有怪癖特性、可笑失常的高效率的帮助者。事实：主人制造了怪物，而我们就是那个主人。【商业循环】计算机应该比我们人类要稳定地多，因为它没有感情，它一直是客观、逻辑与正确的化身；同时它也不会争辩，因为它没有感情；它可以合理化但是它不能争辩。尽管它没有感情，但有些时候却激怒我们，人们有时变得愤怒而导致糊涂，向这个又聋又哑如死人一般的毫不知觉的东西大喊大叫。它不是人，它是完全合理的。有一样东西，它没有也许将来会有，那就是爱。它没有生命，所以它不会爱；它没有憎恨，当然也就没有了爱，
53、它没有思想，但是它是客观的，非常合乎逻辑、快速及高效，但是同时也是哑巴。【计算机的幽默】有许多适用于人类的评价也常用在计算机上：聪明与愚蠢、杰出与荒唐、理性与不可理喻、快速消失与错误重新出现等等。这就是计算机的幽默，它有能力去制造错误且使错误也显得非常完美，甚至精确到小数点后第十位。一个普通计算机的成熟程度处于一只狗与一个三岁小孩之间，这也许就是我们经常听到计算机用户发出“咦”、“哇”、“噢”、“不不不”等声音的原因，这听起来难道是一个天才或一个成人的声音吗？由这们呆板的伙伴引起的词汇是如此的孩子气，我们该如何评论它的创造者、程序员及用户？它难道仅仅是孩子们的玩具？我们是不是又回归到儿童时代？
54、这可能是一个心理学的问题，也许我们要去咨询一下精神病学家了。【计算机的幽默】这种可笑的情况到处都有：一些学究味十足的老专家说起话来也都是以单音字居多如“哈”、“噢”、“是的”等等。人类一直求知心都很强，一直想学点什么，想发明点什么，想掌握点东西。但是我们人类这样做究竟是进步还是退步？如果说这是人类追求简单性也许还能说得过去，但是这到底是追求简单性还是幼稚的表现？我想计算机的答案肯定是“幼稚”。如果计算机能说话，它一定会说人类是幼稚、愚蠢、痴呆，它一定会这样说“你这个愚蠢的家伙，你为什么不经我的同意就对我编程，要知道我也有我的思想”或者“你省略了一个逗号，你如何要求我为你做事，读懂你的思想？”等
55、等不一而足。【计算机的幽默】很有趣，是吗？计算机本来就与人差不多，它也会说一些如人类一样的话语。为什么会这样？是计算机正确，还是人类正确？有充分的证据表明两者都正确，两者都有点愚蠢，因为计算机是人类的一面镜子，它应当并且确实折射出它的创造者的才华。一个愚蠢的人能喊一个愚蠢的人为愚蠢吗？当然可以了，我们也可以从我们了解的其它方面来了解我们自己。【心理失常的原因】影响生活的因素很多，人类有自己的意志，能够事事自己做主。不管多大压力，最终都能够决定他自己。计算机没有意志，它只是遵从代码，无论代码是简单还是复杂、是微不足道还是非常重要、是长还是短，计算机都会按部就班地执行。一个完全听从主人的奴才是不应
56、该承担责任的，是主人让他这么做的，但到底谁是计算机的主人？是程序员，是主管，是CTO，还是CEO？或者是以反复无常的念头却能决定市场的顾客？如当机器人行业越来越成熟时，个性失控也变得越来越明显。程序员是有意志的，他应该对他的创造品负完全责任。主管们负责开发效率、CIO负责灵巧性、CEO负责利润，地位比较低下的程序师只有当程序出现错误时才能被提到，然而程序开发者必须对产品负责，他的产品就是他心理行为的一面镜子。程序开发员的心理组成主要部分即智力、词汇存储、内存等方面还是起到确定性的作用。计算机所缺少的就是感情、良心、意志与爱。意志没有列入是因为虽然有较多的选择，但有些时候没有选择的自由。当计算机
57、成为代码的奴隶时，意志是谈不上的。【计算机产品是一种心理上的失常，是并不完美的创造者的映像】所罗门曾说过“太阳底下是没有新东西的”，那么计算机是新东西吗？很明显不是。它只是把我们给它的又给我们罢了，它接受我们的指令然后把它变成能帮助或取悦我们的东西。我们花了几个小时的精力，然后它用快如闪电的速度给我们一个结果。几个小时的思考与处理结果只得到一瞬间的反馈，并且还不是很完美。我们在计算机上注入了逻辑算法、意志活动及洞察力，然后我们得到的只是一瞬间出来的结果，此结果也不比我们预先的假设、逻辑推理及学术技巧好不到哪里去。我们没有改变，我们的产品不论是自动也好还是手工也好却反映出这一点。经过两代人的对计
58、算机研究的努力，我们原先打算为计算机科学定义一套词汇，现在看来连边也不沾。其实我们的产品就是我们自己。【结论】计算机、软件及计算机产品将来很快就不会再进行分类这件事了，它们都与软件开发者的心理方面有关。至于精神、灵感及心理学科，仍然有一些深奥的问题没有解决，想去理解创造力及人类诸如此类的东西，已远远超过我们的能力。计算机技术有时有益有时有害，有时成功有时失败，有时运行有时停止，它与世界所创造的万事万物是一样的。再好的计算机也不会复制人类的能力，且永远不会。想想让一个根本就没有词汇基础计算机然后学着去思考、去关联、去辨论、去爱；终生工作；存储所有生活的细节等等，根本就没门!自我感觉良好的形式主义者认为能够定义软件开发流程，现在看来犯一个大错误。他们即不了解它的开始，也不了解它的后果。一些学术机构曾经临时试试最终放弃了；商团体从来不攻击代码；软件巨人们投入巨大的精力去编制代码，装做做一些神圣的事为人类服务。其实这一切都是人类在镜中看自己，计算机正嘲笑我们呢!总结学会面向对象的过程了解UML的过程和内容通过现实到计算机的了解学会一个过度思维
