期末复习必备：体系结构-考点_倩倩的临时版.docVIP

名词解释 10-20 设计五准则，4+1，OO协作与写作设计，OO职责和职责分配，GRASP模式或其中之一 软件设计的审美标准，列举已知设计方法与技术并说明他们促进了哪些审美标准 设计层次性 高层、中层、底层，各层出发点和关注因素（审美ESPECIALLY），主要方法、技术和最终产品 以上两个至少考一个 结构风格 描述比较相关风格 对给定场景判断使用风格 职责分配和协作设计 三个小点必定考一个 协作设计比较和场景判定 对给定场景和要求的控制风格， 设计模式！！！！！ ！！！设计模式所有的思考题，可能有20分 普通/集合类型programming to interfaces 区别 OCP手段（不仅是继承-最基本 信息隐藏类型，手段 实现共性可变性的手段，一般给定场景做好聚合和集成即可 解决DE-COUPLING时INDIRECTION的手段 MVC和分层的区别（具体到实现 名词解释 1.1 设计五准则： 用“美”的方式实现功能，是设计的价值 在设计方法和技术中，做到简洁性，一致性，坚固性 设计复杂度=事物复杂度+载体与事物的适配复杂度 设计重在内部结构，不是外在表现 只有高层设计良好，底层设计才可能良好（层次之间是迭代关系而非线性关系、不要再全部完成高层设计之后再进行底层设计、要尽早有一个可验证原型） 只有写完并测试代码之后，才能算是完成了设计。（敏捷视点 1.2 4+1视图： 4+1视图模型是实践中应用较广的用来描述体系结构设计的多视点方法，它定义了5个视图： 逻辑视图：关注系统的逻辑结构和重要设计机制，描述系统提供的功能和服务（面向对象分解）。使用者是终端用户，考虑因素包括功能性需求 进程视图：关注系统的运行时表现，描述系统的并发进程组织（进程分解）。使用者是集成人员，考虑因素包括非功能性需求，如并发性、性能、规模等。 开发视图：关注系统的实现结构，描述系统开发的组织（子系统分解）。使用者是编码人员和软件经理。考虑因素包括软件的模块组织，如层级结构、软件管理、复用、约束等。风格通常是分层风格。 物理视图：关注系统最为重要的需求，描述系统应该实现的场景与用例（映射软硬件）。使用者是系统工程师。根据潜在的硬件条件考虑系统的非功能需求，如可维护性，可靠性，吞吐量和规模等。 场景视图：关注系统最为重要的需求，描述系统应该实现的场景与用例（结合上述四者）。使用者：所有视图的使用者和评估者。考虑系统的一致性和有效性 1.3 OO协作和协作设计（need complementary） 应用可以分解为许多不同行为的集合 每一个OO之间的协作，将完成一个相应的行为 协作可以看成是一个对象网络中，传递在对象之间以完成一个特定行为的信息的模式。因此对象间的协作是分散在整个网络中的，而非一处单一的地方。 协作设计：对系统对象间的协作进行辨认和设计以使对象间协作能够正确完成所期待的行为。 分两步： 辨认协作：来自用例或是初步设计，如模块接口、进程通信等。 设计协作：系统行为协作分两种，分散式和集中式。分散式中逻辑行为分布在整个系统当中，而集中式则有一个额外的控制器来控制应用的逻辑行为。系统控制协作（风格）分为三种：分散式，集中式和委托式（系统决策行为分布在整个网络，但由中央控制器做最主要的决策） 1.4 OO职责和职责分配(可以包含下面的GRASP模式) 在多种职责分配方式中，选择耦合更低、聚合更高的分配方式。 1.5 GRASP： General Responsibility Assignment Software Pattern，包括九种设计对象的模式来构建良好的高内聚、低耦合、可复用的面向对象软件。 包括creator, controller, pure fabrication, information expert, high cohesion, indirection, low coupling, polymorphism, protected variations. 分配模式（GRASP模式）： 信息专家模式：对象设计最基本的原则之一，将职责分配给拥有足够信息完成该项职责的对象。维护了信息隐藏原则，提高了内聚度，降低了耦合，但使得对象更为复杂。 创建者模式：决定哪个类负责创建另一个类。以下情况B应当创建A，如果B包含或聚合了A；B密切使用了A；B记录了A的实例；B拥有初始化A的数据。降低了耦合度。 控制者模式（也是协作设计）：可由以下类来处理系统事件：代表整个业务或组织的类；代表整个系统的类；实际完成该项工作的对象；一个人造的类，纯粹用来代表这个用例，处理事件。具体如何分配需要实际考察内聚耦合度。在设计中，应当使用controller将外部事件源和内部事件处理对象分开（如UI和后台处理） 多态：当需要根据对象类型来决定不同的行为时，