面向对象建模技术

1.从结构化到面向对象模型:

1.1 结构化与面向对象的区别:

结构化思维用过程刻画数据间关系.对象思维直接用类表达数据间关系.结构化中，数据是死的，全部依赖 算法操作.对象思维中，数据是活的， “她”知道自己的信息(属性)，并能完成自己的工作(操作) .结构 化思维更像是一个人在解决所有问题.对象思维更像是一个团队的分工协作.

1.2: 面向对象方法:

面向对象方法(Object-Oriented Method)是一种把面向对象的思想应用于软件开发过程中，指导开发 活动的系统方法，简称OO (Object-Oriented)方法.面向对象方法的作用和意义决不只限于编程技术.它 是一种程序设计范型-面向对象程序设计范型；是软件系统开发的方法论-面向对象方法学；是流行的技 术-面向对象技术。

1.3: 面向对象技术:

面向对象技术是一系列指导软件构造的原则(如抽象、封装、多态等)，并通过语言、数据库和其它工 具来支持这些原则.从本质上讲，对象技术是对一系列相关原则的应用OO=类+对象+抽象+封装+继承+多 态+消息 … …

1.4: 面向对象技术基本点:

1.任何客观的事物或实体都是对象。对象组成客观世界，复杂对象可以由简单的对象组成。

2.具有相同数据和操作的对象可以归并为一个类(class ) ，对象是对象类的一个实例。 3.类可以派生出子类，子类继承父类的全部特性(数据和操作)，又可以有自己的新特性。

4.子类与父类形成类的层次结构。 对象之间通过消息传递相互联系。

1.5: 面向对象技术的优势:

1.顺应人类思维习惯，让软件开发人员在解空间中直接模拟问题空间中的对象及其行为.更要容易被开发 人员所接受.

2.稳定较小的需求变化不会导致系统结构大的改变.

功能最不稳定,数据次之,对象相对最稳定,而面向对象用对象承载功能和数据,用相对稳定的把不稳定 的”包”起来.

3.复用代码重用：类库、框架等重用机制能提高质量，减少由于编制新的系统代码而产生的成本通过继 承、关联、封装等手段.

软件开发组越大，组中每个成员的生产率就越低–Philippe Kahn, Borland公司创始人.

1.6: 对象定义:

对象是一个实体，该实体：

1.具有明确定义的边界和标识边界意味着对象是一个封装体，通过封装来与其它对象分隔.标识则表明每 一个对象都是唯一的(在程序运行的时候，用计算机内存地址表示对象)

2.对象封装了状态和行为对象的状态通过对象的属性(attribute)和关系(relationship)来表达.对象的行为 通过对象的操作(operation),方法(method)和状态机(state machine)来表达

1.7: 面向对象相关原则:

1.7.1: 抽象-Abstraction:

对象到类的过程就是抽象即将所见到的具体实体抽象成概念，从而在计算机世界中进行描述和各种操作.

1.7.2: 封装-Encapsulation:

封装是对客户(使用者)隐藏具体实现细节.客户只依赖于接口通过封装实现信息隐藏和数据抽象.

比如在c语言中,对数据的访问没有限制.这就导致操作这个数据结构的程序员，必须严格遵守一系列业务 逻辑规则，否则很容易破坏数据的一致性.结构化程序设计处理大项目时，多人协同开发时，本质上无法 保证数据的一致性.

但在面向对象的设计方法中,通过封装把数据隐藏起来,使得该数据无法被其他开发人员随意的修改.

1.7.3: 分解-Decomposition:

分解是指将单个大规模复杂系统划分为多个不同的小构件分解的构件通过抽象、封装等技术形成相对独 立的单元，可以独立设计和开发，从而实现化繁为简、分而治之.

面向对象设计中的模块化，将根据需要将类分组放在一些包中.

1.7.4: 泛化-Generalization:

泛化是类之间的一种isa/ is kind of 关系,通过该关系一个类(子类)可以共享另外一个或多个类(父 类)的结构和行为.

采用继承(Inheritance)实现泛化关系通过泛化关系，可以建立类之间的层次结构，根据继承层次中父 类的个数不同，分为：单一继承.多重继承(Java不允许).

1.7.5: 多态-Polymorphism:

多态是在统一外表(接口)下隐藏不同实现的能力.

即一个接口可以有不同的实现行为.

是面向对象技术的本质特征.

