第三讲 面向对象方法学.docx
《第三讲 面向对象方法学.docx》由会员分享，可在线阅读，更多相关《第三讲 面向对象方法学.docx（15页珍藏版）》请在冰豆网上搜索。
第三讲面向对象方法学
第三讲面向对象方法学
问题:
汇编语言编写程序、高级语言的结构化编程和面向对象编程之间的比较？
面向对象方法与面向过程方法的比较分析
属性
面向对象方法
面向结构方法
计算机处理的实体对象
这里的对象是指数据以及可以施加在这些数据之上的操作所构成的统一体
是各种预定义类型的变量、数组、记录和文件等数据描述
计算机处理对象的操作
通过消息驱动对象主动的执行起自身的数据处理行为
通过对象（参数）传送，并调用外部的处理功能来处理对象
处理观点上的不同
把程序看成是相互协作而又彼此对立的对象的集合。
每个对象就是一个微型的程序，有自己的数据、操作、功能和目的
看作是工作在数据之上的一系列过程或函数的集合
基本实体
类（数据+行为）
模块（数据+部分行为）
通讯机制
消息的传递
模块调用和参数的传递
思维的特点
该方法使用现实世界的概念抽象地思考问题从而自然地解决问题。
他强调模拟现实世界中的概念而不强调算法。
在进行面向对象设计时，计算机处理问题方式被放弃，而重点针对需要处理的问题进行分析。
这种方法以算法为核心，把数据和过程作为相互独立的部分，数据代表问题空间中的客体，程序代码则用于处理这些数据。
这种思维方法与计算机处理问题的方法是相一致的。
对于那些非常熟悉计算机处理过程的程序员来说具有不可替代的优势。
软件开发过程的特点
面向对象的方法重点强调反映现实需求的对象业务模型的建立，相对而言设计和编码部分的工作则较为次要。
重点在软件处理过程的设计和实现上。
适用范围的比较
适合于比较大型的，对计算机的处理效率要求不是非常高的应用。
对于要求涉及底层处理的应用或需要较高处理效率直接对硬件系统进行操作的系统比较适用。
另外对一些小的需要复杂处理流程的软件系统也比较适用。
一般特点比较
稳定、可重用、易维护；但效率比较底
效率高；但难维护
两种方法的交互性
面向对象方法是在传统软件工程方法上发展起来的一种新方法，许多传统的软件工程方法在面向对象的分析上也同样起作用，（模块设计的原则等）
面向过程设计，在面向对象的设计中还存在一些不可消除的作用，当前提出的面向方面的设计就是这种作用的体现。
面向对象的概念（省略）
面向对象软件过程的一般特性:
1．
面向对象的软件过程
软件过程模型的比较
属性
面向对象方法
面向过程方法
过程模型中强调的重点
业务分析模型的建立
软件设计模型的建立
生命周期个环节关系
各个阶段之间的界限不在明显
具有较清晰的界限分别，每个阶段描述模型之间的过度比较困难，需要一定的转换处理
主要处理的对象
对象模块
数据流，加工，功能模块等
开发过程
强调迭代
强调环节之间的依赖性
喷泉模型:
喷泉模型的生命周期与面向过程的生命周期是一致的，但喷泉模型的各个阶段是迭代和无缝的。
RUP过程模型:
软件过程是指实施于软件开发和维护中的阶段、方法、技术、实践及相关产物（计划、文档、模型、代码、测试用例和手册等）的集合。
行之有效的软件过程可以提高开发软件组织的生产效率、提高软件质量、降低成本并减少风险。
目前市场上领先的软件过程主要有RUP（RationalUnifiedProcess;Rational统一过程）、OPENProcess和OOSP（Object-OrientedSoftwareProcess;面向对象软件过程）。
而其中的RUP具有较高认知度的原因之一恐怕是因为其提出者Rational软件公司聚集了面向对象领域三位杰出专家Booch、Rumbaugh和Jacobson，同时它又是面向对象开发的行业标准语言——标准建模语言（UML）的创立者。
RUP是由Objectory过程演化而来，其初始版本为5.0，先后经历了5.1、5.11、5.5等版本直到最新的RationalUnifiedProcess2000版本。
RUP的二维开发模型
传统的软件开发模型瀑布式开发模型是一个单维的模型，开发工作划分为多个连续的阶段。
在一个时间段内，只能作某一个阶段的工作比如，分析、设计或者实现
RUP可以用二维坐标来描述。
横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期（Cycle）、阶段（Phase）、迭代（Iteration）和里程碑（Milestone）；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动（Activity）、产物（Artifact）、工作者（Worker）和工作流（Workflow）。
入下图:
RUP的二维开发模型
从图中的阴影部分表示的工作流可以看出，不同的工作流在不同的时间段内工作量的不同。
值得注意的是，几乎所有的工作流，在所有的时间段内均有工作量，只是工作程度不同而已。
这与Waterfallprocess（瀑布式开发模型）有明显的不同。
开发过程中的各个阶段和里程碑
RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：
初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）。
每个阶段结束于一个主要的里程碑（MajorMilestones）；每个阶段本质上是两个里程碑之间的时间跨度。
在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。
如果评估结果令人满意的话，可以允许项目进入下一个阶段。
1.初始阶段
初始阶段的目标是为系统建立商业案例并确定项目的边界。
为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。
本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。
对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。
初始阶段结束时是第一个重要的里程碑：
生命周期目标（LifecycleObjective）里程碑。
生命周期目标里程碑评价项目基本的生存能力。
初始阶段的主要成果是：
✓前景文档：
对核心项目要求、关键性质、主要限制的一般性的前景说明；
✓初始的用例模型（完成10％－20％）
✓初始的项目术语表
✓初始的商业用例，包括商业环境、验收规范以及成本预测
✓初始的风险评估
✓项目规划，其中明确阶段和迭代
✓商业模型，根据需要可选
✓一个或多个原型
初始阶段结束时是第一个里程碑：
生命周期目标里程碑。
对初始阶段进行评估的准则是：
✓风险承担人对项目范围定义和成本/进度估计达成共识
✓需求由主要的用例无二义地表达出来
✓成本/进度估计、优先级、风险和开发过程的可信度
✓开发出来的体系结构原型的深度和广度
✓实际支出与计划支出的比较
2.细化阶段
细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。
为了达到该目的，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。
同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。
细化阶段的成果是：
✓用例模型（至少完成80％）：
识别出了所有的用例和角色，以及大多数用例的描述
✓一些增加的需求，包括非功能性需求以及任何与特定用例无关的需求
✓软件体系结构描述
✓可执行的体系结构原型
✓修订后的风险表和商业用例
✓整个项目的开发计划，包括粗略项目规划，显示迭代过程以及相应的评估准则
✓更新的开发用例，指定要使用的过程
✓初步的用户手册（可选）
细化阶段结束时第二个重要的里程碑：
生命周期结构（LifecycleArchitecture）里程碑。
生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。
此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。
细化阶段的评估准则包括对以下问题的回答：
✓产品的前景是否稳定？
✓体系结构是否稳定？
✓可执行的演示是否强调了主要的风险元素，并且已经解决？
✓构造阶段的规划是否已经足够详细和准确，是否有可信的评估支持？
✓如果用当前的规划来开发整个系统，并且使用当前的体系结构的话，是否所有的风险承担人对当前的前景都达成一致？
✓是否实际的资源支出与计划的支出都是可接受的？
✓如果项目不能通过这个里程碑，则将取消或重新考虑。
3.构造阶段
在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。
从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。
构造阶段的产品是一个可以立即提交给最终用户使用的产品，它至少应该包括：
✓在特定平台上集成的软件产品
✓用户手册
✓对当前版本的描述
构造阶段结束是第三个里程碑：
初始运行能力。
此时要决定软件、节点和用户是否已经准备好运行，并且项目没有出现任何高风险问题。
这个版本通常叫做beta版。
构造阶段的评估准则包括对以下问题的回答：
✓这个产品版本是否足够稳定和成熟，可以在用户群中发布吗？
✓是否所有的风险承担人都已经准备好向用户提交？
✓实际的资源支出和计划的支出的比值是否仍然可接受？
✓如果项目没有达到这个里程碑，必须推迟发布。
4.交付阶段
交付阶段的目的是把软件产品交付给用户群。
一旦产品提交给最终用户，通常会产生新的要求，如继续开发新版本，修正一些问题，或者完成某些被推迟的功能部件。
当基线足够成熟，能够向最终用户领域发布时，就进入了交付阶段。
这通常需要系统的一些可以使用的子集已经达到一定的质量要求，并且有用户文档，从而使交付产生积极的效果。
包括：
✓beta测试确认新系统达到用户的预期
✓与被取代的旧系统并行操作
✓功能性数据库的转换
✓用户和维护人员培训
✓向市场、分销商和销售人员进行新产品的展示。
✓
交付阶段侧重向用户提交软件的活动，这个阶段包括几个典型的迭代，如beta版本，通用版本以及对用户的反馈作出响应等，都需要可观的精力。
但是，在生命周期的这一点上，用户反馈可能主要限于产品调整、配置、安装和可用性问题上。
交付阶段的主要目标包括：
✓使用户可以自我帮助
✓使风险承担人合作，使展开基线完整，并与前景评估准则一致
交付阶段的终点是第四个重要的项目里程碑：
产品发布里程碑。
在这个点上，要确定是否已经达到目标，能否开始另一个开发周期。
交付阶段主要的评估准则包括对以下问题的回答：
✓用户是否满意？
✓是否能够接受实际的和计划的资源支出的比？
RUP的核心工作流
RUP中有9个核心工作流，分为6个核心过程工作流（CoreProcessWorkflows）和3个核心支持工作流（CoreSupportingWorkflows）。
尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。
9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。
1.商业建模（BusinessModeling）
商业建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。
2.需求（Requirements）
需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。
为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。
3.分析和设计（Analysis&Design）
分析和设计工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。
分析设计的结果是一个设计模型和一个可选的分析模型。
设计模型是源代码的抽象，由设计类和一些描述组成。
设计类被组织成具有良好接口的设计包（Package）和设计子系统（Subsystem），而描述则体现了类的对象如何协同工作实现用例的功能。
设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。
体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。
4.实现（Implementation）
实现工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式（源文件、二进制文件、可执行文件）实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。
5.测试（Test）
测试工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现,识别并确认缺陷在软件部署之前被提出并处理。
RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。
测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。
6.部署（Deployment）
部署工作流的目的是成功的生成版本并将软件分发给最终用户。
部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：
软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。
在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。
7.配置和变更管理（Configuration&ChangeManagement）
配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。
配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。
工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。
同时也阐述了对产品修改原因、时间、人员保持审计记录。
8.项目管理（ProjectManagement）
软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。
其目标包括：
为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。
9.环境（Environment）
环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。
环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。
RUP的迭代开发模式
RUP中的每个阶段可以进一步分解为迭代。
一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统.
传统上的项目组织是顺序通过每个工作流，每个工作流只有一次，也就是我们熟悉的瀑布生命周期。
这样做的结果是到实现末期产品完成并开始测试，在分析、设计和实现阶段所遗留的隐藏问题会大量出现，项目可能要停止并开始一个漫长的错误修正周期。
RUP的迭代开发过程是受控的，在项目计划中就制定了项目迭代的个数、每个迭代的延续时间以及目标。
在每一个迭代的起始阶段都制定详细的迭代计划以及具体的迭代工作流。
每次迭代过程都生成该次迭代的Release.作为下次迭代的基础。
在迭代结束前，都应执行测试工作，并仔细评估该迭代过程，为下一次迭代做准备。
迭代并不是重复地做相同的事,而是针对不同UseCase的细化和实现.
UML概念可以划分为以下范围：
系统需求;静态结构;动态行为;交互行为;物理实现;各种图之间的关系;模型组织;扩展机制
系统需求
用例视图（UseCasesView）从外部用户的角度来描述系统的行为，它将系统功能划分为对用户有意义的事务，这些事务被称为用例，用户被称为执行者，用例视图也就是描述活动者在各个用例中的参与情况，它指导所有的行为视图。
静态结构
静态视图（StaticView），一个模型必须首先定义各种事物的内部特征和相互之间的关系，应用概念建模成类，类描述事物的属性和以及在这些属性上的操作。
类之间可以存在不同的关系，比如泛化（继承）、关联和依赖等，静态视图表示成类图，静态视图在某一时刻的快照称为对象图。
动态行为
状态机视图（StateMachineView），通过对每个类的对象的生命周期进行建模，描述了对象时间上的动态行为。
状态机是由状态和迁移组成的图，状态机通常附属于类，描述类实例对接受事件的响应。
活动视图（ActivityView）是利用状态机对运算和工作流进行建模的特殊形式。
活动图的状态代表了运算执行的状态，而非一般对象的状态，活动图和流程图很相似，不过它支持并发。
交互行为
交互视图（InteractionView），对象通过交互来实现行为，交互视图通过协作来进行建模，协作具有结构和行为两个方面，结构包含为行为方面而定义的一系列角色和关系，行为方面是绑定于角色的对象间的一系列交换的消息，这些消息在协作中称为交互，消息序列可用两种图来表示：
顺序图（重点在消息的时间顺序）和协作图（重点在交换消息的对象间的关系）。
物理实现
物理视图（PhysicalView），许多系统模型独立于最终的实现，在实现方面，必须充分考虑系统的重用性和性能。
UML有两种视图来表示系统的实现：
实现视图和部署视图，实现视图将可重用的系统片段打包成组件，部署视图描述系统运行时资源的物理分布，这些资源称为结点。
各种图之间的关系
静态视图（类图，对象图），物理视图（实现视图，部署视图）是描述系统的静态结构。
用例图是描述系统的外部视图。
活动图描述系统的外部/内部视图。
交互视图（顺序图，协作图）描述系统的内部视图。
状态图描述单个类的动态行为。
模型组织
模型管理视图（ModelManagementView），任何大系统必须划分为较小的单元，以使人们能在某一时刻只接触有限的信息，不影响团队间的并行工作。
模型是利用包（Package）和包的依赖来进行管理的。
包是UML模型中通用的层次组织结构，包上的依赖总结了包内容的依赖关系。
扩展机制
扩展机制（ExtensionMechanisms），UML能满足绝大部分系统建模的需要，但任何语言都不是万能的，它必须考虑一定的扩展机制，UML的扩展机制包括约束、标签值和原型。
这些扩展机制可以用来为特定领域剪裁UML的配置，这样带来一些好处：
根据自身需要来使用建模语言。
静态模型:
基本的模型元素
静态视图：
类图;对象图
分类：
类（Class;接口（Interface）;子系统（SubSystem）;执行者（Actor）;用例（UseCases）;组件（Component）;结点（Node）;注释（Comment）;
类:
是具有相同属性、操作和关系的对象集合的总称。
通常在UML中类被画成矩形，包括三个部分：
名称、属性和操作。
●名称：
每个类都必须有一个名字，用来区分其它的类。
类名是一个字符串，称为简单名字。
路径名字是在类名前加包含类的包名为前缀。
例如Wall、java:
:
awt:
:
Wall都是合法的类名。
●属性：
类可以有任意多个属性，也可以没有属性。
在类图中属性只要写上名字就可以了，也可以在属性名后跟上类型甚至缺省取值。
●操作：
操作是类的任意一个实例对象都可以调用的，并可能影响该对象行为的实现。
接口:
是未给出实现的对象行为的描述，接口包含操作，但没有属性，一个或多个类可以实现接口，每个类实现接口的操作。
包:
可以包含各种模型元素和其它的包，包之间还可能存在一定的依赖。
子系统:
是具有独立的说明和实现部分的包，它代表了与系统其它部分具有清晰接口的清晰单元，它通常代表了系统在功能或实现范围上的划分。
执行者:
是与系统、子系统或类交互的外部人员，进程或事务。
在运行时，具体人员会充当系统的多个执行者，不同用户可能会成为一个执行者。
用例:
是系统提供的外部可感知的功能单元，用例的目的是定义清晰的系统行为，但不解释系统的内部结构。
用例可以与执行者关联，也可以参与其他的多种关系，比如扩展、泛化和包含等。
用户的动态部分用交互视图来描述，比如顺序图、协作图。
用例用椭圆来表示，用例名标在椭圆下方，用实线与同自身通信的用户相连。
组件:
是可重用的系统片段，具有良好定义接口的物理实现单元。
每个组件包含了系统设计中某些类的实现。
组件设计的原则：
良好的组件不直接依赖于其它组件，而是依赖于其它组件所支持的接口。
这样的好处是系统中的组件可以被支持相同接口的组件所取代。
结点:
代表系统运行时的物理对象，结点通常拥有运算能力，它可以容纳对象和组件实例。
注释:
用于解释设计的思路，便于理解。
关系：
关联（Association）;泛化（Generalization）;依赖（Dependency）;实现（Realization）;约束（Constraint）
关联:
描述了系统中对象和其它实例之间的离散的连接，关联是有序的，它允许重复，关联的实例是链。
关联至对象的连接点称为关联端点，很多信息被附在关联端点上，它拥有角色名、重数（多少个类的实例可以关联于另一个类的实例），可见性等。
关联有自己的名称，可以拥有自己的属性，这时关联本身也是类，称为关联类。
聚集（Aggregation）:
用来表达整体－部分关系的关联。
组合（Composition）:
是一种聚集，是关联更强的形式。
泛化:
是一般化和具体化之间的一种关系。
继承:
就是一种泛化关系，更一般化的描述称为双亲，双亲的双亲称为祖先，更具体化的描述称为孩子，在类的范畴，双亲对应超类，孩子
多重继承:
一个孩子可以从多个双亲继承属性和方法。
多重继承可能存在冲突，因为被继承的双亲可能存在相同的类声明，这时，最好显式解决冲突问题。
依赖:
指明两个或两个以上模型元素之间的关系。
依赖有很多种类，比如：
实现（realize）、使用、（usage）、实例化（instantiate）、调用（call），派生（derive）、访问（access）、引入（import）、友元（friend）等等。
实现:
是依赖的一种，但由于它具有特殊意义，所以将它独立讲述。
实现是连接说明和实现之间的关系。
约束:
用来表示各种限制，如关联路径上的限制，和属性特征检测（存在、所有）。
静态视图:
是UML的基础，静态视图表示为类图，主要是描述类和类之间的关系。
对象图:
是系统在某一时刻的快照。
面向对象设计
面向对象设计继续做面向对象分析阶段的工作，建立软件的结构。
主要工作分为两个阶段：
高层设计;类设计;
高层设计（系统设计）
高层设计阶段开发系统的结构，即构造应用软件的总体模型；高层设计阶段标识在计算机环境中进行问题解决工作所需要的概念，并增加了一批需要的类；这些类包括那些可使应用软件与系统的外部世界交互的类。
；
此阶段的输出是适合应用软件要求的类、类间的关系、应用的子系统视图规格说明。
图一高层设计模型
高层设计的特点
高层设计可以表征为标识和定义模块的过程。
模块可以是一个单个的类，也可以是由一些类组合成的子系统。
定义过程是职责驱动的。
类接口的协议如同“合同”：
需方提出的请求必须列在协议表中，供方则必须提供所有协议的服务。
高层设计应遵循的原则
应使得在子系统的各个高层部件之间的通信量达到最小；
子系统应当把那些成组的类打包，形成高度的内聚；
逻辑功能分组，提供一个一个单元，识别并定位问题事件；
类设计（对象设计）
类与具有概念封装的子系统十分类似。
每个子系统都可以被当做一个类来实现，这个类聚集它的部件，提供了一组操作。
类和子系统的结构是正
升级会员 