1．面向对象建模
建模把复杂得问题分解为易于理解的小元素，以达到问题的求解模型帮助你具体化和指出系统的不同方面，模型也显示不同的部分如何彼此相关并有助于它们的工作形象化。
UML 定义了软件工程领域中的不同模型。下面给出模型和它们的描述：.
类模型描述其静态结构，状态模型表示对象的动态行为，用例模型解释用户的要求，交互模型描述消息流，实现模型包含工作单元，部署模型包含属于进程分配的细节。
提供一种简单的、准备使用的、表现为可视的建模语言，是独立于过程的，是独立于语言的
2．五大视图：
UML 定义了软件工程领域中的不同模型。下面给出模型和它们的描述：.
类模型描述其静态结构，状态模型表示对象的动态行为
，用例模型描述用户的要求，交互模型描述消息流，实现模型描述工作单元，部署模型属于进程分配的细节。
* 用户视图–表示系统的目的和目标
* 结构视图–表示系统的静态或空闲的状态
* 行为视图–表示系统的动态状态或状态的变动
* 实现视图–表示系统的逻辑元素的分布
* 环境视图–表示系统物理元素的分布
3．用户视图
系统的用户视图由用例图组成，用例图包含执行者、用例、及它们的关系，用例图表示了系统对外部实体提供的功能，用例图由执行者和用例组成（执行者对系统做什么的）
执行者主要可分为四类： 主要执行者–直接与系统交互的人，次要执行者– 涉及到系统维护的人，外部硬件–运行应用的非计算机的系统部分，其他系统–为其工作需要与你系统交互的外部系统
4．结构视图
代表系统的静态方面，包含类图（描述不同的类和它们的关联，描述系统中声明的类）和对象图（描述不同的对象和它们彼此间的链接）。
类：用来描述具有特征的现实世界的实体。
它们具有不同的类型：
实体类 -用例考察的与系统交互的实体的一种类
控制类 -控制用例工作的一种类
边界类 –信息在用例内、外流动时映射为相关的类
对象图：描述一段时间里特定实例的静态结构，描述了类图的实例，包含对象和链接，包含类图中发现的类的实例。
5．行为视图
当把现实场景应用于实现特定任务时，方法构成了系统的动态方面
行为视图描述了软件系统模型的动态方面
协作图- 表示类与它们关联之间的交互
时序图-描述了类与它们关联之间的交互（以时间序列）
状态图－当外部进程或实体访问时描述了类的行为，在执行动作时它类的状态和响应，表示为不同的实体的状态和转换
活动图－描述了类的活动，被内部进程或实体访问时描述了类的行为
协作图用来表示类之间交换的消息 和描述了类和它们关联之间的关系 ；关联角色指出了 类协作中类所扮演的角色 ；时序图给出 以时间序列安排的类之间的交互 ；
状态图中的转换用来描述描述系统中不同对象状态之间的关系 和用来建模不同对象状态之间的关系 ；活动图中动作流用来表示对象不同状态之间的关联 ，对象流述 动作状态和对象之间的关联 ；
状态图描述对象生命周期中的三种情形之一，分别是 满足某些条件 、 执行某一活动
和 等待某一事件的出现 ；
6．实现视图
描述软件系统实现的不同方面
例如：源代码结构，运行时的实现结构，软件发行的配置管理
构件是对执行良定义的、独立于它环境的现实任务有帮助的类或类组
用构件图 来表示系统的实现视图
7．环境视图
描述系统中使用的不同构件的物理分发，也称为部署图，描述的节点构成了系统部署的物理硬件需求的一部分，包括表示系统的硬件需求的节点或系统将部署的网络的设计。
8．状态图
属性建模：
属性拥有很少的值，属性在这些值之间的转换上有一定的限制。实例属性具有上面列出的两个特性，并且它的值反映了他的本身对象的自然状态，则称这个属性为状态属性（state attribute）。状态属性时表示对象状态的机制。
画的仅仅是那种类，它在系统的上下文内具有很强的动态行为
先找出这种类，然后列出它的状态，再画。
基本状态图，嵌套状态，并发状态和同步，消息结果参数的瞬时状态，连续的、可变的属性
Mealy约定：所描述的UML状态图是与转换相关的。
Moore约定：所描述的UML状态图是与状态相关的。
9．体系结构和接口
体系结构：软件体系结构，硬件体系结构，软件体系结构与硬件体系结构的相互影响
窗口布局图，描述每个窗口的特性。窗口导航图，描述窗口间的转换，这将构成特定应用的导航路径。
窗口导航图的目的是表示用户如何按照主流的应用导航路径从一个窗口切换到另一个窗口。通常，一张窗口图显示的是一个使用案例的人机交互路径。
导航图是一个简单易懂的屏幕转换图，它自身就是状态图结构的变体。
UML为描述系统体系结构的软件和硬件构成，提供了两种附加图：
包图(package diagram)：它描述的是纯软件元素的分组。包图对于实现软件的高层结构建模是很有价值的。
配置图：描述的是系统实现的技术单元。配置图也可以描述软件怎样被分布在选定的技术单元上，利用表示纯物理技术（处理器）的配置图，添加软件组件和它们间的互连关系。
10．用UML对结构建模
图：类图，对象图
内容：类（接口、协作），对象
关系：依赖、泛化、关联（以名称、角色、多重性、聚合修饰）
以注解修饰，以构造型、标记值、约束修饰扩展
公共机制：
详述（规格说明）specifications
修饰adornments：注解note分，隔栏等compartment
公共划分common divisions
扩展机制extensibility mechanisms.
l 构造型stereotype（表示新的建模元素）
l 标记值tagged value （表示新的建模属性）
l 约束constraint （表示新的建模语义）
对象：某一时间点上一组对象及其之间的关系，对系统的静态设计师图和静态进程视图建模——某一时刻系统的快照，对象集、对象状态以及对象之间的关系
内容：对象，链，和其他所有的图一样可以有注解和约束
11．用例和用例图的区别
用例描述需求，系统功能型需求，用例模型在需求工作流中定义。它是指示系统将要做什么的功能需求。 用例主要工作是写文本文档，图是次要的
黑箱用例：用例类型：成功场景，其它场景，细化，包括步骤和变化。
用例驱动开发：需求主要记录在用例中。多次迭代，导出用例。
识别其它需求：补充规则，词汇表，前景（构想）。
12．领域，依附集和内聚
对象类的领域主要包括 基础领域、结构领域、商业领域和应用领域；
和分别属于哪些领域。基础：Integer、Stack、Set、Date、BinaryTree、Mass
结构：Transaction、Backup、Port、RemoteMachine、Window和CommandButton
一个类的直接依附集是指这个类的直接类引用集的大小。一个类的间接依附集是指这个类的间接引用集的大小。直接类引用和间接类引用。
它提供了衡量类复杂程度的方法。
内聚可衡量这个类的特征属于一个单一类整体的完善程度。包括：事物型内聚，混合领域型内聚及混合角色型内聚。
13．状态空间和行为
类的状态空间和行为，子类的状态空间和行为，类的不变式和类的前置条件和后置条件。
类状态空间维数：属性的个数。子类的状态空间受限于父类的状态空间。但是可以扩展。
类的行为：子类行为的拓展。
一个类的不变式是指一种状态，即在任何时候该类的每一个对象都满足条件（当这个对象处于平衡状态时）。（如三角形）类的不变式的继承性。
每一个行为都有：前置条件和后置条件。（前置条件：栈非空，后置条件：取出内容。）
类的不变式和操作运算的前置条件和后置条件一起，共同形成了一种称为“契约设计”的设计方法的框架结构，这种设计方法能够确保一个目标对象的操作对其客户对象提供的一条消息产生正确的反应，而客户对象提供的消息是符合该操作运算的前置条件的。
14．类型一致性和闭合行为
类与类型：类是类型的内部设计，类型代表着类的外部特征。类型 含有物理意义。
类型一致性原则：如果s为t的真子类型，则s必须与t一致。即类型s的对象可以出现在型t的对象所需要的任何环境中，并且当该对象的任何获取操作执行时，仍能保持其正确性。
不变性：子类的不变式至少和超类的不变式一样强。（长方形和正方形）。
（难道是宽进严出）：
抗变性：每个子类操作的前置条件不应强于其超类操作的前置条件。（取值范围大）
协变性：每个子类操作的后置条件至少要和其超类操作的后置条件一样强。（取值范围小）
闭合行为原则：在基于类型/子类型层次结构的继承层次结构中，类C的任何对象操作的执行－包括从C的超类继承的所有操作－ 应满足C的类不变式。
15．继承与多态性的危险性
继承的滥用：
错误的聚集：用聚合而不是用继承（如飞机的部件）。
倒置的层次结构：雇员，经理，董事会等。
混淆类及其实例：熊，熊猫，物种等。
误用：房间是长方体又是圆柱体。
多态性的危险性：操作的多态性，变量的多态性，消息中的多态性，多态性与一般性。
16．嵌入式系统
概念：
时间：软，硬系统
线程：是一个简单的程序，获得CPU的使用权，多任务处理。6中状态：（休眠，就绪，延迟，等待，运行，中断）。
中断：ISR，中断延迟时间，中断等待时间，中断恢复时间。时钟周期中断。
操作系统：内核，协调两个线程之间，及一个线程和一个中断之间的通信。
分为非抢占式的内核和抢占式内核。
17．系统分析员职责
提出问题的解决方案，需要沟通技巧，在用户和客户建立关系。
软件开发生命周期：
u Identifying problems, opportunities, and objectives
u Determining system requirements
u Analyzing system needs
u Designing the recommended systems
u Developing and documenting software
u Testing and maintaining the system
u Implementing and evaluating the systems
再工程：重新设计，在产品和过程上。
逆向工程：从代码逆向到模型。就是代码和模型之间的切换。
18．学习案例
从业务入手，用GRAPPLE开发过程解决问题，发现业务过程，吸取经验教训。
GRAPPLE（Guidelines for Rapid APPLication Engineering）快速应用工程指导原则。
GRAPPLE中有下列段：需求收集（requirements gathering），分析（analysis），设计（design），开发（development），部署（deployment）。
需求收集：发现领域过程，领域分析，识别协作系统，发现系统需求，将结果提交给客户
分析：理解系统的用法，充实用例，细化类图，分析对象状态变化，定义对象之间的交互，分析与协作系统的集成
联合应用开发会议：(Joint Application Development session, JAD session)
发现业务过程：用活动图来表达（泳道）。明确定义，业务逻辑，停下来总结。
19．领域分析
分析会谈，开发初步类图，建立和标记类的关联，找出关联的多重性，得到聚合，填充类的信息。使用抽象类对类分组，按照聚集或者组成对类分组，重新调整类的名称。某些关联是三元的，使用常识对关联进行命名。（步骤）
查找记录中名词，动词及动词短语。
搜集à筛选&进一步会谈à选择，删除一些相同的名词。
名词：类或者属性，增加一些类。
动词及动词短语：关联或者操作。
20．收集系统需求
信息流，加快信息的流动。识别各业务过程模型中的信息流动。
修改类图；建立环境视图；识别系统各个功能模块，组成包结构；提取系统的各用例。
利用包图和用例图来表达系统需求。
联合应用开发会议（ Joint Appkication Development Session, JAD Session）
1．开发组通过该会议收集用户的需求，将需求编制成文档
2．参加会议的人员不仅包括开发组成员，还要包括系统可能的最终用户和领域专家。
3．会议的目标：产生能反映系统功能的包图，每个包代表系统的一个功能模块，其中包含了详细说明该功能模块的若干个用例
21．用例开发
开发组必须分析和理解每个用例，以从领域跨越到实际系统。
用例的一个重要方面就是能够提出组成系统的构件。
导入用例，再开一次联合应用开发会议，一组用户，整体领域专家的餐馆老板
• 用例——一组场景的集合，每个场景又由一系列步骤组成：
– 场景的简单陈述
– 关于场景的假设条件
– 用例的发起参与者
– 场景的前置条件
– 场景中与系统相关的步骤序列
– 场景完成后的后置条件
– 用例的收益参与者
– 设计文档中，每个用例的描述应该单独一页，内容包括文字叙述和用例图，图中画出该用例和用例参与者。
用例“Take an order”
• 发起参与者：Server
• 收益参与者：Customer
• 简单陈述：服务员将顾客的定单信息输入到他的手提电脑并将定单信息传递到厨房。
• 假设条件：顾客想就餐，顾客已经阅读了菜单并做出了选择
电脑已经出现了“输入定单”用户界面。
• 前置条件：顾客已经就坐并阅读了菜单。
• 后置条件：定单被输入进WIN系统中。
• 步骤序列：
1.服务员激活电脑中“输入定单”用户界面。
2.“输入定单”界面显示在电脑屏幕上。
3.服务员将顾客的菜单选项输入到WIN系统。
4.系统将定单发送到厨房的桌面电脑。
• 当阐述出系统的设计假设后，就开始：
– 考虑系统应当能够做什么
– 思考怎样让系统完成应该做的事
– 思考组成系统的构件有哪些
• 用例分析的目标就是描述出用户所看到的系统。
22．交互
分析用例有助于澄清系统中的工作部件。尽管我们现在已经对用例了解了很多，但是仍然要进一步建立系统中的工作部件之间的交互和工作部件状态变化（如何变化和何时变化）的模型。有了这些信息以后，程序员就知道如何对类编码以及如何使类相互协作
列出系统中的工作部件，分析工作部件之间的交互，修改案例。
用例“Take an order”（用顺序图来表达）
– 1.服务员激活他的手提式个人计算机的“输入定单”用户界面
– 2.“输入定单”用户界面出现在显示器屏幕上。
– 3.服务员将顾客的菜单选项录入到定单输入界面。
– 4.定单处理程序创建一个定单对象。
– 5.定单处理程序传送到厨师的界面。
– 6.定单处理程序将定单输入到定单数据库中。
– 7.定单处理程序告知服务员，定单已经被传送到厨房并且已经在定单数据库中登记过了。
– 之后是构件交互，构件交互的目标是为程序员提供信息——他们编码所需要的一些信息。构件交互分析的结果应该能使程序员更容易地编制实现构件和构件之间通信的代码。
23．设计外观、感觉和部署
GUI设计的一般原则；GUI JAD session；从用例到用户界面；用于GUI设计的UML图，描绘出系统的部署。用例驱动了用户界面的设计
24．设计模式
设计模式是被证明了的设计问题的解决方案。它在多种情况下使用，在UML中可以用参数化的协作表示设计模式。
使用设计模式可以让设计者容易复用已经被证明过的问题解决方案，在设计中引入好的设计思想，并可以使文档的编制更加简化和清晰。
职责链模式（Chain of Responsibility）
职责链是一种可应用于许多具体领域的行为模式。这个模式处理一组对象和一个请求之间的关系。链中的第一个对象获得请求，解决它或者把请求传到链中的下一个对象，直到有一个对象可以解决请求，这个传递才会停止。
好的面向对象的软件是 一个好的封装和共生性的组合
为了提高系统的可维护性，共生性提供了三个指导原则,分别是 通过将系统拆分为封装的元素使得整个共生性（包括差异共生性）达到最小化、将任何超过封装边界的共生性最小化和在封装边界范围内将共生性最大化；
一个类状态空间的维数概略地等于 等于这个类中定义的属性数目 。
类的不变式 和操作运算的 前置条件 和 后置条件 一起，共同形成了一种称为“契约设计”的设计方法的框架结构，
下列哪些程序单元分别属于0、1、2、3级封装结构。
A. 原始代码( 1 )、B. 包( 3 )、C.子程序( 1 ) D. 类( 2 )
| 控制类 |
实体类 |
边界类 |
| Application Manager
|
Regional HR Head (V)
|
Application
|
|
|
Employee |
|