目录
Part One：概述
1、系统（system）：系统是一组互相依赖和互相交互的一组组件组成的整体，一个系统可以用静态的结构和动态的行为两方面来描述
2、分析（analysis）：分析是一个将复杂事物分解成小的组成部分的过程
分析是将复杂系统分解成小的、可以理解和可以管理的组成部分的过程
3、设计（design）：设计是使用建模元素描述一个事物规格的过程，该规格满足一定的需求，并符合一定的限制条件。
4、用计算机系统解决其他行业问题的过程
|
描述问题和方案 |
|
转换为计算机系统需求 |
|
需求分析与设计 |
|
分析问题 |
|
提出方案 |
图2-1 计算机系统解决其他行业问题的过程
Part Two：UML 和 RUP
1、如何描述一个系统？ 使用建模工具
软件建模工具通常包括结构化建模工具和面向对象建模工具；
结构化建模工具包括数据流图DFD、软件结构图 SSD和程序流程图 PFD
面向对象的建模工具主要是UML
常用的UML建模工具包括：rational rose 和 staruml
2、模型（Model）原模型（metamodel）、建模（Modeling）、建模工具（Tools）
建模：用建模工具构建模型的过程
系统模型：包括结构模型（静态模型）和行为模型（动态模型）
2、UML（Unified Modeling Language）
1、UML的组成结构：
图2-2 UML的组成结构
2.UML上层结构
3、 “4+1”架构：（用例视图、逻辑视图、实现视图、进程视图、部署视图）
1、“4+1”架构中“1”是用例视图。
3、软件过程
软件过程分为组织过程、管理过程、技术过程
图2-4 软件过程
4、RUP（Rational Unified Process）迭代 增量
1、RUP的四个阶段(Phases)：先启(初始)阶段、精化阶段、构建阶段和移交（产品化）阶段
2、阶段结束标志着重要的里程碑（Milestone）:
|
|
图2-5 RUP四个阶段及里程碑
3、RUP的每个阶段包含一到多次迭代，每次迭代包括业务建模、需求、分析设计、实现、测试和部署这6个工作流。（环境、项目配置、配置与变更管理）
4、RUP的核心工作流由角色、角色所参与的活动和活动所输出的工件组成，工件包括文档、模型元素和软件模型。
5、RUP迭代和增量开发方法：
5、UML之关系(考察根据关系写出java代码)
1）依赖关系
理解：一个类A使用到了另一个类B，B类的变化会影响到A。这种使用关系是单向的、临时的、非结构化的，并且是最弱的一种关系。
|
B |
|
A |
描述方式：
依赖关系的四种表现：
A）ClassA中某个方法的参数类型是ClassB；
B）ClassA中某个方法的实现实例化ClassB；
C）ClassA中某个方法的返回值的类型是ClassB；
D）ClassA中的某个方法中调用了ClassB的方法；
例如：
依赖关系的实现
2）泛化关系 
子类指向父类
理解：类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能。箭头指向父类 （xx is-a xx，通常是泛化关系） 
派生类指向基类
例如：CPet类泛化出CPetDog类、
CPetCat类、CPetBird类
图2-8 泛化关系示例
图2-9 泛化关系的实现
3）关联关系 
理解：两个类、或者类与接口之间语义级别的一种强依赖关系. 一种拥有的关系，它使一个类知道另一个类的属性和方法。带普通箭头的实心线，指向被拥有者。是一种结构关系
关联关系的角色和重复度：
图2-11 关联关系的实现
关联之聚合关系 （has-a） 
表示整体与部分之间的关系，不同的生命周期，
图2-15 实现关系的实现
关系的一些理解：
1、抽像出A类和B类共有特征，形成C类，则B和C类之间是泛化关系
2、依赖、关联、泛化和实现关系中，耦合最强的关系是泛化，最弱的是依赖关系
四种关系的java实现
关联和依赖的区别：（做题易错）
1、 从类的属性是否增加的角度看：
发生依赖关系的两个类都不会增加属性。其中的一个类作为另一个类的方法的参数或者返回值，或者是某个方法的变量而已。
发生关联关系的两个类，其中的一个类成为另一个类的属性，而属性是一种更为紧密的耦合，更为长久的持有关系。
2、 从关系的生命周期来看：
依赖关系是仅当类的方法被调用时而产生，伴随着方法的结束而结束了。
关联关系是当类实例化的时候即产生，当类销毁的时候，关系结束。相比依赖讲，关联关系的生存期更长。
6、UML建模元素-结构型元素
结构型元素主要包括：类、对象、接口、参与者、用例、协作，组件，节点，成组元素
1、类的模型元素
图2-16 类的模型元素
注：1、类名不要简写，不能省略。
2、属性可见性有公共+、私有-、保护#、缺省~四种符号表达；属性可多重，有初值，可以使类层次的，也可以是对象层次的。
3、有三种类：实体类、边界类、控制类
4、主动类：主动发起动作的类（线程类、进程类、任务类）；参数类
2、对象的模型元素
图2-17 对象模型元素
注：1、对象的特性：封装；通过消息互相操作。
2、对象通常由对象名，对象所属的类和属性值构成，而且对象名要加下划线
3、接口的模型元素
两种表示方法：一个圆、类的<<interface>>版型
接口和抽象类：1、都不能实例化；2、抽象类可包含部分实现但是不能多重继承；接口只能包含常量，可多重继承和实现。
4、参与者和用例
参与者是一个与组织（或系统）外部的，与组织（或系统）交互的角色。
用例描述了一系列活动，通过该系列活动，用例为参与者提供可见的价值。
参与者和用例是关联关系
5、协作
协作是两个或多个类或对象一起工作以实现用例的过程。分为静态部分和行为部分。静态部分定义了参与该协作的类、接口和其他元素。行为部分定义了这些元素如何交互作用从而达到目的
6、组件
组件是系统中物理的，可替代的部件，是一个描述了一些逻辑元素（如类、接口）的物理包。组件是逻辑元素的容器。
组件分为 部署组件、工作组件和执行组件三种。
组件和接口之间可以是实现和依赖两种关系
部署图中的连接指的是两个物理设备之间的耦合，包括物理介质和软硬件传输协议。
图2-19 组件
7、节点
节点是系统运行时存在的物理元素，包括存储和处理能力，节点是组件的容器，节点可以是处理器也可以是设备。节点能够有效地对部署的结构进行建模。
图2-20 节点
8、成组元素
把建模元素，关系，图进行分组的元素，包（package）是把元素组织成组的机制。
包界定了一个命名空间，同一个包中的元素不可以有相同的名字。
包是可嵌套的，包内元素的可见性，包之间可以有多种关系，主要考察包间各个元素之间的关系
7、UML建模元素-行为型模型
1、活动图：
活动图是由泳道、活动、活动流、对象流、分支和分叉组成。
活动分为动作状态(不能再分解的活动,不可中断),活动状态(可以在分解的复杂活动,可中断)
活动流：反映一个活动向另外一个活动之间的转移以及活动之间的顺序。用带箭头的实线表示。
分支合并 
分叉汇合 
泳道用于表达责任区域；一个泳道通常用来代表一个角色。(一个泳道可以表示：用例，类，组件，组织单元、角色)
*对象流：反映活动与对象之间的依赖关系，表示对象对活动的作用或对对象的影响。用箭头虚线表示。
活动图应用：描述工作流，描述工程组织过程，描述算法流程，
2、状态图：
状态图用来表示一个系统或一个对象整个生命周期所经历的状态和状态迁移
一个状态通常包括状态名、进入(entry)/退出(exit)动作和内部迁移(do)组成
状态迁移包括引起状态迁移的事件、监护条件和动作组成。
8、交互和交互图（顺序图、协作图(通信图)）
1、顺序图：
顺序图包括对象、生命线、控制焦点、消息四种元素。
对象的命名方式：三种（对象名和类名、类名、对象名）（uml:Course、:Course、uml）
消息：对象A向对象B发送消息，即为对象A调用对象B的一个操作。
消息类型：调用消息(CALL) 、异步消息(SEND) 、返回消息(RETURN) 、自调用(Self Call)、创建(Create)、销毁(Destroy)
Part Three：业务建模
1、业务：一个组织通过组织内部为实现其价值通过资源的协作而完成的事务。
2、业务建模：以组织之外的视角来观察组织内部要素和过程的模型
3、业务建模内容：业务组织建模、业务流程建模、改进业务流程、领域建模
4、业务建模通常包含那些模型？使用那些图？
业务用例模型——业务用例图（业务参与者，业务用例）
业务对象模型——活动图、顺序图、状态图等（业务工作者，业务实体，业务用例实现（顺序图）
领域模型——类图
Part Four：需求建模
1、从业务到系统的两个转换：1）从组织视角向系统视角的转换2）从组织提供价值到计算机系统提供价值的转换
2、需求是系统必须满足的条件或具备的能力
3、系统需求包含功能需求、非功能需求（性能需求）和约束条件（环境），功能需求用用例模型来建模，非功能需求在需求的补充规约里载明
3、需求建模的方法：1、从业务模型导出需求，并形成系统用例模型
2、根据需求获取记录，从中提取出需求，最后形成系统用例模型
对于1、有三推导：业务边界——>系统边界（从组织向系统转换）；业务工作者——>系统主角（与组织交互向与系统交互转换）；业务用例——>系统用例（组织职能向系统职能转换）（可重点看一下PPT11，从业务模型到需求模型的映射方式）
对于2、使用需求获取技术获取系统需求（包括功能需求、非功能需求、约束条件），之后识别actor（参与者的泛化）和usecase（重在描述交互和系统功能）
4、用例模型精化（解决用例键的冲突与重复问题）
1）用例的扩展关系(extend)：基本用例路径本身是完整的
将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。
2）用例的包含关系（inclusion）：基本用例路径本身是不完整的
使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。
用例的扩展关系与包含关系的本质区别是扩展用例可不被基用例执行，而包含关系中，基用例必须执行包含用例才是完整的
用例的泛化关系（Generalization）：同一系统目的不同技术实现
用例的泛化关系，子用例与父用例的行为相似，子用例继承父用例的所有行为、结构和关系且子用例可以重载父用例的部分行为
用例分包的四种方式：
按参与者分包、按主题分包、按开发团队分包、按发布情况分包
Part Five：分析与设计
1、分析模型
主要包括：架构分析（静态模型，结构模型，采用宝图，类图，对象图来描述）和用例分析（动态模型，交互模型，采用顺序图，通信图来描述）（逻辑视图）
1）架构分析——架构综合
1、架构综合的目的是构造和评估一个满足架构敏感需求的概念性架构，通过构造该架构，表明系统是可行的
架构敏感需求：指在决定系统架构时扮演重要角色的那些需求（非功能需求）
概念性架构：是对某些想法的一个较短而不完整的实现，以证明其可行性，示范其原理，其目的是为了验证一些概念或理论。
2、定义备选架构（架构模式见课本P135）
3、架构分析——分析机制（一种模式，包含了解决通用问题的通用解决方案）
（持久化、进程间通信、安全性、冗余）
4、架构设计过程：在系统的全局范围内，以分析活动的结果为出发点，将现有的“分析类”映射成设计模型中的“设计元素”；明确适用于系统的“涉及机制”；调整内容逐渐充实为系统“架构”
2）用例分析——用例驱动的迭代开发
选择迭代用例的依据是用例的优先级，优先级高的用例在精化阶段的早期进行分析和设计，优先级低的用例在精化阶段的后期迭代中进行分析和设计
用例分析基本过程：寻找候选对象、描述对象间的交互和描述类。候选对象可以用对象清单描述，对象间交互用交互图描述，分析类用类图描述
寻找对象的步骤：找实体对象、边界对象、控制对象和生命周期对象
候选对象可能来自于业务对象模型、原始需求的描述和系统用例描述
2、设计原则
LSP：Liskov替换原则
派生类的对象可以替换基类的对象（子类替换父类）
OCP：开放-封闭原则
开放封闭原则的核心思想就是抽象编程。将经常发生变化的状态和行为封装成一个抽象类（或接口），外部模块将依赖于这个相对固定的抽象体，从而实现对修改的封闭。
由上图左边可见，Client类和Server类都是具体类，Client使用Server类中提供的服务。在该设计方案中（左图），如果Client需要使用另外一个服务器对象，就必须把Client类中使用Server的地方全部修改为新的服务器类。显然，这违背了OCP，需要修改Client来应对Server的变更。考虑此设计方案违背OCP原则的原因是Client可能面对不同的服务器，为此，可以把Client可能面对的不同服务器进行抽象，该抽象定义了Client需要服务器所提供的行为，但这些行为没有实现（需要具体的服务器来实现）。方案如右图。
在图右边所示的方案中，Client并不直接依赖于任何一个具体的服务器，而是将其所需要的行为定义为抽象接口Client Interface。任何能够提供这些服务的服务器将实现该接口。按照该设计方案，Server和Client之间是相互独立的，如果需要使用新的服务器只需要从Client Interface接口下再实现一个新的类即可，原有的结构不需要改变。
SRP：单一职责原则
SRP体现了内聚性，，对于每一个类只有一类功能相关的职责。就一个类而言，应该仅有一个引起它变化的原因
如上图所示，Rectangle类可能会因为两方面的原因而变化。
3、设计模式
GoF设计模式：（给你一个设计模式，你要知道他是哪一类的，并大致了解这个模式是什么意思）
创建型模式：单件，工厂方法
结构性模式：适配器（类、对象）、代理模式
行为性模式：职责链、命令、访问者
对于每个模式什么意思，详见
类模式处理类和子类之间的关系；对象模式处理对象间的关系
4、架构设计和子系统设计(PPT19)
这一讲从分析到设计了，设计比分析更加精确
包：是一种将模型元素分组的机制；主要用于组织模型元素，配置管理单元；
包之间有依赖关系，但要避免循环依赖
子系统：
子系统是一种对外只提供接口的包，提供行为，完全封装了实现细节
子系统设计包括：子系统接口设计；分配职责到子系统元素；详细设计子系统元素；描述子系统间依赖关系
5、RUP类设计和用例实现设计
设计类：精化类的操作，精化类的属性；添加实现设计目标的支持类；精化类的方法和状态；精化类之间的关系（重点，掌握）
下面分别对各个关系的精化给出描述
图2-35 泛 化关系的精化
图2-36 依赖关系的精化
图2-37 关联关系的精化
图2-38 一对多关系的精化之聚合
图2-39 一对多关系的精化之组合
图2-40 一对一关系的精化
图 2-41 多对一关系的精化
多对多关系的精化
图2-43 关联类的精化
用例设计：画好顺序图
6、数据库设计
ODB对象数据库
1）建模原语
原子类型：只包含简单属性
集类型：对象集合List<> Set<>
结构化类型：内含对象引用
2）持久设计类和关系到ODB的映射
映射实体类；映射关联；映射聚合；映射类属；
图2-44 映射实体类
图2-45 实现和泛化关系映射
图2-46 关联关系
图2-47 映射关系
图2-48 ODB数据库映射举例
RDB关系数据库
1）RDB建模原语
表、字段、主键、外键、参照完整性
2）持久设计类到RDB映射方法
映射实体类、映射关联、映射类属
图2-49 映射实体类
图2-50 映射1：N关联
图2-51 映射1：1关联
图2-52 映射N:N关联
自关联
图2-54 类属映射—将类层次中的每个类映射成一个表
图2-55 类属映射—将整个类层次映射到一个表
图2-56 类属映射—将每个不想交的具体类映射到一个表
Part Six：实现与部署
组件图
组件图建立了逻辑元素到物理元素的映射，组件往往对应物理实体
组件和接口的关系：实现和依赖
组件和逻辑元素的关系：包含关系（组件是逻辑元素的容器）
部署图
部署图用来描述系统硬件节点构成，以及在这些节点上运行软件组件的分布
部署图基本概念：节点（处理器，设备）、连接
节点是组件的容器，一个节点是一个物理处理机、
总体知识框架图
4685
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
