>构造型1.泛化关系
泛化代表一般与特殊的关系。在用例之间的泛化关系中，子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或覆盖父用例中的行为和含义。父用例表示通用的行为序列，通过插入额外的步骤或定义步骤，子用例特化父用例
在UML规范中，泛化关系用空心三角形箭头的实线表示，箭头指向父用例
2.包含关系
包含关系指的是两个用例之间的关系，其中一个用例（称为基本用例）的行为包含了另一个用例（称为包含用例）的行为
包含关系是依赖关系的版型，也就是说包含关系是比较特殊的依赖关系，他们比一般的依赖关系多一些语义
在UML规范中，包含关系用带箭头的虚线表示，箭头指向包含用例。同时，必须用<>标记附加在虚线旁，作为特殊依赖关系的语义
3.扩展关系
扩展（extend）关系的基本含义与包含关系类似，即一个用例（称为基本用例）的行为包含了另一个用例（称为扩展用例）的行为。但在扩展关系中，对于扩展用例有更多的规则，即基本用例必须声明若干“扩展点”，而扩展用例只能在这些扩展点上增加新的行为和含义
在UML规范中，扩展关系用带箭头的虚线表示，箭头指向基本用例。同时，必须用<>标记附加在虚线旁，作为特殊依赖关系的语义。
4、五种视图概念，各自包括哪些图？
动态图/动态建模：
顺序图、协作图、状态图、活动图
静态图/静态建模：
包图、用例图、类/对象图、部署图、构建图
核心图：用例图/类图/顺序图/包图
1 *用例图(use case diagram)：表达功能点，表现是一种用户视角/功能视角的性质。
2 *类图(class diagram)：表示的是对象结构
3 *顺序图(sequence diagram)：表达的是 系统与外界交互 / 对象间交互 关系。
4 协作图(collaboration diagram)：可以由顺序图来自动生成。
5 状态图(state chart diagram)：复杂系统或系统中的某些复杂对象状态多变，才需要画。
例如：订单（订单生成 / 揽货 / 发出 / 中间投递 / 妥投待签收 / 签收）
注意：状态图是针对某些对象的状态图。
6活动图(activity diagram)：简单版本的就是针对某个方法的程序流程图；
复杂版本的可以使用泳道（swim lane）来加入参与者
ⅹ7 组件图（component diagram）:可以形象理解为编译后的功能模块的jar包组织
ⅹ8 部署图 (deployment view/ diagram)
9 包图（package overview / hierarchy）：层次组织用，子目录结构，对象间关系
UML的五种视图：5种视图分别描述系统的一个方面，5种视图组合成UML语言完整的模型。
▪用例视图(Use case View),也称为外部视图，功能视图、用户视图，包括用例图。
▪静态视图(Static View),也称为逻辑视图(Logic View)，也称为结构模型视图(Structural Model View)，包括类图、对象图和包图。
▪交互视图(Interactive View)，包括协作图和顺序图
▪动态视图(Dynamic View) ，也称为行为视图(Behavior View), 也称为并发视图(Concurrent View)，进程视图（Process View）包括状态图和活动图。
▪实现视图( Implementation View)，也称为组件视图或物理视图(Component View)，包括组件图和部署图。
系统
| 视图 | 使用图形 | 适用对象 |
| 用例视图 | 使用用例图 | 用户, 设计者, 实现者, 测试者 |
| 静态视图 | 类图，包图 | 设计者, 实现者 |
| 交互视图 | 协作图和顺序图 | 实现者, 组装者 |
| 动态视图 | 状态图和活动图 | 实现者 |
| 实现视图 | 组件图和部署图 | 实现者, 组装者, 测试者 |
5、耦合、继承被部分人称为“最强耦合”的理解耦合：对象间存在的一种“使用”关系，统称为耦合。
依赖、关联、聚合，都表达对象间存在一种“使用”关系，都属于耦合。
继承/泛化，基类对象和派生类对象间不存在“使用”关系，不属于耦合。
高内聚、低耦合：软件设计追求的目标之一
做加法容易，减法难。一旦一个类继承了另一个类，以后就没法卸掉这个类的属性。用聚合代替继承,使用动态数组进行属性的装载。
6、瀑布、原型法、螺旋模型、up过程、xp过程各自的特点
A 传统软件过程模型
瀑布过程：单周期、无迭代、一次交付
文档驱动、推迟实现、阶段性和依赖性、质量保证
⏹文档驱动的模型
⏹阶段间具有顺序性和依赖性
⏹推迟实现的观点
⏹质量保证的观点
瀑布模型的问题
⏹实际项目很少按照该模型给出的顺序进行
⏹用户常常一开始难以清楚地给出所有需求
⏹用户必须有耐心等待一个漫长无反馈的交付
⏹开发者常常被不必要地耽搁
B SME模型（迭代/增量模型）
融合了瀑布模型的基本成分和原型的迭代特征。采用随着
日程时间的进展而交错的线性序列。
⏹第一个增量往往是核心产品
⏹每一个增量均发布一个可操作产品
⏹早期的增量是最终产品的“可拆卸”版本
some... more... even more
1）快速原型法
界面驱动、多周期迭代
第一个原型就是最开始的静态原型，供用户评审需求达成一致。后面每个原型都是逐渐的界面菜单等的响应实现。
2）螺旋模型
风险驱动，在每周期四象限的第二象限负责评估当前的风险和困难，每周期都要评估随时调整其优先级。
I象限：需求分析
II象限：风险分析
III象限：开发实现
IV象限：评审
3）RUP过程
用例驱动、体系结构为中心、重型过程
行业标准，主流过程
4）XP过程（eXtreme Programming）
四个要素：沟通（communication）、简单化（simplicity）、反馈（feedback）、勇气（courage）。这形成了XP的核心价值观。
属于AP（敏捷方法（Agile Process）中的突出代表）,重视设计模式，基本无文档。
测试驱动、结对编程、集体拥有、高频迭代、自动化测试和集成
软件生命周期(SDLC，Systems Development Life Cycle,SDLC)是软件的产生直到报废或停止使用的生命周期.周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。
软件过程模型的共性：需求分析分量最重，风险最高，需要予以高度重视
7、类对象间的关联关系的成员可见，依赖关系的局部可见，关联与聚集的不同与相同
依赖(Dependency ) :含义:是类与类之间的连接,表示一个类依赖于另外一个类的定义;依赖关系仅仅描述了类与类之间的一种使用与被使用的关系;
关联(Association):含义:类与类之间的连结,关联关系使一个类知道另外一个类的属性和方法;通常含有“知道”,“了解”的含义。关联可以是双向的，也可以是单向的
聚合(aggregation):含义:是关联关系的一种,是一种强关联关系（has-a）;聚合关系是整体和个体/部分之间的关系;关联关系的两个类处于同一个层次上,而聚合关系的两个类处于不同的层次上,一个是整体,一个是个体/部分;在聚合关系中,代表个体/部分的对象有可能会被多个代表整体的对象所共享;
组合(Composition):含义:它也是关联关系的一种（is-a）,但它是比聚合关系更强的关系.组合关系要求聚合关系中代表整体的对象要负责代表个体/部分的对象的整个生命周期;组合关系不能共享;在组合关系中,如果代表整体的对象被销毁或破坏,那么代表个体/部分的对象也一定会被销毁或破坏,而聚在合关系中,代表个体/部分的对象则有可能被多个代表整体的对象所共享,而不一定会随着某个代表整体的对象被销毁或破坏而被销毁或破坏;
8、类对象的三种构造型<>，<>，<>与MVC层的对应关系Boundary、Control、Entity是三种特殊的生命线对象类型，通常一起使用（MVC模式、控制模式）：
Boundary：边界对象，初学者用得少，在MVC模式、控制模式、需求分析过渡到系统设计中用得多些，可用于表示交互界面、子系统。
Control：控制对象，用于表示业务逻辑、分工协调的职责对象，采用控制模式分析设计时用得多。
Entity：实体对象，用于表示需要永久保存或较长生命期的数据对象，例如票据、文件、数据库（通常不直接说数据库等技术实现方式，而说逻辑意义的名称）。
9、MVC模式三层分层
MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
10、GRASP信息专家模式、高内聚、低耦合
GoF等设计模式是针对特定问题而提出的解决方法，而GRASP则是站在面向对象设计的角度，告诉我们怎么样设计问题空间中的类与它们的行为责任，以及明确类之间的相互关系等等。GRASP可以说是GoF等设计模式的基础。
11、GoF观察者模式、单例模式
单例模式是设计模式中最简单的形式之一。这一模式的目的是使得类的一个对象成为系统中的唯一实例。要实现这一点，可以从客户端对其进行实例化开始。因此需要用一种只允许生成对象类的唯一实例的机制，“阻止”所有想要生成对象的访问。使用工厂方法来实例化过程。这个方法应该是静态方法（类方法），因为让类的实例去生成另一个唯一实例毫无意义。
观察者模式（Observer）完美的将观察者和被观察的对象分离开。举个例子，用户界面可以作为一个观察者，业务数据是被观察者，用户界面观察业务数据的变化，发现数据变化后，就显示在界面上。面向对象设计的一个原则是：系统中的每个类将重点放在某一个功能上，而不是其他方面。一个对象只做一件事情，并且将他做好。观察者模式在模块之间划定了清晰的界限，提高了应用程序的可维护性和重用性。
观察者设计模式定义了对象间的一种一对多的组合关系，以便一个对象的状态发生变化时，所有依赖于它的对象都得到通知并自动刷新。
12、聚合优先于继承
由此可见，组合比继承具有更大的灵活性和更稳定的结构，一般情况下应该优先考虑组合。只有当下列条件满足时才考虑使用继承：
子类是一种特殊的类型，而不只是父类的一个角色
子类的实例不需要变成另一个类的对象
子类扩展，而不是覆盖或者使父类的功能失效
13、针对抽象不针对具象
这是OO设计中的一个原则，比方说我们需要一个东西来盛水，这个东西只要有盛水的功能就行了，我们并不关心它是马克杯，乐扣杯，或者是牌大瓷缸，甚至是尿壶，这个能盛水的东西便是抽象(我们在脑海里只有一个概念，却没有实物)，而马克杯或者其他的具体实物便是抽象的实现，面向抽象编程会非常灵活，并且低耦合，易于扩展和维护，还是那个比方，人是一个类，人有一个喝水的方法，想喝水就要依赖一个能盛水的容器，如果我要是依赖于具体编程，比如我今天想用乐扣杯盛水喝，明天想换个口味用尿壶，那么我就得每天都换一种（换一种实现就得修改一会类），非常麻烦，如果我依赖抽象（接口），我只是想喝水，只要这东西能盛水就行，我需要什么具体容器，就由它人来提供（工厂类提供一个具体实现的向上转型也就是抽象以便喝水的人可以用），来实现解耦
14、粗、细粒度用例图与顺序图之间的关系
15、顺序图的两阶段绘制
16、建模题（超市买手，学生选课等，参见实验2-5）
重点复习上传的笔记，建模大题重点复习实验2、实验3、实验5。选择题注意可能是不定项选择，各题目注意题目加黑的导语
•对修改封闭
◦类应该是封闭的，不可再去修改代码的
•对扩展开放
◦类又应该是可以扩展的，可以不去修改源代码的前提下去扩展增加新的功能或覆盖改写原有的功能
⏹。两类多态
⏹静态多态
⏹模板（template）
/泛型（Generic Type）
⏹重载
⏹动态多态
⏹虚函数覆盖改写
/接口
◦接口全部只有方法的虚体(C++中称为纯虚函数)，抽象类还可以有属性和不虚的方法体定义。
◦类中只要有至少一个方法是虚函数，那么就是抽象类。抽象类中如果没有属性成员而且方法成员全是虚体，就是一个接口。
◦抽象类和接口都不能实例化。
◦接口只能被继承它的子类去实现(JAVA中接口也可以继承接口)；抽象类可以被子类继承来定义虚体方法，也可以被子类覆盖改写已有的非虚的方法。
•关联：对于两个相对的类，当一个类的实例与另一个类的一些特定实例存在固定的对应关系时，这两个系统之间为关联关系：
◦首先排除天然语义上是否是聚合
◦当不是聚合时，如果B对象出现在A对象的成员部分，那么A关联B。
•聚合：当系统A被加入到系统B中，成为系统B的组成部分时，系统B和系统A之间为聚集关系。
◦例如自行车和它的响铃、龙头、轮胎、钢圈以及刹车装置就是聚集关系，因为响铃是自行车的组成部分。
◦而人和自行车不是聚集关系，因为人不是由自行车组成的，如果一定要研究人的组成，那么他应该由头、躯干和四肢等组成。
由此可见，可以根据语义来区分关联关系和聚集关系。
如果再从程序设计语言构成来看，当为聚集时，B出现在A的成员体部分（B对A而言是成员可见）。也就是聚合和关联在程序特征上没有不同，都是成员可见性的类型。
按照B出现的形式不同分为弱聚集和强聚集，后者也称为组成/组合（composition）。
◦B出现为引用或指针：弱聚集，菱形为空心。
◦B作为A的对象成员：强聚集，菱形为黑色实心。
JAVA所有对象皆为引用，取消了指针，因此强弱聚集在语言层次上就没有区别了。因此一般统一用 来表达聚集。
•依赖：对两个相对的类实体，当一个类对象负责构造另一个类对象的实例，或者依赖另一个类对象的服务时，这两个类对象之间主要体现为依赖关系。表示较弱的临时使用关系，不需要记录保存。
例如生产零件的机器和零件，机器负责构造零件对象。再例如充电电池和充电器，充电电池通过充电器来充电。再例如自行车Bicycle和打气筒Pump，自行车通过打气筒来充气。
注意它们之间对象的生命并不是“同生同灭的”，而是偶尔需要时就为之，需之则用，用后即弃。这是一种非常弱的使用关系，不同于前面的关联是有固定的使用关系的。
从前面的例子中可以看到，依赖也是对象间关系的一种，它表达的语义比关联要弱。
对象B不出现在A的成员体中，而出现在A方法体中。
◦出现在A的方法的形参中：参数可见
◦出现在A的方法内部作为局部变量：局部可见
程序特征：
当不是聚集，也不是关联时，如果出现了参数可见或局部可见，就表达为依赖。使用 连接A和B类的对象，表示A类对象将在某个时刻会使用到B类对象
◦