多态是类型理论中的概念，其中，一个名字可以代表许多不同类的实例，只要它们有共同的超类。

1.7.6: 分层-Hierarchy:

分层是指面向不同的目标建立不同的抽象级别层次，从而在不同的抽象层次对系统进行分解，进一步简 化对系统的理解.

两种分层结构类层次结构：

(1)在不同的抽象级别进行对象的抽象，通过泛化关系，形成类间的继承层次结构.

(2)对象层次结构：是指对象间的组成结构，即大的对象由小的对象组成.

1.7.7: 复用-Reuse:

复用是借助于已有软件的各种有关知识建立新的软件的过程.

将软件看成是由不同功能部分的构件所组成的有机体，每个构件在设计编写时可以被设计成完成同类工 作的通用工具.

如果完成各种工作的构件被建立起来以后，编写特定软件的工作就变成了将各种不同构件进行组合的简 单问题，从而对软件产品的最终质量和维护工作都有本质性的改变.

系统开发各个阶段都可能涉及到复用.

从最底层的代码复用，到设计复用、架构复用，再到需求复用，甚至于延伸到特定业务领域的复用.

复用原则要求设计者不仅针对当前的业务需求开展设计，还需要考虑业务的通用性和可扩展性等问题， 从而设计抽象层次高、复用粒度大的组件.

2.可视化建模:

2.1: 瀑布模型:

1.瀑布模型的性质:

不同的开发阶段应该被连贯地进行.每个阶段都有文档，上一个阶段的文档是下一个阶段文档工作的基础. 系统部署后，进入维护阶段.

2.瀑布模型的优点:

将软件开发当做工程对待.

3.瀑布模型的缺点:

没有引入迭代.

2.2: 统一过程模型:

统一过程(THE UNIFIED PROCESS)试图在整体开发过程模型中结合迭代与渐增两种思想.

特点:

每项活动都可以在任何一次迭代发生，但是重心随着开发过程的进行，每次迭代的重心都不同.

2.3: UML:统一建模语言

UML — Unified Modeling Language.

UML是一种标准的图形化建模语言，是面向对象分析与设计的标准表示，它不是一种程序设计语言，而 是一种可视化的建模语言(用于分析设计).

Unified Modeling Language (统一建模语言)是对象管理组织(OMG)制定的一个通用的、可视化的 建模语言标准，可以用来可视化(visualize) 、描述(specify)、构造(construct)和文档化 (document)软件密集型系统的各种工件(artifacts，又译制品) .

2.4: 结构:

UML主要包括两类图:

结构图: 结构图用于表示系统中元素的静态结构，例如系统组织结构，例如，类图系统的物理元素，例 如，包，组件图运行时配置等.

行为图: 用来描述动态行为对象的创建与销毁对象按照顺序发送消息外部事件引发了特定的对象的操作.

2.5: 4+1模型:

UML试图在5个方面刻画一个软件.

系统的结构用五个视图(Views)描述，用例视图在集成其他四个视图的内容中起着特殊的作用。

2.6: 类图:

类图表示类的存在以及从逻辑层面表达它们之间的关系.

类图的基本要素：类，以及它们之间的关系.

类图中一个类的结构:

类图中类之间的关系:

2.7: 聚合与组合:

聚合 (aggregation): “part of” 关系.不是物理包含关系.表示一种弱关联.有独立的生命周期.

组合(composition)的概念：整体包括部分,是一种物理包含.一个部分对象仅仅对应于1个整体对象；该整 体对象如果不存在，则部分对象也就没有存在的必要组合中，创建“整体”对象，则要创建“部分”对象；消 灭“整体”对象，其组合的“部分”也必须被消灭。相反，如果“部分”对象被消灭，则“整体”对象也必须被消 灭.一般在构造函数中引入.

2.8: 类的可视性记号:

出现在uml类图中的符号:

Public (+)：所有的其它类都可以访问 .

