Posts - 79,
Articles - 0,
Comments - 3833
个人博客已迁移至codinglabs.org，欢迎访问
11:16 by T2噬菌体, ... 阅读,
&& & &本文以实例的方式，展示了如何使用UML进行面向对象的分析与设计。本文将假设读者对UML、面向对象等领域的基本内容已了然于胸，所以将不会过多阐述，而将重点放在应用过程上。本文的目的是通过一个完整的实例，展现基于UML的OOA&D过程
的一个简化模式，帮助朋友们更好的认识UML在OOA&D中起的作用。
&& & &经常听到有朋友抱怨，说学了UML不知该怎么用，或者画了UML却觉得没什么作用。其实，就UML本身来说，它只是一种交流工具，它作为一种标准化交流符号，在OOA&D过程中开发人员间甚至开发人员与客户之间传递信息。另外，UML也可以看做是OO思想的一种表现形式，可以说&OO是神，而UML是型&。所以，想用好UML，扎实的OO思想基础是必不可少的。然而，在UML应用到开发过程中时，还是有一定的模式可以遵循的。（注意，是模式而不是教条，我下面给出的流程只是一个启发式过程，而不是说一定要遵循这个流程。）下面，我们通过一个CMS系统的分析设计实例，看看如何将UML应用到实际的开发中。
从需求到业务用例图
&& & &OOA&D的第一步，就是了解用户需求，并将其转换为业务用例图。我们的CMS系统需求非常简单，大致课做如下描述：这个系统主要用来发布新闻，管理员只需要一个，登录后可以在后台发布新闻。任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后可对新闻进行评论。管理员在后台可以对新闻、评论、注册会员进行管理，如修改、删除等。&&&&& 通过以上需求描述，我们画出如下的业务用例图：&& & &这里要注意三点：&& & &1.业务用例是仅从系统业务角度关注的用例，而不是具体系统的用例。它描述的是&该实现什么业务&，而不是&系统该提供什么操作&。例如，在实际系统中，&登录&肯定要作为一个用例，但是这是软件系统中的
操作，而用户所关注的业务是不包含&登录&的。&&&&& 2.业务用例仅包含客户&感兴趣&的内容。&&&&& 3.业务用例所有的用例名应该让客户能看懂，如果某个用例的名字客户看不懂什么意思，它也许就不适合作为业务用例。
从业务用例图到活动图
&& & &完成了业务用例图后，我们要为每一个业务用例绘制一幅活动图。活动图描述了这个业务用例中，用户可能会进行的操作序列。活动图有个很重要的使命：从业务用例分析出系统用例。例如，下面是&新闻管理&的活动图：&& & &可以看到，一个&新闻管理&这个业务用例，分解出N多系统操作。这里要特别注意这些操作，其中很多&活动&都很可能是一个系统用例（当然，不是每个都是）。例如，由这个活动图可以看出，系统中至少要包含以下备选系统用例：登录、注销登录、查看新闻列表、修改新闻、删除新闻。&&&&& 这样，将每个业务用例都绘制出相应的活动图，再将其中的&活动&整合，就得出所有备选系统用例。
从活动图到系统用例图
&& & &找出所有的备选系统用例后，我们要对他们进行合并和筛选。合并就是将相同的用例合并成一个，筛选就是将不符合系统用例条件的备选用例去掉。一个系统用例应该是实际使用系统的用户所进行的一个操作，例如，&查看新闻列表&就不能算一个系统用例，因为他只是某系统用例的一个序列项。&&&&& 最终我们得出的系统用例图如下：
从系统用例图到用例规约
&& & &得出系统用例图后，我们应该对每一个系统用例给出用例规约。关于用例规约，没有一个通用的格式，大家可以按照习惯的格式进行编写。对用例规约唯一的要求就是&清晰易懂&。&&&&& 下面给出&登录&这个系统用例的一个规约：
业务领域类图
&& & &完成了上面几步，下面应该是绘制业务领域类图了。所谓业务领域类图要描述一下三点：&& & &1.系统中有哪些实体。&&&&& 2.这些实体能做什么操作。&&&&& 3.实体间的关系。&& & &这里要特别强调：这里的实体不是Actor，而是Actor使用系统时使用的所调用的实体，是处在系统边界之内的实体。例如，管理员就没有作为一个实体出现在这里，因为管理员处在系统边界之外，它所有的工作都可以通过调用这三个类的方法完成。并且，这里的&注册会员&实体也不是刚才用例图中注册会员这个Actor，而是作为一个系统内的业务实体，供Actor们使用的。例如，其中的注册功能是给注册会员这个Actor使用，而移除则是给管理员这个Actor使用的。&&&&& 理解以上这段话非常重要，我经常看到由于混淆了实体和Actor的关系而导致画出的领域类图不准确或职责分配不准确。&&&&&&大家可能还注意到，我们这里没有给出每个实体的属性。其实，在领域分析阶段，实体的属性并不重要，重要的是找出实体的操作。&
&& & &以上这几步，就是分析的过程。而下面的步骤就是设计了。&&&&& 设计没有分析那么好描述，因为分析是&客户面&，它只关心系统本身的功能和业务，而不关心任何和计算机有关的东西。但是，设计和平台、语言、开发模型等内容关系紧密，因而很难找出一个一致的过程。但是，一般在设计过程中实现类图是要绘制的。&&&&& 实现类图和领域类图不一样，它描述的是真正系统的静态结构，是和最后的代码完全一致的。因此，它和平台关系密切，必须准确给出系统中的实体类、控制类、界面类、接口等元素以及其中的关系。因此，实现类图是很复杂的，而且是平台技术有关的。所以，我在这里不可能给出一个准确的实现类图，不过为了描述，我还是给出一个简化了的实现类图，当然，它是不准确的，而只是从形式上给出实现类图的样子。&&&&& 我们假设这个系统建构于.NET 3.5平台上，并且使用ASP.NET MVC作为表示层，整体使用三层架构。那么，用户模块体系的实现类图大体是这样子（不准确）：
&& & &有了静态结构，我们还要给出动态结构，这样，才能看清系统间的类是如何交互的，从而有效帮助程序员进行编码工作。&&&&& 上图给出的是用户登录的序列图。首先注册会员作为Actor，调用UserController的Login方法启动序列，然后序列按图示步骤执行。其中UserServices作为业务组件，首先调用数据访问组件的GetByName确定用户是否存在，如果存在，再调用GetByNameAndPassword确定输入密码是否是此用户的密码。从而完成业务功能。&&&&& 要注意，序列图在实际中是很多的，几乎每个类方法都配有相应的序列图。
最后的步骤
&& & &在完成了上面的过程后，就可以进行编码、调试、测试等工作了。但这些已经超出了本文讨论的范围。
&& & &本文简要给出了使用UML进行OOA&D的过程。当然，由于示例较小，而且本人水平有限，所以给出的相关内容可能不是很准确。而且软件分析设计本来就不是一个固定模式的过程，随着系统的不同整个过程会有变化。本文只是想起到一个抛砖引玉的作用，让朋友们大致了解UML的使用流程。至于实际的分析设计，还需要深入的学习和实践的积累。面向对象的程序设计_百度百科
关闭特色百科用户权威合作手机百科
收藏 查看&面向对象的程序设计
面向对象程序设计（：Object-oriented programming，：OOP）是一种，同时也是一种程序开发的方法。对象指的是的实例。它将作为的基本单元，将程序和其中，以提高软件的重用性、灵活性和扩展性。面向对象程序设计可以看作一种在程序中包含各种独立而又互相调用的对象的思想，这与传统的思想刚好相反：传统的程序设计主张将程序看作一系列的集合，或者直接就是一系列对电脑下达的指令。面向对象程序设计中的每一个对象都应该能够接受数据、处理数据并将数据传达给其它对象，因此它们都可以被看作一个小型的“机器”，即对象。目前已经被证实的是，面向对象程序设计推广了程序的灵活性和可维护性，并且在大型项目设计中广为应用。 此外，支持者声称面向对象程序设计要比以往的做法更加便于学习，因为它能够让人们更简单地设计并维护程序，使得程序更加便于分析、设计、理解。反对者在某些领域对此予以否认。当我们提到面向对象的时候，它不仅指一种程序设计方法。它更多意义上是一种程序开发方式。在这一方面，我们必须了解更多关于面向对象系统分析和（Object Oriented Design，简称OOD）方面的知识。所&&&&属编程架构
一项由Deborah J. Armstrong进行的长达40年之久的计算机著作调查显示出了一系列面向对象程序设计的基本理论。[1]它们是：（Class）定义了一件事物的抽象特点。通常来说，类定义了事物的属性和它可以做到的（它的行为）。举例来说，“”这个类会包含狗的一切基础特征，即所有“狗”都共有的特征或行为，例如它的孕育、毛皮颜色和吠叫的能力。类可以为程序提供模版和结构。一个类的方法和属性被称为“”。 我们来看一段：
&&&&吠叫():
&&&&毛皮颜色:
&&&&孕育:结束
在这串代码中，我们声明了一个类，这个类具有一些狗的基本特征。关于公有成员和私有成员，请参见下面的继承性一节。（Object）是类的。例如，“狗”这个类列举狗的特点，从而使这个类定义了世界上所有的狗。而莱丝这个对象则是一条具体的狗，它的属性也是具体的。狗有皮毛颜色，而莱丝的皮毛颜色是棕白色的。因此，莱丝就是狗这个类的一个实例。一个具体对象属性的值被称作它的“状态”。（系统给对象分配内存空间，而不会给类分配内存空间。这很好理解，类是抽象的系统不可能给抽象的东西分配空间，而对象则是具体的。）
假设我们已经在上面定义了狗这个类，我们就可以用这个类来定义对象：
定义莱丝是狗
莱丝.毛皮颜色:棕白色
莱丝.吠叫()
我们无法让狗这个类去吠叫，但是我们可以让对象“莱丝”去吠叫，正如狗可以吠叫，但没有具体的狗就无法吠叫。
类和对象就好比是“实型”和“1.23”，“实型”是一种数据的类型，而“1.23”是一个真正的“实数”（即对象）。所有的“实数”都具有“实型”所描诉的特征，如“实数的大小”，系统则分配内存给“实数”存储具体的数值。一个对象通过接受消息、处理消息、传出消息或使用其他类的方法来实现一定功能，这叫做消息传递机制（Message Passing）。
如：莱丝可以通过吠叫引起人的注意，从而导致一系列的事发生。（Inheritance）是指，在某种情况下，一个类会有“子类”。子类比原本的类（称为父类）要更加具体化。例如，“”这个类可能会有它的子类“牧羊犬”和“吉娃娃犬”。在这种情况下，“莱丝”可能就是牧羊犬的一个。子类会继承父类的属性和行为，并且也可包含它们自己的。我们假设“狗”这个类有一个（行为）叫做“吠叫()”和一个属性叫做“毛皮颜色”。它的子类（前例中的牧羊犬和吉娃娃犬）会继承这些成员。这意味着程序员只需要将相同的代码写一次。
在伪代码中我们可以这样写：
类牧羊犬:继承狗
定义莱丝是牧羊犬
莱丝.吠叫()&&&&/*&注意这里调用的是狗这个类的吠叫方法。*/
回到前面的例子，“牧羊犬”这个类可以继承“毛皮颜色”这个属性，并指定其为棕白色。而“吉娃娃犬”则可以继承“吠叫()”这个方法，并指定它的音调高于平常。子类也可以加入新的成员，例如，“吉娃娃犬”这个类可以加入一个方法叫做“颤抖()”。设若用“牧羊犬”这个类定义了一个实例“莱丝”，那么莱丝就不会颤抖，因为这个方法是属于吉娃娃犬的，而非牧羊犬。事实上，我们可以把继承理解为“是”或“属于”。莱丝“是”牧羊犬，牧羊犬“属于”狗类。因此，莱丝既得到了牧羊犬的属性，又继承了狗的属性。 我们来看伪代码：
类吉娃娃犬:继承狗
&&&&颤抖()
类牧羊犬:继承狗
定义莱丝是牧羊犬
莱丝.颤抖()&&&&/*&错误：颤抖是吉娃娃犬的成员方法。&*/
当一个类从多个父类继承时，我们称之为“”。如一只狗既是吉娃娃犬又是牧羊犬（虽然事实上并不合逻辑）。多重继承并不总是被支持的，因为它很难理解，又很难被好好使用。具备封装性（Encapsulation）的面向对象程序设计隐藏了某一方法的具体执行步骤，取而代之的是通过消息传递机制传送消息给它。因此，举例来说，“狗”这个类有“吠叫()”的方法，这一方法定义了狗具体该通过什么方法吠叫。但是，莱丝的朋友并不知道它到底是如何吠叫的。
封装是通过限制只有特定类的对象可以访问这一特定类的成员，而它们通常利用接口实现消息的传入传出。举个例子，接口能确保幼犬这一特征只能被赋予狗这一类。通常来说，成员会依它们的访问权限被分为3种：公有成员、私有成员以及保护成员。有些语言更进一步：可以限制同一包内不同类的访问；和保留了为类的成员聚集准备的关键字：internal（C#）和Friend（VB.NET）；语言则可以让用户指定哪个类可以访问所有成员。（Polymorphism）是指由继承而产生的相关的不同的类，其对象对同一消息会做出不同的响应。[2]例如，狗和鸡都有“叫()”这一方法，但是调用狗的“叫()”，狗会吠叫；调用鸡的“叫()”，鸡则会啼叫。 我们将它体现在伪代码上：
&&&&&&&&开始
&&&&&&&&&&&&吠叫()
&&&&&&&&结束
&&&&&&&&开始
&&&&&&&&&&&&啼叫()
&&&&&&&&结束
定义莱丝是狗
定义鲁斯特是鸡
鲁斯特.叫()
这样，虽然同样是做出叫这一种行为，但莱丝和鲁斯特具体做出的表现方式将大不相同。多态性的概念可以用在上，本文不再赘述。(Abstraction)是简化复杂的现实问题的途径，它可以为具体问题找到最恰当的类定义，并且可以在最恰当的继承级别解释问题。举例说明，莱丝在大多数时候都被当作一条狗，但是如果想要让它做牧羊犬做的事，你完全可以调用牧羊犬的方法。如果狗这个类还有的父类，那么你完全可以视莱丝为一个动物。编程范型 对于OOP的准确定义及其本意存在着不少争论。
通常，OOP被理解为一种将程序分解为封装数据及相关操作的模块而进行的编程方式。有别于其它编程方式，OOP中的与某数据类型相关的一系列操作都被有机地封装到该数据类型当中，而非散放于其外，因而OOP中的数据类型不仅有着状态，还有着相关的行为。OOP理论，及与之同名的OOP实践相结合创造出了新的一个编程架构；OOP思想被广泛认为是非常有用的，以致一套新的被创造了出来。（其它的例如函数式编程或过程式编程专注于程序运行的过程，而逻辑编程专注于引发程序代码执行的断言）
对面向模拟系统的语言（如：SIMULA 67）的研究及对高可靠性系统架构（如：高性能操作系统和CPU的架构）的研究最终导致了OOP的诞生。
新手上路我有疑问投诉建议参考资料 查看面向对象设计中的五大原则_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
文档贡献者贡献于
评价文档：
23页免费172页免费10页免费8页免费50页免费28页免费79页免费60页免费70页免费26页免费
喜欢此文档的还喜欢86页免费44页免费59页7下载券37页7下载券30页免费
面向对象设计中的五大原则|中​科​院​杨​老​师​讲​座
把文档贴到Blog、BBS或个人站等：
普通尺寸(450*500pix)
较大尺寸(630*500pix)
大小：576.50KB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢4071人阅读
一旦明白了软件设计的真谛（参见《》），我们就更能理解面向对象设计的优点。简单说来，它更便于我们在软件中构建更真实的虚拟世界。
首先，对象的引入方便了在软件虚拟世界中模拟现实世界。现实世界是由很多独立的抽象或具体物体组成的，比如房子、汽车、空调、书等等。为了构建更真实的虚拟世界，在软件中需要存在用于表达类似现实物体的编程元素，这正是引入对象概念的意义所在。
以对象为设计中心，迫使设计者在关注程序所需实现功能的同时不至于忘记通过抽象去塑造概念，以便用对象表达之。由于抽象获得的对象有助于隐藏复杂度，这在一定程度上简化了通过对象表达和理解软件虚拟世界的难度。也由于对象的存在，使得设计更加的生动和具有更强的自我解释能力。
从软件设计者的角度：如果希望塑造的对象在现实生活中存在，这有助于他借助现实引导自己的设计，他也应尽量将虚拟世界中对象的行为塑造成与现实世界的相近；如果希望塑造的对象在现实生活中并不存在，他只能借助对象的行为和状态去塑造对象（的概念），此时应注意行为、状态与概念间关系的合理性，否则所塑造的对象将令人费解。
从软件维护者的角度：如果对象在现实生活中存在，这有助于他借助生活经验快速掌握设计；如果在现实中找不到对象的影子，他仍可以通过对象的行为掌握对象的概念，这同样有助于他更方便地维护软件。
其次，面象对象设计由于强调以对象为中心，因而具备更强的封装能力。在大多支持面向对象设计的编程语言中，更强的封装能力除了意味着更具信息隐藏能力外，还使得封装的边界既明显又更不易被突破，这有助于在软件的维护过程中维持“形”。某种程度上，面向对象设计强化了软件行业推崇的模块化设计。
再次，面向对象设计中的继承和多态技术除了进一步提高通过软件模拟现实世界的能力外，还能让设计更灵活、易变更和方便复用。
显然，面向对象设计的优势是通过使得设计方法更抽象而获得的，这也解释了为什么掌握面向对象设计比掌握面向过程设计更难。现实中，由于有些工程师难以转变为从对象、继承和多态的角度思考设计，使得运用面向对象设计这一方法举步为艰。
面向对象设计的关键是用对象表达抽象概念，如果抽象出的概念并不清晰，则所获得的设计一定不会好。千万不要误以为运用面向对象设计所获得的设计就一定比面向过程的好。好方法获得好结果的前提仍需要我们运用好。
有了面向对象设计以后并不是说我们就可以抛弃面向过程设计。实际上，即使我们采用了面向对象设计，但在局部范围内我们还是离不开运用面向过程的设计思想。比如，类的构建需要运用面向对象设计，而类方法的实现却得用到面向过程设计。
本文出自李云的博客，请务必保留此出处：http://blog.csdn.net/hzliyun/article/details/7535631。
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
正写《C＋＋跨平台与框架开发》
前摩托罗拉软件架构师。具有硬件开发经验的资深软件工程师。
& 深刻理解软件开发的复杂性本质；
& 擅长软件设计；
& 嵌入式软件开发专家；
& 扎实的IPv4网络知识；
& 行业经验的多样性：
- 2年电气与电子产品开发；
- 3年图像监控桌面软件和前端嵌入式产品开发；
- 10年通讯产品开发；
- 现就职于阿里巴巴集团从事UC浏览器的软件开发工作；
访问：224002次
积分：3248
积分：3248
排名：第3988名
原创：60篇
评论：375条
(1)(1)(1)(1)(1)(3)(4)(1)(2)(1)(3)(2)(3)(4)(1)(1)(5)(2)(5)(18)}