1. 面向对象系统建模
[toc]
1.1. 面向对象的分析模型[16]
面向对象设计的基本任务，把面向对象分析模型转换为面向对象设计模型。
面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成；设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和描述流程化处理过程的活动tu等。
用例之间的关系：
用例之间的关系主要有包含、扩展和泛化，利用这些关系，把一些公共的信息抽取出来，以便于复用，使得用例模型更易于维护。
- 包含关系。当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例。
- 扩展关系。如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。
- 泛化关系。当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。
用例“会员注册”和“电话注册”、“邮件注册”之间是泛化关系。
类之间的关系[16]
类之间的关系：关联(Association)、聚集(Aggregation)、组合(Composition)、泛化(Generalization)、依赖(Dependence)。
类University与类Student之间的关系是聚集(Aggregation)关系；类University和类Department之间的关系是组合(Composition)关系；类Student和类Course之间的关系是关联(Association)关系。
(1)关联提供了类之间的结构关系，将多个类的实例连接在一起。
(2)依赖关系表示一个类的变化可能会影响另一个类。
(3)泛化关系描述了一般事物与该事物中的特殊种类之间的关系。
(4)聚集关系表示类之间整体与部分的关系，其含义是部分可能同时属于多个整体，两者生命周期可以不相同。
(5)组合关系表示类之间的整体与部分关系，部分只能属于一个整体，两者具有相同的生存周期。
简要说明状态图和活动图的含义及其区别[15]
状态图：用来描述一个特定对象的所有可能状态以及其引起状态转移的事件。
活动图：用来描述操作的行为，也用于描述用例和对象内部的工作过程。
两者有本质区别：
状态图和活动图用于不同的目的。
状态图着重描述一系列的状态及状态间的转移，状态间的变迁需要外部事件的触发。
活动图用于捕获动作及动作的结果，活动图中一个活动结束将立即进入下一个活动，是内部处理驱动的流程。
依赖倒置原则
依赖倒置原则是指抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。在程序代码中传递参数时或在组合(或聚合)关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明和方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口和抽象类中声明过的方法，而不要给出多余的方法，否则，将无法调用到在子类中增加的新方法。
面向对象设计中的类[13]
在面向对象设计中，类可以分为三种类型：实体类、边界类和控制类。
①实体类映射需求中的每个实体，实体类保存需要存储在永久存储体中的信息。实体类是对用户来说最有意义的类，通常采用业务领域术语命名，一般来说是一个名词，在用例模型向领域模型转化中，一个参与者一般对应于实体类。
②控制类是用于控制用例工作的类，一般是由动宾结构的短语(“动词+名词”或“名词+动词”)转化来的名词。控制类用于对一个或几个用例所特有的控制行为进行建模，控制对象通常控制其他对象，因此它们的行为具有协调性。作为完成用例业务的责任承担者，协调、控制其他类共同完成用例规定的功能或行为。
③边界类用于封装在用例内、外流动的信息或数据流。边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。边界对象将系统与其外部环境的变更隔离开，使这些变更不会对系统其他部分造成影响。它可以实现界面控制、外部接口和环境隔离。
架构文档化[13]
软件架构文档应该从使用者的角度进行书写，针对不同背景的人员采用不同的书写方式，并将文档分发给相关人员。
架构文档要保持较新，但不要随时保证文档最新，要保持文档的稳定性。
架构文档化的主要输出结果是架构规格说明书和架构质量说明书。
里氏替换原则:
里氏替换原则是面向对象设计原则之一，由Barbara liskov提出，其基本思想是，一个软件实体如果使用的是一个基类对象，那么一定适用于其子类对象，而且觉察不出基类对象和子类对象的区别，即把基类都替换成它的子类，程序的行为没有变化。反过来则不一定成立，如果一个软件实体使用的是一个子类对象，那么它不一定适用于基类对象。
在运用里氏替换原则时，尽量将一些需要扩展的类或者存在变化的类设计为抽象类或者接口，并将其作为基类，在程序中尽量使用基类对象进行编程。由于子类继承基类并实现其中的方法
最少知识原则[11]
最少知识原则(也称为迪米特法则)是面向对象设计原则之一，指一个软件实体应当尽可能少地与其他实体发生相互作用。这样，当一个实体被修改时，就会尽可能少地影响其他的实体。
①在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用。一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波动。
②在类的结构设计上，每个类都应当尽量降低其属性和方法的访问权限。
③在类的设计上，只要有可能，一个类型应当设计成不变类。
④在对其他类的引用上，一个对象对其他对象的引用应当降到最低。
1.2. 基于MVC的J2EE架构[09]
JSP构件：系统界面
Servlet：分发客户请求、有效组织其他构件为客户端提供服务的控制器
Entity Bean：数据库相关操作
Session Bean：系统核心业务逻辑