Protected (#)：类中的元素以及子类中的元素可访问 .

Private (-): 仅类中的元素可以访问.

Package (~): 仅仅同一个包中的元素可以访问.

2.8.2: 对象图:

2.9: 构件图:

构件(Component)是系统中遵从一组接口且提供其实现的物理的、可替换的部分。

构件图(Component diagram)则是显示一组组件以及它们之间的相互关系，包括编译、链接还在执 行时组件之间的依赖关系。

一个构件代表一个可复用的软件；提供一批有意义的功能在最底层，一个构件是一群(自己内聚的)松散耦 合的类系统中的每一个类必须在一个构件之中，或者在系统的顶层；一个构件可以包含其它构件.

可以利用构件层次地分解一个系统与表达系统的逻辑结构 (这是在UML2.0中新引进的；面向构件编程).

2.9.1: 基本元素:

components,构件

their interfaces, 接口

their realizations. 接口实现

2.10: 部署图(Deployment Diagram):

部署图被用来表示将工件分配到系统的各个物理设计节点的情况。部署图代表系统的工件结构的视图. 使用部署图表示系统执行平台的物理节点的集合；这些节点组成了系统的执行平台。

三个基本的部署图元素：工件、节点、连接符号.

2.11: 用例图:

用例图：描述将要创建的系统的环境与系统应该提供的功能描述谁与系统交互；即(外部世界) 用户让系 统做什么.

用例描述包括将系统作为一个黑匣子。描述人与系统之间的交互。

比如一个人去银行.他与系统进行的交互就是存现金,取现金,那么这就是两个用例.

2.12: 活动图:

与流程图比较类似.

]活动图提供了活动流的可视化描述(系统中，业务中，工作流，其它流程中)；

活动图关注应有的活动，以及谁负责完成这些活动.

3.建模过程:

3.1: 领域模型:

领域模型捕捉业务环境最重要的对象(产生类图).

领域模型代表存在的“实物” 或业务环境中出现的事件.

专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。

3.2: 用例模型:

一个用例图涉及到一个参与者与一个用例.表达的是功能化的需求.

3.2.1: 参与者：

在系统之外，透过系统边界与系统进行有意义交互的任何事物.参与者透过系统边界直接与系统交互，参 与者的确定代表系统边界的确定.

参与者可以通过泛化关系来定义，在这种泛化关系中，一个参与者的抽象描述可以被一个或多个具体的 参与者所共享.

识别参与者:

3.2.2: 用例:

例描述的是参与者与系统的交互，而不是系统内在的活动。因此用例的定义也应该只关注系统对外所体 现的行为，即用例止于系统边界.将系统视为黑匣子描述的不是内在的系统活动.

每个用例都会对参与者产生一个有价值的结果。

购买商品的会员构造一个”购买商品”的用例是合理的.倘若构造”查询商品”,”购买”这两个用例就是不好的 用例.

3.2.3: 用例其他注意事项:

(1)系统执行，每个用例所产生的结果值都是由系统生成的。

(2)用例从参与者的观点出发,而不是从系统的观点出发.

(3)粒度问题:

处理方式:

3.2.4: 用例图:

用例图：表达参与者与用例关系图形.

一个用例图实例:

3.3: 用例文档:

用例文档：描述用户与系统交互的需求说明书.

用例描述是需求的核心内容,而用例图作为用例文档的索引图.

用例文档要考虑到每个用例的各种场景.文档中每一句话都有其价值.

3.4: 重构用例模型:

(1)用例关系:

通过用例关系将复杂的用例进行适当的分解，以便于提高需求的复用性和可扩展性等，从而使用例模型 的结构更合理.

(2)用例分级:

可以根据用例的重要程度进行分级，以便后续迭代计划的制定，高级别的用例优先考虑用例分包将相关 的.

(3)用例分包:

将相关的用例打包，通过分包的方式可以将用例图分层表示，以用于大规模系统的用例建模。

3.4.1: 用例关系：

(1)Include(包含):

基用例中复用被包含用例的行为提取公共步骤，便于复用.

(2)Extend(扩展):

通过扩展用例对基用例增加附加的行为.

(3)Generalization(泛化):

派生用例继承泛化用例的行为并添加新行为.

重构的用例模型例子：

3.4.2：注意事项：

用例不是功能分解.使用用例进行功能分解，是用例使用过程中最容易出现的问题.用例是目标，不是过 程；用例不代表功能模块.

用例说明了系统所能提供的功能、服务，而软件分析/设计者可能会进行不同的设计.

3.5: 用例分析：

得到用例模型之后，进行用例分析，根据分析进行设计，从而得到类图，并编写代码。

分析：为了满足需求模型中所描述的功能，系统内部应该有什么样的业务核心机制(需要几个对象互相协 作呢？ )

分析的目标是开发一系列模型，以描述软件核心成分，从而满足客户定义的需求：称为分析模型。

