下载文档原格式
浅谈OOA,OOD,OOP的理解OOA（⾯向对象分析）、OOD（⾯向对象设计）、OOP（⾯向对象编程），这3个概念，对于我们JAVA程序员来讲，或多或少应该都有所了解，或者说⾄少都听说过。
但是要谈到对其理解，可能对于多数⼊⾏不深的从业者来说，确实不是那么容易做到。
特别是对于绝⼤多数的3年以内的低中级软件⼯程师⽽⾔。
因为他们的⼯作更多是需要按照项⽬经理分配的任务来编写功能代码，很少有多余的时间去阅读或者思考⼀些概念性的东西。
说起这个问题，我也在⽹络上也搜索过很多的资料，⼤多摘录⾄书籍，⽐较官⽅化。
让初学者⽆从理解。
为了⼴⼤的新从业者或者应聘者，在这⾥，我们以⼀种实例的⽅式来对这3个概念进⾏重新的阐述：业务场景：建⾏卡持有者，张三与李四两⼈，现在需要张三给李四转账⼈民币5000元整。
按照业务分析后的流程图如下:对于分析业务流程，常见的2种：⾯向过程分析（POA），⾯向对象分析（OOA）⾯向过程分析（Procedure Oriented Analysis）：是⼀种以过程为中⼼的编程思想，以数据流向为主要导向。
为了解决问题，将解决问题的业务过程，按照⼀定的顺序划分成为⼀个⼜⼀个的事件，然后再封装成⼀个⼜⼀个的函数，最后由⼀个函数统⼀的按照顺序⼀步⼀步的调⽤即可。
在⾯向过程分析中，顺序很重要，要实现功能只需要按照⼀定的顺序相互调⽤函数即可。
上述业务场景按照⾯向过程分析出来的结果就是：1. 程序检查张三卡中余额是否⾜够5000元⼈民币（事件1，满⾜则调⽤事件2）2. 程序从张三卡中扣除5000元⼈民币（事件2）3. 程序向李四卡中加⼊5000元⼈民币（事件3）4. 程序检测李四卡中是否正常⼊账（事件4，满⾜则结束整个业务）5. 程序向张三卡中加⼊5000元⼈民币（事件5）在上述过程中，我们将这个业务过程，分成了5个步骤，也叫做5个事件，那么如果需要在程序中完成该转账业务的话，那么我们只需要按照1-2-3-4-5这样的顺序依次调⽤函数⽅法即可。
使用Rose创建顺序图案例分析
1.需求分析
我们可以通过更加具体的描述来确定工作流程，基本工作流程如下：
（1）李老师希望通过系统查询某名学生的学科成绩。
（2）李老师通过用户界面录入学生的学号以及学科科目请求学生信息。
（3）用户界面根据学生的学号向数据库访问层请求学生信息。
（4）数据库访问层根据学生的学号加载学生信息。
（5）数据库访问层根据学生信息和学科科目获取该名学生的分数信息。
（6）数据库访问层将学生信息和分数信息提供给用户界面。
（7）用户界面将学生信息和分数信息显示出来。
2.确定顺序对象
创建顺序图的下一步是从左到右布置在该工作流程中所有的参与者和对象，同时也包含要添加消息的对象生命线。
李老师 :
3.
练习题
（1）以“远程网络教学系统“为例，在该系统中，系统管理员需要登录系统才能进行系统维护工作，如添加教师信息、删除教师信息等。
根据系统管理员添加教师信息用例，创建相关顺序图。
: Administrator
: teacher
（2）在“远程网络教学系统”中，如果我们单独抽象出来一个数据访问类来进行数据访问。
那么，根据系统管理员添加教师信息用例，重新创建相关顺序图。
: Administrator
: teacher
（3）绘制如下读者预订协作图
（4）绘制如下读者确认预订协作图，并将其转换成顺序图。
实战OO：鲁棒分析徐锋/ 文引言曾经有人指出结构化分析技术存在一个致命的弱点，其在分析模型和系统的设计模型之间，存在着一个本质性的断层。
这个断层导致系统构想与实现在设计时产生了分离。
而在面向对象系统中，是否也存在这个现象呢？从理论上说，OO技术是可以将系统中几乎独立的各个方面链接成一个语义上的整体。
但在许多OO的实践中，却也感受到了这种分析与设计的鸿沟，当完成了用例建模之后，要开始绘制顺序图或协作图，至而演化成为设计类图，总是感到有些力不从心。
其实存在着一个方法，它可以有效地填补这个鸿沟，那就是Ivar Jacobson在1991年引入的OO世界的Robustness分析，中文译做鲁棒分析、健壮性分析。
虽然“Robustness 分析”这一名字中带有分析一词，但准确地说它有着很多与设计类似的工作，只是它并不能够算是正式的设计，因此被归到分析阶段中。
也许是由于简单易用，也许是由于它通常不被文档化保存，只是绘制成草图的形式，现在在RUP中、在很多OO技术书籍中，好像越来越少看到它的出现。
但是希望这一切不要让你与这个强大的工具擦肩而过，学会它吧，它将成为你强大的秘密武器。
什么是鲁棒分析在和大家一起运用鲁棒分析技术继续完成我们的任务之前，还是一起来了解一下什么是鲁棒分析？有了一些基本的概念和认识，才能够有效地应用它。
1 鲁棒性分析的作用鲁棒性分析具体来说有什么用呢？它是如何帮助大家跨越分析与设计之间的鸿沟呢？在OO分析与设计中，它能够完成以下几个关键任务：1）正确性检查：鲁棒分析将通过比顺序图更简单、更有效的图形来描绘用例中的传递过程，从而确保用例是正确的，而且没有指定对于特定对象来说不合理、不可能的系统行为。
而且，熟练掌握鲁棒分析，甚至可以成为编写用例描述时结合使用的一种有效方法。
2）完整性检查：通过鲁棒分析，你可以很容易地找到用例描述中所有必须的扩展路径。
3）持续发现对象：在做鲁棒分析时，你将开始思考具体的细节，从而很容易发现在域建模时遗失的对象，而这些对象在绘制顺序图时不容易被重新找到，而只会让你感觉根本无法绘制出相应的顺序图。
第一章1、什么是分析与设计？1、分析强调对问题和需求的调查研究2、设计强调的是满足需求的概念上的解决方案2、什么是面向对象分析与设计？1、在面向对象分析过程中，强调的是在问题领域内发现和描述对象（或概念）2、在面对对象设计过程中，强调的是定义软件对象以及它们如何协作以实现需求。
3、简单示例：1、定义用例（use case）需求分析可能包括人们如何使用应用的情节或场景，这些情节或场景可以被编写成用例。
2、定义领域模型（domain model）面向对象分析的结果可以表示为领域模型，在领域模型中展示重要的领域概念或对象。
需要注意的是，领域模型并不是对软件对象的描述，它使真实世界领域中的概念和想象可视化。
（也被称为概念领域模型—conceptual object model）3、定义交互图关注的是软件对象的定义—它们的职责和协作。
顺序图（sequence diagram）是描述协作的常见方法。
它展示对象之间的信息流，和由消息引起的方法调用。
4、定义设计类图除了在交互图中显示对象协作的动态视图外，还可以用设计类图（design class diagram）来有效的表示类定义的静态视图。
这样可以描述类的属性和方法。
与领域模型表示的是真实世界的类，设计类图表示的是软件类要注意的是，尽管设计类图不同于领域模型，但是其中的某些类名和内容还是相似的。
第二章1、什么是UML？统一建模语言（UML）是描述、构造和文档化系统制品的可视化语言。
UML表示法的基础是UML元模型，它描述建模元素的语义，UML元模型对模型驱动架构（Model Driven Architecture, MDA）CASE工具供应商具有影响。
开发者并不需要对其进行学习。
2、三种UML应用方式1、UML作为草图—非正式的、不完整的图，借助可视化语言的功能，用于探讨问题或解决方案空间的负责部分。
2、UML作为蓝图—相对详细的设计图。
用于：①逆向工程；②代码生成。
终于到了快结束的时候了，这将是用例分析系列的最后一篇，结果是得到需求规格说明书，以结束需求分析的过程。
经过前面七篇的工作，我们从最初的业务用例获取入手，获得了业务用例模型，这是我们的业务范围；经过分析得到了业务场景，这是我们的业务蓝图；经过规划，得出用例实现视图，这是我们的系统范围；经过再次分析，得到了用例实现以及领域模型，包括用例规约，业务规则和业务数据，这是我们的概念模型。
仅从需求所需的必要元素来说，我们基本上已经完成了需求分析的工作。
诚如上一篇结尾所说，为了让我们的需求更完美，这一篇所要做的工作也是必不可少的。
这一篇将要讨论到的内容包括：用例补充规约，系统原型，以及需求规格说明书先说说用例补充规约。
之前我们得到的用例规约是功能性的，它们是针对Actor完成目标业务所需的功能性Feature的描述。
然而我们所面对的系统除了功能性的Feature之外，总有一些是与业务功能无关的，这部分需求就是补充规约要涉及的内容。
什么样的需求与业务功能无关呢？一般来说，就是系统需求，例如可靠性，可用性，扩展性，易用性等等。
用户提出，系统必须提供7*24小时的服务，它应该有一定随业务变化而适应的能力，系统的界面应当简单易学，具备基础计算机知识的人可以不经过培训就能使用它等等。
这些需求与具体业务要求无关，哪怕一个不实现，系统也能Run起来。
但是这些需求又是如此重要，它们是系统达到用户期望必不可少的。
甚至在用户看来，某些补充规约要求比业务要求还重要，某个业务要求没做好，用户或许能宽容，如果你说系统不能提供7*24小时的服务，用户肯定是不能接受的。
这些需求，就是要在补充用例规约里面说明的内容。
笔者自己有个习惯，在上一篇也有所提及，就是习惯于把全局规则也写到补充用例规约里面。
比如，用户提出，所有系统使用者在系统中的任何操作，都要能够记录下来；如果数据被更改，不论是Modify,Add 还是Delete，数据都要做一个备份；响应时间可能超过1分钟的功能，都要提供进度条等等...这些全局规则在实际情况中，一般都是由系统框架，或某个中间件来完成的，它们是系统架构的一部分。
OO⽅法OO⽅法(Object-Oriented Method，⾯向对象⽅法，⾯向对象的⽅法)是⼀种把⾯向对象的思想应⽤于软件开发过程中，指导开发活动的系统⽅法，简称OO (Object-Oriented)⽅法，是建⽴在“对象”概念基础上的⽅法学。
对象是由数据和容许的操作组成的封装体，与客观实体有直接对应关系，⼀个对象类定义了具有相似性质的⼀组对象。
⽽每继承性是对具有层次关系的类的属性和操作进⾏共享的⼀种⽅式。
所谓⾯向对象就是基于对象概念，以对象为中⼼，以类和继承为构造机制，来认识、理解、刻画客观世界和设计、构建相应的软件系统。
⾯向对象⽅法作为⼀种新型的独具优越性的新⽅法正引起全世界越来越⼴泛的关注和⾼度的重视，它被誉为"研究⾼技术的好⽅法"，更是当前计算机界关⼼的重点。
⼗多年来，在对OO⽅法如⽕如荼的研究热潮中，许多专家和学者预⾔：正象70年代结构化⽅法对计算机技术应⽤所产⽣的巨⼤影响和促进那样，90年代OO⽅法会强烈地影响、推动和促进⼀系列⾼技术的发展和多学科的综合。
⼀、⾯向对象⽅法的由来与发展 回顾历史可激励现在，以规划将来。
OO⽅法起源于⾯向对象的编程语⾔（简称为OOPL）。
50年代后期，在⽤FORTRAN语⾔编写⼤型程序时，常出现变量名在程序不同部分发⽣冲突的问题。
鉴于此，ALGOL语⾔的设计者在ALGOL60中采⽤了以"Begin……End"为标识的程序块，使块内变量名是局部的，以避免它们与程序中块外的同名变量相冲突。
这是编程语⾔中⾸次提供封装（保护）的尝试。
此后程序块结构⼴泛⽤于⾼级语⾔如Pascal 、Ada、C之中。
60年代中后期，Simula语⾔在ALGOL基础上研制开发，它将ALGOL的块结构概念向前发展⼀步，提出了对象的概念，并使⽤了类，也⽀持类继承。
70年代，Smalltalk语⾔诞⽣，它取Simula的类为核⼼概念，它的很多内容借鉴于Lisp语⾔。
