| 整体技术方案的因素（考察的要点） | |
| 界面复杂度 | |
| 简单数据输入（Simple data input），例如登录界面。 | |
| 数据表静态视图（Static view），如商品报价列表。 | |
| 可定制视图（Customizable view），如查询的报表报告。 | |
| 数据的动态视图（Dynamic view），实时运行的监控视图。 | |
| 交互式的图形（如CAD，多交互的设计APP等）。 | |
| 页面部署约束 | |
| 经常要离线工作的移动计算机 | |
| 手持设备（PDA、手机等） | |
| 网络全浏览器支持，包括低速以及ADSL老版本浏览器 | |
| 网络较新浏览器支持 | |
| 内网较新浏览器支持 | |
| 内网特定浏览器支持 | |
| 内网专用工作站（C/S架构的Client） | |
| 用户数量级和用户类型 | |
| 少数的专业用户[关注：功能强大、扩展性强、DIY参与、学习性强] | |
| 数量固定的组织机构的日常使用者[稳定、便捷、易用、安全、切合业务需求] | |
| 大量爱好者[功能的执着追求、扩展升级] | |
| 数量巨大的消费型用户[速度，便利、服务态度] | |
| 系统接口类型 | |
| 通过协议提供服务：系统依照协议向外提供服务。如http协议，SOAP（simple object access protocol）协议等。 | |
| 直接访问系统服务：按照类似系统内部的调用方式直接使用系统的方法，例如RPC/RMI/Corba等。 | |
| 性能和可伸缩性 | |
| 数据传输：仅仅为了满足系统间交互数据的需要，如EDI（electronic data interchange）电子数据交换，数据库同步等（database synchronous）。 | |
| 只读：只能对数据进行浏览和查询操作。如股票行情分析系统。 | |
| 独立的数据更新：可以对数据进行更改，但各用户的操作相互隔离，互不影响，互不冲突，包含一些数据交互但不能影响基础数据。例如使用者的的个人数据管理。 | |
| 并发的数据更新：并发用户对数据的更改将相互影响，例如多个用户同时预定等功能。 |
（ERP）
| （考察的要点）ERP系统 | |
| 界面复杂度：数据静态显示/可定制的视图。 | |
| 页面部署约束：各系统平台或浏览器（PC端，移动端或其他电子设备）。 | |
| 用户数量级和用户类型：组织机构日常使用者，人数相对固定。 | |
| 系统接口类型：通过HTTP/TCP协议提供服务，附加SOAP协议。 | |
| 性能和可伸缩性：主要是独立的数据更新，少量的并发。 | |
| 选择软件的架构样式（风格） | |
| Dataflow system（数据流系统） 1) Batch sequential（批处理） 2) Pipes and filters（管道过滤器） Call and returan systems（调用与返回系统） 1)Main program and subroutine（主程序和子程序） 2)OO System（面向对象系统） 3)Hierarchical Layers（分层系统） |
|
| Independent components(独立的构件) 1) Communication process （通信交互的进程）2) Event systems （事件驱动系统） 3) Capsule-prot-protocol（实时系统） |
|
| 软件的架构样式（风格）：一组软件元素以及其关系的元模型（meta-model），这些元素和关系将基于不同的风格（由元模型索定义）来描述目标系统本身。 这些元素就叫做构件（Component）和连接器（Connection），而它们之间的关系则表示为如何组合构件、连接器的约束条件。 |
|
| ERP系统概要（架构）设计使用分层系统。 分层模式：一种将系统的行为或功能以层为首要的组织单位来进行分配（划分）的结构模式。一层内的元素只依赖当前层和依赖层的其他元素，并被下一层所依赖。 逻辑分层： 1) 通常在逻辑上进行垂直的层次划分。 2) 关注点是如何将软件构件组织成一种合理的结构，以减少依赖，从而便于管理（支持协同开发）。 3) 逻辑层次的划分基于包（命名空间）的设计原则。 物理分层： 1) 在物理上进行水平的层级划分。 2) 关注软件运行时刻的性能以及伸缩性，还有系统的操作需求（Operatrional requirement） 3) 管理、安全等。 4) 物理层划分的目标在于确定能够满足若干不同需求的软件运行时对系统资源要求的标准配置，各构件部署在这些配置下将获得最优的性能。 |
|
| ERP系统的分层模型： 在职能上可分为三层：presentation Layer 表示层、Persistence Layer持久层和Business Layer业务层。每层在功能上应十分明确，相互独立，通过接口相互联系。 |
|
| 利用可重用资产 资产类型：领域模型、需求规格、构件、模式、Web Services、框架、模版等。 首先必须考察这些资产使用的上下文，即项目需求、系统范围、普遍的功能和性能。 之后可以从组织级的资产哭或业界来搜寻相关的资产，甚至的相似的产品或项目。 |
|
| 设计模式（Design pattern）： 概念 ：一般是指一种从一个一再（重复）出现（相同或相似）问题的背景中抽象出来的解决问题的固定方案，即方法论。而这个问题背景不应该是绝对的，也不应该是固定的。一些不相关的问题可能会有同样的问题背景，从而需要应用相同的模式来解决问题（抽象到一致）。 软件的建模和设计过程中用到的模式。 每一种设计模式都进行了系统的命名，解释和评价了面向对象系统中一个重要和重复的设计。这些模式可用于指导面向对象系统中一些至关重要的对象建模问题。如果有相同的问题背景，那么可以直接套用模式去解决。 |
| 23种常用的设计模式： | |
| 1. Abstract Factory（抽象工厂模式） | 提供一系列相互依赖对象的接口，而无需指定它们具体的类。 |
| 2. Adapter（适配器模式）： | 将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本因为接口不兼容而不能一起使用的那些类可以一起使用。 |
| 3. Bridge（桥接模式）： | 将抽象部分和它们的实现部分分离，使它们都可以独立的变化。 |
| 4. Builder（构建模式） | 将一个复杂对象的构建与它的表示分离，使它们都可以独立的变化。 |
| 5.Chain Of Responsibility（请求链模式） | 解除请求的发送者和接收者之间的耦合，从而使多个对象都有机会处理这个请求。 将这些对象链接成一条链来传递该请求，直到有一个对象处理它。 |
| 6. Command（命令模式） | 将一个请求封装为一个对象，从而可以用不同的请求对客户进行参数化，将请求排队或记录请求日志，以及支持取消操作。 |
| 7. Composite（复合模式） | 将对象组合成树状结构以表示“部分-整体”的层次结构。Composite使得客户对单个对象和复合对象的使用具有一致性。 |
| 8. Decorator（装饰模式 | 给一个对象动态的添加一些额外的职责。 |
| 9. Facade（统一外观模式） | 为子系统中一组接口提供一个一致的界面。 |
| 10. Factory Method（工厂模式） | 定义一个用于创建对象的接口，由子类决定将哪个类实例化。 |
| 11.FlyWeight（轻量级模式） | 运用共享技术有效地支持大量细粒度的（fine grained）的对象。 |
| 12.Interpreter（翻译模式） | 给定一种语言，定义它的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。 |
| 13. Iterator（遍历模式）： | 提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。 |
| 14. Mediator（媒介模式） | 用一个中介对象来封装一系列的对象交互。 |
| 15. Memento（备忘录模式） | 在不破坏封装性的前提下，捕捉一个对象的内部状态，并在该对象之外保存这个状态。 |
| 16. Observe（观察者模式） | 定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖它的对象都得到通知并自动刷新。 |
| 17. Prototype（原型模式） | 用原型实例指定创建对象的种类，并通过复制原型来创建新的对象。 |
| 18. Proxy（代理模式） | 为其他对象提供一个代理以控制对这个对象的访问。 |
| 19. Sington（单一模式） | 保证一个类仅有一个实例，并提供一个访问它的全局访问点。 |
| 20. State（状态模式） | 允许一个对象在其内部状态改变时，改变它的行为。 |
| 21. Strategy（策略模式） | 定义一系列算法，将它们一个个封装起来，并且它们可以相互替换。 |
| 22. Template（模版模式） | 定义一个操作中的算法框架，而将一些步骤延迟到子类中。 |
| 23. Visitor（访问者模式） | 表示一个作用于某对象结构中的各元素的操作。 |
| 软件框架 | |
| 企业面临的挑战 | 根据优先级的排序，主要包括高可靠性（high availability）、低成本（cost effective）、可扩展性（scalability）、投放市场的快速性（time to market），安全性（secure）、良好的性能（good performance）、可集成性（ability to integrate），以及多平台支持（multi-channel）等。
要面对上述的要求和挑战，需要采用通用、灵活、开放的、可扩展的框架，之后再在框架基础之上开发具体的应用系统。 |
| 框架的定义： | 框架是应用系统的骨架，将软件开发中反复出现的任务标准化，以可重用的模式提供给用户使用 大多提供了可执行的具体程序代码，支持迅速的开发出可执行的应用，但也可以是抽象的设计框架，帮助用户开发出健壮的设计模型。 好的抽象、设计成功的框架，能够大大的缩短应用系统的开发周期。 分别用于垂直和水平应用。 |
| 框架的特点： | 框架具有很强的（大粒度）可重用性，远远超过了单个类，它是一个功能连贯的类集合，通过相互协作为应用系统提供服务和预制行为。 框架中的不变部分提供了接口，对象的交互和其他不变量。 框架中的变化部分（应用中的个性）。 一个好的框架定义了开发和集成组件的标准。为了利用、定制或扩展框架服务，通常需要框架的使用者从已有框架类集成相应的子类；以及通过执行子类的重载方法，使用用户定义的类能从预定义的框架类获取需要的消息，这会带来很多好处，包括代码的一致性和重用性，对变化的适应性，特别是它能够让开发人员专注于业务逻辑，从而大大减少了开发时间。 |
| 子系统的划分和接口定义 | |
| 划分子系统和设计模型组织结构 | 1. 设计模型的组织结构的最终目标是支持个人或团队进行独立的开发。 2. 层次、包的划分，为团队的分工协作提供最直接的依据。 3. 子系统的划分，是团队成员之间的依赖关系最小化，从而支持并行开发（方便构建）。 4. 为方便测试而进行划分，包、子系统及其接口的定义应当支持被独立的加以测试。 |
| 使用子系统的好处 | 子系统可以用来将系统划分成相互独立的部件，它们可以 1. 被独立的定制（Ordered）、配置（Configured）或交付（delivered）。 2. 在接口保持不变的情况下被独立开发。 3. 跨越一些分布式计算节点被独立部署。 4. 被独立的变更而不打破系统的其他部分。 也可以用来： 1. 将系统中访问关键资源而需要有安全限制的部分分割出来成为独立的控制单元。 （如果将管理功能、约束条件、流程检查抽取出来为单一的子系统，并对全局进行控制，将运行状态、错误检查、错误处理，异常控制和系统功能并行使用）。 2. 在设计中代表已有的产品或外部系统。（每个子系统代表某个单例的产品，具有突出性和代表性，如将基础数据和业务报表功能分离，代表基础数据维护和报表系统，最大的限度降低耦合性，使得每个功能子系统都能独立的突出其核心功能和服务，子系统的划分粒度应适宜于当前的使用者）。 |
| 识别系统的接口 | 目标：基于职责来识别系统的接口。 步骤： 为所有子系统识别一组候选的接口。 考察接口间的相似性。 定义接口间的依赖关系。 将接口对应到子系统。 接口定义规定的行为。 将接口打包。 |
| 设计接口 | 命名接口：接口名称要反映到系统的角色中。 描述接口：接口描述要传达的职责信息。 定义操作：名称应当反映操作的结果，描述经行操作的目的。 文档化接口：打包支持信息，包括序列图、状态图、测试计划等。 |
| 优势： | 优化设计，包括去冗余和提高重用 最小冗余设计及其优势 系统设计的优劣可以通过最终编码的冗余程度来衡量。 减少系统的物理尺寸，降低实施的成本。 缩小应变更引起的更改范围，降低维护成本。 简化系统的复杂度，便于理解和扩展。 |
| 去冗余途径： | 通过抽取共性元素，从而在结构上保持组成元素（形式）的单一存在。去冗余的途径包括一下几种：划分、泛化、模板化、元层次化和面向方面编程。 |
| 划分 | 将系统划分为职责更加几种和明确的模块（例如，对象、子系统、子程序等），相同的行为将通过调用同一模块来实现，从而避免重复的组成元素分散于系统各处（绝大部分系统的问题，重复的模块、代码太多，最常见的冗余情况）。 结构化的泛型下，将重复的代码抽取出来重构为子函数、子程序。 面向对象泛型：识别对象，并将职责分配给合适的对象，其他对象将委托它来完成相应的行为。为对象定义通用的原语方法，而在更高级别调用它们以实现粒度更大的职责。让对象通过组合来复用已有对象的服务。 |
| 泛化 | 将共性的行为抽取出来，专门在一处单独定义，所有类似行为的实现将关注于那些个性方面，共性方面直接从既有方面继承，而不再重复的实现。 在结构化泛型下，可以在主函数中执行一个统一的执行过程，然后使用钩子函数等途径来回调用个性化的扩展函数。 在面向对象泛型下，父类实现共性的行为，并定义一些可重载的方法，在父方法中调用，然后让子类重载它们以便扩展个性行为。（利用多态机制）。 泛化的去冗余：主要是避免重复实现一些较大粒度的框架性行为，对于小粒度的行为复用应当使用既有的划分途径。 |
| 通过模板化（泛型化）去冗余： | 使用模版来定义共性的结构和行为，并开放出某些变量，这些变量对模版而言是行为敏感的，在具体的应用场景，通过引用不同的参数变量，从而导出众多个性化的行为组合。 在结构化泛型下，将一组类似的行为并入一个函数，而通过传入参数来控制不同的组合。（一个方法内包含多个处理分支）。 在面向对象泛型下，主要有模版类、模版函数等。 模板化去冗余组合，形式是一种结构（变量）与行为（模版）的二元组合，一个模版可以使用不同的变量来表现不同的个性，同时避免了重复的定义。 |
| 通过元层次化去冗余 | 利用元数据来表达某种领域行为，然后使用相关的机制来实例化。从而实现元数据定义的行为内容。 元数据驱动（meta-data driven）的方式有：声明规格（declarative specification），通过代码生成器转换为最终的代码实现，需要使用编译器进行事前转换。指令规格（imperative specification），元数据定义行为，运行时由特别机制解释执行，不需要进行事前的转换。 |
| 通过面向方面编程（AOP）来去冗余。 | 将分散在系统代码之间的行，将类似职能的代码抽取出来，作为一个方面（aspect），集中到一块来出来（这些职能包括日志记录、权限验证、资源的释放、异常处理等），避免类似代码的重复。 面向方面编程AOP技术的提出，就是为了解决所有途径都难以解决的、类似职能代码横向交错（cross-cut）冗余的问题。 AOP技术将系统中随处可见的行为抽象成若干个行为方面，然后将它们和主体对象的固有行为结合在一起，实现了纷繁复杂的多样系统行为。 |
| 通用问题往往可以抽象为方面 | 其中，架构分析设计所面对的： 选择候选层级 保持会话状态 确定共通的用户界面交互机制 确定共通的数据存储机制 解决并发和同步冲突 支持事务处理 接口的定位和实例化机制（常用途径：命名服务） 设计统一的异常机制 安全机制的实 |