需求模型以用户的角度描述系统所要实现的目标，而分析模型表示在系统内部应该提供哪些核心业务元 素和关系，以实现需求模型提出的目标(例如，要有哪些对象(类)的配合才能完成需求中所提出的功 能)。

用例模型被“翻译”成分析模型(用例描述 顺序图，用例描述中的重要名词被翻译成类名及其属性)

3.5.1:用例实现：

用例实现： 将用例行为分配给类

用例实现是分析/设计模型中系统用例的表达式。

用例实现描述了对象间的协作以完成用例目标。

用例实现将用例模型中的用例和设计(分析)模型中的类和关系连接在一起，说明了每个用例必须用那些类 来实现。提供了从分析和设计到需求的可跟踪性。

用例实现和用例是两个不同的概念，它们关注的重点不同.

用例(描述)面向用户，描述功能。

用例实现则面向分析设计人员，描述软件的内部结构。

构造用例实现是分析最核心的工作。

获得实现用例行为所必须的分析类，利用这些分析类来描述其实现逻辑。

3.5.2: 顺序图:

顺序图是一种交互图，描述对象之间的动态交互关系，着重体现对象间消息传递的时间顺序.

对象(Object)：对象、对象的生命线、对象的执行发生和对象的删除.

消息(Message)：简单消息、同步消息、异步消息、返回消息.

3.5.3: 专家模式:

是怎样将职责分配到分析类的指南.

将职责分配给具有当前职责所需要的数据的类如果一个类有这个数据，就将职责分配给这个类.

3.5.4: VOPC图:

对于每一个“用例实现”，需要绘制与之相关的类图，即VOPC图.

参与类类图(VOPC, View Of Participating Classes Class Diagram).

当所有的用例的VOPC图都画完了以后，就由此可以推导出分析类图.

3.6: 架构分析：

架构分析的过程就是定义系统高层组织结构和核心架构机制的过程。

​ ( 1)定义系统的备选架构来描述系统的高层组织结构—备选架构(选取层次结构， Client-server, MVC 等).

​ ( 2)提取系统的关键抽象以揭示系统必须能够处理的核心概念—关键抽象(领域模型图).

​ ( 3)创建用例实现来启动用例分析—用例实现 .

架构模式(软件体系结构，架构)表示了对软件系统的一个基础结构组织形式。它提供了一套预定义子系 统，详细说明它们的职责，并且包括组织它们之间的规则和指南。

经典的架构有：

​ ( 1)分层架构(层次架构)

​ ( 2) 模型-视图-控制器(M-V-C)

​ ( 3) 客户端-服务器架构 …

3.7: 分析类图:

最终目标是从系统的角度明确说明每一个分析类的职责和属性以及类之间的关系, 从而构造系统的分析类 视图。

分析阶段的重点在于找出体现系统核心业务所需数据的实体类，而界面和业务逻辑细节分别由边界类和 控制类隐藏.

在很多UML模型中，分析阶段的工作就是找到这些实体类.

这些实体类组成系统概念模型(分析类图).

通过比较各个用例的VOPC图，删除重复的与那些没有引用的实体类，即可得到由实体类组成的分析类 图，这些是分析的关键.

3.7.1: 类之间的关系：

​ ( 1)关联：关联是类之间的一种结构化关系，是类之间的语义联系表明类的对象之间存在着链接对象是 类的实例，而链接是关联的实例。

​ ( 2)自反关联：自反关联是指一个类自身之间存在关联，它表明同一个类的不同对象之间存在链接。

​ ( 3)聚合：聚合(Aggregation)关系是一种特殊的关联关系。

除了拥有关联关系所有的基本特征之外,两个关联的类还分别代表“整体”和“部分” . (4)泛化：泛化是指类间的结构关系、亲子关系子类继承父类所具有的属性、操作和关联。

分析类图实例：

4.面向对象的设计原则:

面向对象的设计原则是面向对象设计的基本指导思想.

是评价面向对象设计的价值观体系.

是设计模式的出发点和归宿.

是构造高质量软件的出发点.

4.1: 好的设计:

好的设计:

4.2: LSP-替换原则:

LSP(The Liskov Substitution Principle, Liskov替换原则).

“若对于类型S的任一对象o1，均有类型T的对象o2存在，使得在T定义的所有程序P中，用o1替换o2之 后，程序的行为不变，则S是T的子类型” .

