标签：迭代 对象 系统 视图 基本概念 面向对象 RUP 方法 面向对象分析
本系列博客只综述当前作者《面向对象分析与设计》课程的重点内容，该系列博客主要有：《面向对象基本概念》、《UML语言》、《需求理解》、《面向对象分析》、《面向对象设计》、《设计模式及模式应用》、《数据库设计》、《MDD、SOA、AOSD》等等，由于该系列博客会在我复习阶段进行编写和总结，可能不会全部完成。 另：博客中如果存在不正确地方麻烦大家指正
如果你觉得本博客有所帮助的话，记得点个赞，お願いします！
核心内容
- 面向对象基本概念
面向对象基本概念
一、Object、Class、Message
1. Object（对象）
定义：
- 是系统中用来描述客观事物的一个实体，它是构成系统的一个基本单位。 一个对象由一组属性和这组属性进行操作的一组方法组成。
- 对象是具有定义良好的边界和标识的实体，它封装了状态和行为。
状态：由属性和关系表示，是对象可能存在的条件之一，通常会随着时间而改变；
行为：行为由操作、方法和状态机表示，决定一个对象如何行动和反应，对象的可见行为由它可以执行的操作而定义；。
关键点：
- 对象是软件运行时才会存在的概念，一个对象代表了一个现实的或虚构的实体；
- 对象包括数据和方法，相同类的对象具有相同的数据和方法；
- 对象之间通过消息进行通信、交互，一个对象通过向另一个对象发送消息激活某一个功能；
- 对象只描述客观事物本质的、与系统目标有关的特征，而不考虑那些非本质的、与系统目标无关的特征；
- 在软件生命周期的不同阶段，对象可以有不同的表现形式；
- 每个对象都有唯一的标识，即使状态与另一个对象相同；
- 一个对象不会独自承担所有任务，也不会没有存在的意义；
- 在不是纯面向对象语言中允许有不属于任何对象的成分存在，例如C++程序中的main函数。
2. Class（类）
定义：
类是具有相同属性和方法的一组对象的集合，它为属于该类的全部对象提供了统一的抽象描述，其内部包括属性和方法两个主要部分。
个人理解：类是一个抽象的概念，统一描述了一组具有相同属性和方法的对象。像马、汽车、人都是抽象的概念，都是类；而具体到某一匹马、某一辆车、某一个人时，他们都是对象。
关键点：（类和对象的关系）
- 类是对象的抽象，它给出了属于该类的全部对象的抽象定义（从对象产生类）；
- 类是对象的模板，用它可以产生多个对象，一个具体的对象只是类的一个实例（从类产生对象）；
- 同类对象具有相同的属性和方法，是指它们的定义形式相同，而不是说每个对象的属性值都相同；
- 类是静态的，类的存在、语义和关系在程序执行前就已经定义好了；
- 对象是是动态的，对象在程序执行时可以被创建和删除；
3. Message（消息）
定义：
- 消息是一种对象之间通信的规范，该规范传递信息，并期望活动随之发生（一个对象请求另一个对象执行操作）；
- 消息是对象发出的服务请求，它包含下述信息：提供服务的对象标识、服务（方法）标识、输入信息、回答信息。
个人理解：消息本质就是对象之间的函数/方法调用，所谓 “提供服务的对象标识、服务（方法）标识”即Object.Method()，而“输入信息”即方法中的参数Object.Method(Value)，而回答消息就是对象执行完方法后的return。
关键点：
- 对象之间通过消息进行通信，是面向对象(OO)方法的一个原则；
- 采用消息术语，而不是函数调用，是因为消息更接近人们日常思维所采用的术语，其次消息的含义更具有一般性，不限制采用任何实现技术
二、Basic Principles of Object Orientation
面向对象的基本准则/原则
1. Abstraction（抽象）
定义：
抽象指从特定角度出发，从已经存在的事务中抽取出我们所关注的特性，形成一个新的事物的过程。抽象是一种从具体到抽象，由复杂到简单的思维方式。如下图：抽象过程。
2. Encapsulation（封装）
定义：
- 封装就是把对象的属性和方法结合成一个独立的系统单位，并尽可能隐蔽对象的内部细节；
- 封装意味着在设计、生产和描述软件时，用户可以在不了解其工作细节的情况下轻松使用软件，也被称为信息隐藏。
解释：面向对象编程中的接口就是封装的具体表现方式，接口向用户提供调用方法的方式，而隐藏了实现方法具体细节。万物都是接口，如手机，我们通过简单地点击屏幕即可实现各种功能，但我们不了解这些功能具体实现的细节。
关键点：
- 封装就是使一个对象的形成分成两个部分：接口和实现，对于用户而言，接口是可见的，而实现是不可见的；
- 封装提供两种保护：一保护对象，防止用户误用；二保护客户端，封装能减小实现过程改变的副作用，即实现过程的改变不会影响到相应客户端的改变。
解释：用户能且仅能调用接口实现操作，对于接口的实现，由于接口本身的存在将用户与接口的实现之间完全分隔开，用户不知道接口如何实现，接口实现方式改变也不影响用户调用接口，这应该也是封装的意义所在。
3. Inheritance（继承）
定义：
- 特殊类的对象拥有其一般类的全部属性与方法，称作特殊类对一般类的继承；
- 继承是组织类的一种方法。
解释：
- 继承即字面意思的继承。将多个类中的共有属性/方法进行抽象，定义为一个更一般的父类，继承父类的子类，其拥有父类中非私有的属性和方法。为什么这么做？当需要公共属性/方法时，可直接继承该父类，避免再次定义，增加软件重用的机会；
- 一般、一般类：一般与常见的含义一样，一般就是指更常见的东西，大部分人或事物都具有的东西，一般类是指有且仅有大多数类中都共有的属性和方法的类；
- 特殊、特殊类：特殊就是指少见，只有个别人或事物才具有的，特殊类是指具有其他大多数类都少有甚至没有的属性或方法的类；
- 一般类-特殊类：典型案例即父类和子类，父类中有且仅有所有子类中共有的属性和方法，子类中除了有继承父类得到的属性和方法，还可能有自己定义的独家的属性和方法，父类即一般类，子类即特殊类。
关键点：
- 继承保证类之间的一致性，父类可以为所有子类定制规则；
- 利用继承可以开发更贴近现实的模型；
- 继承增加软件重用的机会，降低开发和维护费用；
- 子类可以继承父类的属性/操作，也可以增加或重新定义继承的属性/操作。
继承分类：
- 单继承：子类只从一个父类继承
- 多继承：子类从多于一个的父类继承
4. Polymorphism（多态）
定义：
一个实体在不同的上下文条件中具有不同的意义或用法的能力，是保证系统具有较好的适应性的一个重要手段，是面向对象技术所表现出来的一个重要特征；
解释：一个draw()在圆圈情况下是画圆，在矩形情况下是画矩形，就像打开这个动作，在灯的情况下是开灯，在门的情况下是开门，所谓多态即同名的方法具有相同的功能，但是在不同的上下文环境中得到的结果不一样。
关键点：
- 覆盖和动态绑定是与多态相关的概念
覆盖：相同的方法名，但是方法被覆盖后实现的操作是不同的
动态绑定：相同的操作，但是绑定的对象不同时，操作的结果也不一样 - 多态属于运行时问题，重载是编译时问题
PS：覆盖override和重载overload的区别
三、Interface and Abstract Class
1. Interface（接口）
定义：
- 接口是指定类或组件的操作集合；
- 接口约束多态性；
----多态性,就是有多个类要实现相同的功能,这个时候你应该把这个相同功能的东西拿出来做成一个接口。约束这些子类 - 接口支持“即插即用”体系结构；
----调用对应接口的方法，只要调用方法正确、输入参数匹配，无需人工再干预，系统自动执行对应方法，即只要按着插口的插槽正确插入，就可直接使用 - 接口的约束是相互的。
----接口不仅约束了类的属性和方法，还会约束用户调用方法时输入的参数
接口表示
- 缩略图方法 Elided/lconic Representation
- 正则表达式 Canonical（Class/Stereotype）Representation
2. Abstract Class（抽象类）
定义：
- 抽象类是没有任何直接实例的类；
- 在UML中，您可以通过用斜体书写一个类的名称来指定它是抽象的；
- 抽象操作是不完整的操作，需要子操作提供该操作的实现。
个人理解： 抽象类是一个无法直接实例化的类，是一个只能被继承的类，其中的方法也是抽象、不完整的，需要继承该类的子类进行完善
四、UML-介绍
1. 定义
面向对象： 是以对象为核心、以类和继承为构造机制、以接口和多态提供灵活性的方法。
UML： UML是统一建模语言，用于可视化、指定、构建、记录软件密集型系统的产物，主要由面向对象和可视化建模构成。
2. 特点
- 统一的标准：已成为面向对象的标准化的统一的建模语言；
- 面向对象设计；
- 可视化、表达能力强大
- 独立于过程；
- 概念明确，建模表示法简单，图形结构清晰，容易掌握使用。
3. UML构成
关于图的部分说明：
- UML1.x版本中有九类图：
class diagram (类图)、
object diagram (对象图)、
use case diagram (用例图)、
sequence diagram (顺序图)、
collaboration diagram (协作图)、
statechart diagram (状态图)、
activity diagram (活动图)、
component diagram (构件图)、
deployment diagram (部署图) - 在UML2.0版本中有：
Activity Diagram（活动图）
Class Diagram （类图）
Communication Diagram (通信图)
Component Diagram （构件图）
Composite Structure Diagram (组成结构图)
Deployment diagram （部署图）
Interaction Overview Diagram (交互概要图)
Object Diagram （对象图）
Package Diagram （包图）
State Machine Diagram (状态机图)
Sequence Diagram （时序图）
Timing Diagram (定时图)
Use Case Diagram （用例图）
4. UML在系统开发各阶段的应用
- 在分析阶段，用户的需求用UML模型来描述；
- 在设计阶段，引入定义软件系统中技术细节的类（如处理用户接口、数据库、通信和并行性等问题的类）；
- 在实现阶段，用面向对象程序设计将来自设计阶段的类转换成实际的代码；
- 在测试阶段，单元测试使用类图和类规格说明，集成测试使用构件图和协作图，系统测试使用用例图来验证系统的行为。
5.一个UML的例子
五、对象、职责、协作
注：本部分是根据网上博客整理（出处）。
- 面向对象方法的主要任务：处理对象、职责、协作三者的各种关系，使构造出的系统能解决特定的问题；
- 对象、职责、协作在面向对象方法中相互关联，共同构成面向对象方法的核心内容。
解释：
使用面向对象方法时，首要任务是找出系统中和要解决的问题相关的对象，为每个对象分配职责。当一个任务不能由一个对象来完成时，需要找出或添加其他对象来和这个对象协作来完成任务。此外，对系统中的公共任务，可以将这些任务分配给专门的公共对象来完成。其他的对象需要使用这些公共任务任务时，只要使用公共对象即可。
1. 对象
定义： 对象是完成任务的载体。
发现对象：
对象的发现并非单向过程，而是在职责分配和协作关系定义中需要循环往复。增加的对象和协作关系可能对已有的结构造成变更或需要优化，这个过程就是目前所说的重构。重构在整个开发过程中起到不断的改进和精炼的作用，使构造的系统能更符合业务需求。
2. 职责
定义： 职业是系统分配给对象的任务。
职责分配：
对象职责的分配取决于对象在系统中的作用以及其他对象的作用，对于可以由一个对象完成的任务，就不要分配给多个对象；如果任务大到需要多个对象来完成，职责的分配要体现对象内部的紧耦合和对象间的松耦合。
3. 协作
定义： 协作是当一个任务由多个对象共同完成时，对象之间必须要进行分工协作，以实现对象内的紧耦合、对象间的松耦合，保证系统的可扩展能力。
协作关系：
- 对象间的协作关系包括引用和继承。引用通常都通过针对接口引用来实现对象间的松耦合，当接口不变时，对象内部实现的修改不会对引用它的对象造成任何影响，增强了系统的可扩展性。
- 继承相对引用是一种紧耦合关系，子对象和父对象都是属于同一种类型，子对象可以覆盖父对象中可访问的方法，当父类增加虚方法时，所有继承的子类必须增加对虚方法的实现。另外，由于java，c#不支持多继承，因此当一个任务需要不同类型的对象来完成时，通过单一继承比较难实现。
4. 职责和协作
对象内部的职责和对象间的协作关系的不同组合可用于解决各种不同的问题，对于一些特定的问题，可以采用固定的一些组合方式去解决，这种组合方式就是常说的设计模式。仔细研究一下GoF设计模式的内容，都是对象以及对象间以某种特定方式组合起来解决一个特定的问题。因此，如果要想发现或提出新的设计模式，就需要对对象以及对象间的协作进行研究和分析，针对特地的问题抽象出特定的关系。
六、The Rational Unified Process(Rational统一过程)
本部分参考《试贴：Rational Unified Process 简介》、《RUP(Rational Unified Process)统一软件过程概述》、《RUP 方法简介》
1. 介绍
Rational Unified Process（以下简称RUP） 是一套软件工程方法，主要由 Ivar Jacobson的 The Objectory Approch 和 The Rational Approch发展而来。同时，它又是文档化的软件工程产品，所有RUP的实施细节及方法导引均以Web文档的方式集成在一张光盘上，由Rational公司开发、维护并销售，当前版本是5.0。RUP又是一套软件工程方法的框架，各个组织可根据自身的实际情况，以及项目规模对RUP进行裁剪和修改，以制定出合乎需要的软件工程过程。
2. 二维开发模型
在RUP中，软件开发生生命周期根据时间和RUP的核心工作流划分为二维空间（如下图所示），从图中的阴影部分表示的工作流可以看出，不同的工作流在不同的时间段内工作量的不同。值得注意的是，几乎所有的工作流，在所有的时间段内均有工作量，只是工作程度不同而已。这与Waterfall process(瀑布式开发模型)有明显的不同。
3. RUP核心的基本原理
它们支持应用迭代方法进行软件开发：
- 尽早并且不断的化解重大风险
- 确保满足客户的需求
- 把注意力集中放到可执行的软件上
- 尽早在项目中适应变化
- 在早期确定一个可执行架构
- 使用构件构造软件系统
- 建立高效团结的开发团队
- 始终重视质量
4. 静态结构：方法描述
软件开发过程描述了什么时候，什么人，做什么事，以及怎样实现某一特定的目标。
四个基本模型元素
- 角色-the who(什么人)： 描述某个人或一个小组的行为与职责。一个开发人员可以同时是几个角色，一个角色也可以由多个开发人员共同承担。RUP预先定义了很多角色，例如：Architect(架构师)、Use-Case Designer(用例设计人员)、Course Developer、Implementer(实现人员) …，并对每一个角色的工作和职责都作了详尽的说明。
- 行为-the how(如何做)： 是一个有明确目的的独立工作单元。产品是行为生成、创建或修改的一段信息。它是行为的输入同时又是它的输出结果。产品以多种形式存在，例如：模型（Model）、源代码、可执行文件、文档等。
- 产品-the what(什么事)： 模型是从某一个角度对系统的完全描述。RUP的很大一部分工作就是设计和维护一系列的模型，这其中有Use Case Model、Business Model、Analysis Model、Design Model等。所有的这些模型都以UML描述，因此它们是标准的并为多种CASE工具支持。RUP并不鼓励写在字面上的文挡，产品应尽可能地在CASE工具中创建和修改并为版本管理工具跟踪和维护，它们在整个软件开发周期中动态地增加和修改。当然也可以根据需要为模型生成报告（Reports），但它们是静态的，是某一时刻模型的快照不需要维护和修改。
- 工作流-the when(什么时候)： 描述了一个有意义的连续的行为序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。RUP主要提供两种组织工作流的方式：核心工作流（Core Workflow）和迭代工作流（Iteration Workflow）。
九个核心工作流
- 商业建模（Business Modeling）：理解待开发系统的组织结构及其商业运作，确保所有参与人员对待开发系统有共同的认识。
- 需求分析（Requirements）：定义系统功能及用户界面，使客户知道系统的功能，开发人员知道系统的需求，为项目预算及计划提供基础。
- 分析与设计（Analysis and Design）：把需求分析的结果转化为实现规格。
- 实现（Implementation）：定义代码的组织结构、实现代码、单元测试、系统集成。
- 测试（Test）：校验各自子系统的交互与集成。确保所有的需求被正确实现并在系统发布前发现错误。
- 发布（Deployment）：打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。制定并实施beta测试。
- 配置管理（Configuration and Change Management）：跟踪并维护系统所有产品s的完整性和一致性
- 项目管理（Project Management）：为计划、执行和监控软件开发项目提供可行性的指导；为风险管理提供框架。
- 环境（Environment）：为组织提供过程管理和工具的支持。
4. 动态结构：迭代式开发
- 在时间维上，为了能够方便地管理软件开发过程，监控软件开发状态，RUP把软件开发周期划分为多个Cycles(周期),每个Cycle生成一个产品的新的版本。每个Cycle都依次由四个连续的阶段(pahse)组成，每个阶段都应完成确定的任务。
- 每一个阶段都由一个或多个连续的迭代组成，每一个迭代都是一个完整的开发过程是一个具体的迭代工作流从头到尾的执行。与核心工作流不同的是RUP并没有也无法给出迭代工作流的具体实现步骤，它需要项目经理根据当前迭代所处的阶段、以及上次迭代的结果，适当地对核心工作流中的行为进行剪裁以实现一个具体的迭代工作流。
- RUP的迭代开发过程是受控的，在项目计划中就制定了项目迭代的个数、每个迭代的延续时间以及目标。在每一个迭代的起始阶段都制定详细的迭代计划以及具体的迭代工作流。每次迭代过程都生成该次迭代的Release. 作为下次迭代的基础。在迭代结束前，都应执行测试工作，并仔细评估该迭代过程，为下一次迭代做准备。迭代并不是重复地做相同的事，而是针对不同Use Case的细化和实现。
RUP软件生命周期的四个阶段
- Inception：起始阶段－构建最终产品的设想和业务案例，确定项目范围
- Elaboration：细化阶段－计划必要的活动和资源，详细确定功能并设计架构
- Construction：构建阶段－构建产品，直到一个可交付用户的产品完成
- Transition：移交阶段－产品交付用户，包括制造、交付、培训、支持、维护等
5. 使用 Use Case 驱动
-
传统的面向对象开发方法因为缺乏贯穿整个开发过程的线索，因此很难阐述清楚一个软件系统是如何实现其功能的。在RUP中，Use Case Model就是这样一个线索它是整个软件开发过程的基础。
-
Use Cases Model是需求分析工作流的结果,它从用户的角度描述该系统应该实现的功能。利用Use Case Model 可以有效地界定系统范围及其行为, 并为用户及开发人员认同。Use Case Model 主要由Use Cases 和演员（Actors）构成。Use Case是系统执行的一系列行为，并为Actor生成一些有意义的结果。Actor是所有与本系统有交互的外部系统，可以是人、其他软件系统等。下图是一个Use Case Mode的例子：
-
Use Case作为分析与设计工作流的输入，是实现分析与设计模型的基础。设计模型作为实现工作流的规格说明书，它自然要实现Use Case 模型所定义的功能。同样在测试工作流中，Use Case Model 组成测试实例，用来有效地校验整个系统的正确性。另外，Use Case还是用户手册的基础、并驱动整个迭代开发过程的运作，所以我们说Rational Unified Process是由Use Case 驱动的。
6. 以体系结构为中心
- 体系结构使得开发人员及用户能够更好地理解系统的逻辑结构、物理结构、系统功能及其工作机理，也使系统能够更加容易修改及扩充。但是由于对体系结构的目的及其定义一直模糊不清，且表示方法的混乱一直影响着它的应用。
- 由于在项目的开发过程中不同的开发人员所关心的角度是不一样的，因此软件的体系结构应该是一个多维的结构，RUP采用如下图所示的4+1View（视图）模型，利用UML语言来描述软件的体系结构。这5个视图都是从相应的模型中抽取出对系统的结构、功能、健壮性及其可扩充性有重要意义的元素构成。是各模型的精华与核心部分。
- Use Case是驱动软件的开发周期的原动力，但是分析与设计工作流是以软件体系结构(Architecture)为核心的。RUP的早期的迭代工作，特别是演化阶段的重点就是确定和校验软件的体系结构。演化阶段的MileStone的一个关键任务就是确定该系统的体系结构是否健壮、成熟以及稳定。
7. RUP的优点
- 迭代式开发方法是一个不断的减除风险的过程,每一次的迭代过程都选择最关键的也是风险最大的Use Cases执行。因此风险在迭代过程中不断地被发现、消灭。
- 迭代式开发方法能够更容易地管理需求的变化，整个开发过程由一次次的独立的迭代所组成，项目经理能够比较容易地调整迭代过程，使最终产品实现变化的需求。大部分的产品都存在CASE工具中，并为配置工作流所管理，使得所有开发人都能够及时地知道这种变化，制定相应的对策。
- 开发人员以及项目相关人员能够及时地从迭代过程中得到反馈信息，并能够及时修改以前工作中的失误，有效地监控开发过程，并对迭代工作流进行校正，这对一个时间跨度很长的项目具有重要的意义。
- 以Use Case驱动、体系结构为中心使得开发人员比较容易地控制整个系统的开发过程，管理它的复杂性、维护它的完整性。
- 体系结构中定义清晰、功能明确的组件为基于组件式的开发、大规模的软件复用的提供有力的支持，并是项目管理中计划与人员安排的依据。
- Rational公司提供了丰富的CASE工具支持RUP。比如：可视化建模工具Rational Rose;需求管理工
- Requisite Pro; 版本管理工具Clear Case ; 文档生成 SoDa; 测试工具：SQA, Perfomence等。由于RUP采用标准的UML描述系统的模型基体系结构，因此可以利用很多第三方厂家提供的产品。
- RUP能够达到软件工程研究所制定的CMM（Capability Maturity Model）模型的2级或3级。
8. 总结
Rational Unified Process 是新一代的软件工程方法。与早期的瀑布式开发模型相比，它具有迭代式的增量开发、使用实例驱动、 以软件体系结构为核心三个鲜明特点，这使得RUP非常适宜于开发复杂、技术难度大、需求多变、高风险的项目。RUP又是可裁剪的软件开发过程框架，各组织可以根据自身及项目特点对RUP进行裁减，在某些情况下RUP甚至可以蜕化为瀑布式开发模型。
七、Software Architecture(软件架构)
软件体系结构包含关于软件系统组织的一组重要决策：
- 选择组成系统的结构元素及其界面；
- 在这些元素的协作中指定的行为；
- 将这些结构和行为元素组成更大的子系统；
- 指导该组织的架构风格。
软件体系结构涉及：
使用、功能、性能、弹性、重用、可理解性、经济和技术限制、美学考虑。
架构限制了设计和实现：
体系结构涉及一组约束设计和构造的战略设计决策、规则或模式，架构决策是最基本的决策，更改它们将产生重大的连锁反应。
所有软件架构定义中的共同主题：
动机中的强大思想、组织、风格、模式、责任、协作、联系、动机、主要子系统。
架构的元模型(Booch)：
架构视图：
- 架构视图是从特定的角度或有利位置对系统进行简化的描述(抽象)，涵盖特定的关注点，并省略与此角度不相关的实体，典例是RUP 4+1 View 视图，此外还有数据视图、安全视图。
- 视图需求：简化模型以适应环境，并非所有的系统都需要该系统所有的视图，例如单进程系统就不需要进程视图，极小的程序就不需要实现视图，对于实际问题需要具体问题具体分析，哪些问题需要交流沟通，哪里就需要建立视图。
架构风格：
架构风格定义了组件和连接器类型的词汇表、一组关于如何组合它们的约束、一个或多个语义模型，指定了如何从系统各部分的属性确定系统的总体属性。
架构上重要的模型元素：
注：并非所有的设计都是框架。架构视图等价于对模型进行切片。
- 主要的业务类；
- 重要的机制；
- 处理器和流程；
- 层和子系统。
架构的专注点：
架构可以代表一个系统的整体设计，但单个视图只关注自己的具体方面：
- 模型的结构–组织模式，例如分层、MVC等；
- 基本元素，关键用例、主类、通用机制等等，与模型中存在的所有元素相反；
- 一些关键场景，显示了整个系统的主要控制流（关键用例）；
- 服务，以获取模块化、可选特性、产品线等方面。
良好架构的特点：
- 弹性；
- 简单，易重用；
- 易理解；
- 关注点清晰；
- 架构中各部分责任分配清晰；
- 平衡经济与技术限制。
八、The “4+1 View” Model(4+1视图模型)
本部分主要参考博客《软件架构设计4+1 view模型》
1. 逻辑视图（Logic View）
- 逻辑视图主要用来描述系统的功能需求，即系统提供给最终用户的服务，在逻辑视图中，系统分解成一系列的功能抽象、功能分解、功能分析，这些主要来自于问题领域。
- 在面向对象技术中，通过抽象、封装、继承，可以用对象模型来代表逻辑视图，可以用类图来描述逻辑视图，其中构件是类、类服务、参数化类、类层次，连接件是关联（聚合、使用、继承、实例化）。
2. 开发视图（Development/Module View）
- 开发视图主要通过程序或子系统用来描述软件模块的组织与管理，服务于软件编程人员，方便开发者的设计与实现。
- 它通过系统输入输出关系的模型图和子系统来描述。主要考虑软件的内部需求，包括开发的难易程度、重用的可能性、通用性、局限性等等。
- 开发视图的风格通常是层次结构，层次越低，通用性越好。
- 它的主要构件是模块、子系统、层，连接件是参照相关性、模块/过程的调用。
3. 进程视图（Process View）
- 进程视图侧重系统的运行特性，关注非功能性的需求（性能、可用性），服务于系统集成人员，方便开发者后续的性能测试。
- 强调并发性、分布性、集成性、鲁棒性（容错）、可扩充性、吞吐量等。
- 它用于定义逻辑视图中的各个类的具体操作是在哪一个线程中被执行的。
- 它的构件是进程、简化进程、循环进程，连接件是未指定、消息、远程过程调用、双向消息、事件广播等。
4. 物理视图（Physical View）
- 物理视图主要描述硬件配置，服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。
- 主要考虑如何把软件映射到硬件上，同时还考虑系统性能、规模、可靠性等，可以与进程视图一起映射。
- 它的构件是处理器、计算机、其他设备，连接件是通信协议。
5. 场景（Scenarios）
场景用于刻画构件之间的相互关系，将四个视图有机地联系起来。可以描述一个特定的视图内的构件关系，也可以描述不同视图间的构件关系，用文本、图形表示皆可。
标签：迭代,对象,系统,视图,基本概念,面向对象,RUP,方法,面向对象分析 来源： https://blog.csdn.net/weixin_45928161/article/details/121783148
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。