如果在任何情况下，子类(或子类型)或实现类与超类对象都是可以互换的，那么继承的使用就是合适 的。为了达到这一目标，子类不能添加任何父类没有的附加约束.

“子类对象必须可以替换超类对象” .

当设计违背LSP原则时,可参考一下思路:

4.3: OCP-开闭原则:

开闭原则: ( OCP-The Open-Close Principle)

开闭原则说明软件实体应该对扩展开放，对修改关闭；即在不修改已经存在的源代码的情况下，修改其 行为.

这在软件生产环境中尤其有价值，因为在生产环境下可能需要更改源代码。然后，极有可能对源代码进 行代码评审；单元测试，集成测试等符合开闭原则的代码可以做到在不修改源代码的情况下扩展功能， 因此从经济方面非常节省。

实现开闭原则的两种策略:

4.3.1: 复用代码:

只有在更正代码错误的情况下才能修改一个类；新增或改变功能需要创建不同的类。

新类通过继承的方式复用原来的类的代码 子类可能与超类可能有不同的接口.

主要思想是：复用实现(代码)，而不复用接口现有实现代码不允许修改，新实现不需要实现现有接 口。

4.3.2: 复用接口:

重用抽象接口，而不是重用实现(代码) .

4.4: SRP-单一职责原则:

SRP(The Single Responsibility Principle).

就一个类而言，应该仅有一个引起它变化的原因.

有关类的职责分配问题，是面向对象设计中最重要的基本原则.

SRP体现了内聚性(Cohesion) .

内聚性：一个模块的组成元素之间的功能相关性类的职责定义为“变化的原因”，每个职责都是变化的一 个轴线；当需求变化时，该变化会反映为类的职责的变化如果一个类承担了多于一个的职责，那么引起 它变化的原因就会有多个.

4.5: ISP-接口隔离原则:

ISP(The Interface Segregation Principle).

将很大的接口拆分成较小的，更具体的接口；使得客户类只需要知道它所感兴趣的方法。 ISP原则的意图 是使得一个系统保持较低的耦合，以便于更容易重构，修改与部署。

使用多个专门的接口比使用单一的接口好一个类对另一个类的依赖性应当是建立在最小的接口上的避免 接口污染(Interface Pollution).

4.6: DIP-依赖倒转原则:

(DIP-The Dependency Inversion Principle).

高层模块不依赖于低层模块，二者都依赖于抽象.抽象不依赖于细节，细节依赖于抽象.

针对接口编程，不要针对实现编程.

又称控制反转(IoC ， Inversion of Control)、依赖注入.

结构化设计，上层调用下层，上层依赖于下层，当下层剧烈变动时上层也要跟着变动，这就会导致模块 的复用性降低而且大大提高了开发的成本。面向对象设计中的依赖倒转：一般情况下抽象的变化概率很 小，让客户类依赖于抽象，实现的细节也依赖于抽象。即使实现细节不断变动，只要抽象不变，客户程 序也不需要变化。这大大降低了客户程序与实现细节的耦合度。

ps: 这个带菱形的箭头表示为类之间的聚合关系.

5.设计模式:

设计模式是在构件设计阶段，通过定义类或特定对象之间的结构和行为，从而解决每类设计问题的通用 解决方案.

设计就是解决方案—对某个问题的解决.如果某个解决方案对某类问题都很有用.这时就把它总结出来.这就产生了设计模式.

设计模式是：优秀的设计范例,从优秀设计方案中发现和总结出来的经验,在实践中反复出现的设计问题的优秀解决方案,设计者相互交流的基本术语,设计语言培养优秀设计师的一条捷径.

5.1: 设计模式与设计原则:

设计原则是面向对象设计的指导思想,设计模式只是更好地遵循这一指导思想的手段之一. 设计模式是面向对象设计的具体技术,设计模式抽象出成功设计的共性，并进行分类与标识. 设计模式通过描述对象、协作和职责将设计中的意图抽取出来.

5.2: GRASP:

GRASP ( General Responsibility Assignment Software Pattern，通用职责分配软件模式) . GRASP模式描述了将职责分配给对象的基本原则，这些原则被表示成模式.

职责和职责分配是面向对象分析和设计的最核心工作，合理的职责分配直接决定了设计的质量.

GRASP就是用于指导职责分配的原则和模式.

5.3: 信息专家模式:

信息专家模式：将责任分配给信息专家类(拥有实现该责任的信息的类) .

将职责分配拥有履行一个职责所必需信息的类，即信息专家信息专家模式在职责分配中的应用比任何其 他模式都广泛，它是面向对象的设计中的一个基本指导.

原则信息专家不是一个模糊或者新奇的设计概念，它表述了最普遍的一种“直觉”，即对象所能完成的工 作要依赖于它所掌握的信息.

优点：

(1)封装能够得以维持，因为对象只使用他们自己包含的信息来完成任务(低耦合) .

(2)系统行为只分布在具有所需信息的类中(高内聚) .

5.4: 创建者模式:

使用创建者模式的好处支持低耦合，从而意味着低维护依赖，高复用机会.

5.5: 低耦合模式:

低耦合模式：通过分配责任使得得到低耦合的设计.

高耦合的设计:

低耦合的改进方法:

5.6: 高内聚模式:

5.7: 控制器模式:

控制器模式：将接受(处理)系统事件消息的责任分配给一个代表整体系统(子系统、设备)的类，叫 做门面控制器或者代表一个用例场景的类，称为用例控制器的类。

控制器是一个非用户图形界面对象。控制器负责接收或处理系统消息。控制器决定调用哪些系统操作。 优点：

Controller类对象代表了应用层的控制器，它提供了用户图形界面所需要的方法。这样， ChartDrawerGUI类就可以不和Chart层次类产生关联，而只要调用Controller类即可。

用户图形界面ChartDrawerGUI是可插拔的，可以轻松地替换的.

增加用户图形界面的复用，产生可插拔的用户图形界面可能性. 保证应用逻辑不包含在GUI层. 将系统操 作代理给一个Controller类的好处是支持应用逻辑在将来的应用程序中的复用.

5.8: 多态模式:

如果一个程序使用了条件语句，则当有新的条件被加入的话，则需要修改原来的条件语句组的逻辑缺 点：程序不容易扩展。原因是如果程序有了新变化的时候，则可能会涉及到多处的修改。

解决方案：使用多态模式。当相关的行为基于类型而变化，使用多态操作，将行为责任分配给相关的类 型

。

简单地说,就是把复杂的方法”退化”到类,避免了因为需求的变化大幅度的修改和重新编译原有类的操作.

5.9: 纯虚构模式:

将一组高内聚的责任分配给一个不代表领域类概念的虚构的类。该虚构的类的存在支持高内聚，低耦合 与复用.

这种设计不好：数据库操作方法与这3个类没有概念上的关系，如果数据库操作包含在3个类中，那么您 将得到一个低内聚的设计(导致低内聚的设计);这样做将生成一个与数据库接口(例如JDBC)紧密耦合的 类图.

一方面，按照信息专家模式，三个领域类类都应该拥有数据库访问的职责，而另一方面，如果这样做， 会导致低内聚，高耦合与可重用性差的设计。

使用纯虚构模式进行设计:

5.10: 间接模式:

将责任分配给中介对象，以便在其它组件之间进行协调，以使它们不直接耦合。

5.11: 受保护模式:

如何设计对象、子系统和系统，以使这些元素中的变化或不稳定对其他元素不会产生不良影响？ 确定能预测到的(类型)变化或不稳定点；分配责任以建立一个稳定的接口.

PV是大多数编程和设计的机制和模式的基本动机之一，它使得系统能适应和隔离变化.

改善之后的设计容易维护,容易扩展,而且符合开闭原则.

5.12: Demeter定律:

类的方法不应该依赖于其它的类的结构，而只能依赖于自己所在的类或者其最靠近的超类。 不符合此定律的设计:

符合此定律的设计:

应用Demeter定律的基本效果是可以创建松散耦合的类，其实现秘密被封装了；因此，为了理解一个类 的意图，不必理解许多其它类的细节。

6.分析与设计:

6.1: 设计策略:

D-设计(分解设计， Decomposition design)将系统映射为构件片(component pieces)，再对各个 构件片进行内部设计；是应用广泛的设计策略。

FP-设计(Family Patterndesign)是一种探求一定范围的通用性设计策略，不从需求入手，而去探求问 题的本质特征。主要用于通用产品设计，例如通用财务软件的设计。

I-设计(Invention design)基于概念化原型作系统分析，定义系统以满足所发现的需要和需求.

6.2: 从分析到设计：

面向对象分析是面向对象设计的输入，设计是分析的细化方法。

相同点：都产生类图，分析类图，设计类图)。。

分析：做什么(What)分析有效地确定了将要构建的内容分析重点关注业务(business)问题。

设计：怎么做(How)设计定义如何构建目标系统：采用何种技术、何种平台(如JavaEE，前后端分离开发) 来实现分析模型设计关注于系统的技术(technical)和实现(implementation)细节。

分析集中在系统需求，而设计集中在待生产的软件的结构.

OO设计是对OO分析的进一步细化，其根本思想是：对分析模型中的分析类进行进一步的设计，添加实 现细节，这些分析类最终转变成设计元素面向对象的方法中，设计是分析的自然延续，在分析模型中添 加特定的实现机制，得到可以实现的设计元素.

7.架构设计基础:

7.1: 架构与架构设计:

架构是一个系统的组织结构，包括系统分解成的各个部分、它们的连接性、交互机制和指导系统设计的 相关规则.

架构设计的活动在分析阶段就已经开始，分析阶段主要关注基础架构的选型和并确定核心的分析机制.

设计阶段，要针对分析阶段的备选架构的各个方面进行详细的定义，以设计出符合特定系统的架构.

7.2: 架构设计内容:

(1)确定核心元素：在架构的中高层，以“分析类”为出发点，确定相应的“核心设计元素” (设计类，接口， 子系统等)

(2)优化组织结构：按照高内聚、低耦合的基本原则，整理并逐渐充实架构的层次和内容(在架构的哪些 层，具体地包含哪些包，在哪些包中，包含哪些类) .

(3)定义设计后的组织结构：架构设计还应该考虑设计完成后系统实现、运行以及部署等阶段的组织结构 (JavaEE, 前后端分离开发，服务器，数据存储，软件部署) .

7.3: 包图:

包图是一种将模型元素分组的机制.

包主要用于组织模型元素配置管理单元.

分包的原则：职责相似，将一组职责相似、但以不同方式实现的类归为一组有意义的包；如java类库中 的javax.swing.border.

协作关系：包图包含了各种不同类型的类，它们之间通过相互协作实现一个意义重大的职责.

可以使用包记号表示大的系统架构与局部的结构表示架构，可以依据架构层依据用户功能.

7.3.1: 包的关系:

7.3.2: 包的设计原则:

7.4: 设计元素:

设计元素(Design Elements)是指能够直接用于实现(编码)的模型要素.

主要包括:

包(Package).

设计类(Design Classes).

子系统(Subsystem).

接口(Interface).

主动类(Active Class).

确定设计元素的目的是改进(调整)分析类，使之成为适当的设计模型元素.

7.4.1: 分析类到设计元素:

(1)简单的分析类被直接映射到设计类，如果：若一个分析类是一个简单类(表示一个简单逻辑抽象)则 将此分析类增加详细内容(属性，方法的参数，返回值)，从而成为设计类.

(2)更复杂的分析类可能被分成:

多个设计类.

设计为一个包.

设计为一个接口和子系统.

7.4.2: 接口:

接口(Interface)是类、子系统或构件提供的操作的集合接口允许用户以公开的方式定义多态，并且和实 现没有直接联系接口支持“即插即用”的结构.

7.4.3: 子系统与接口:

子系统(Subsystem)是一种介于包和类之间的一种设计机制，它实现一个或多个接口所定义的行为. 具有包的语义：能够包含其它模型元素.

具有类的语义：具有行为.

子系统可以将系统划分成独立的部分，将被实现为独立的构件，这些构件在保持结构不变的情况下，可 以独立地开发和部署，适应变更，而不影响到其它系统.

子系统也可用于将系统划分成若干单元表示设计中的既存产品或外部系统.

7.5: 永久数据存储:

8.类的设计理论:

类设计(Class Design)目标确保类可为用例实现提供必需的操作确保提供足够的信息可明确无误地实现处 理和类相关的非功能需求(例如，可扩展性).

输入:用例实现(设计).

输出:设计类.

8.1: 主要内容:

1. 创建初始设计类.

2. 定义操作.

3. 定义属性.

4. 定义关系.

8.2: 初始设计类:

8.2.1: 边界类:

8.2.2: 实体类:

8.2.3: 控制类:

8.4: 定义属性:

8.5: 定义关系: