内容发布更新时间 : 2024/11/15 0:04:37星期一 下面是文章的全部内容请认真阅读。
1. 简述 UP 的 4 个阶段和几个主要科目，列出各科目主要制品，各 制品的时限（开始时间及精化时间）。
P25（主要阶段）以及P28（各科目的制品以及制品的时限） 2. 简述需求制品 USGVR 和需求模型 FURPS+; 简述分层架构中的 常见分层：UADBTF。
需求制品：USGVR @P43 Supplementary specification FURPS+需求模型 @P42
分层架构中的常见分层：UADBTF @P150
3. 简述顺序图和通信图的区别，熟练掌握其相互间转换。 @P162 其转换比较简单。
4. 列出 GRASP 的 9 种设计原则，各解决了什么问题？列出 《Headfirst 设计模式》中介绍的 9 种设计原则。 @P210 (General Responsibility Assignment Software Patterns) 前5个原则解决了什么问题。后4个原则解决了什么问题@P300 《Headfirst设计模式》介绍的9种设计原则：
See at: http://blog.csdn.net/nuoboxgx/article/details/1833899 1,[封装变化]:找出应用中可能变化需要变化之处,把他们独立出来,不要和那些不需要变化之处的代码混在一起.(Identify the aspects of your application that vary separate them from what the same.) 2,针对接口编程(Program to an interface, not an implementation.) 3,多用组合少用继承(Favor composition over inheritance.)
4,为了交互对象之间的松耦合设计而努力!(Strive for loosely
coupled designs between objects that interact.)
5,类应该扩展开放,对修改关闭(Classes should be open for extension but closed for modification.)
6,要依赖抽象,不要依赖具体类(Depend on abstractions, Do not depend on concrete classes.)
7,最少知识原则:只和你的密友谈话(Only talk to your friends.) 8,别打电话给(调用)我,我会打电话给(调用)你(Don't call us, we’ll call you.)
9,一个类应该只有一个引起变化的原因(A class should have only one reason to change.)
Add 10, God Bless you and me! Thanks~~
5. 列出 GoF 的 23 种设计模式名称，解释其中 2 种你熟悉的设计模式(singleton 除外)，画出其 UML 类图，并说明其中各角色的作 用及其间的关系。
See at: http://www.docin.com/p-381437375.html#documentinfo GoF设计模式
接口型:Adapter（适配器模式）、Fa?ade（门面模式）、Composite（合成模式）、Bridge（桥接模式）。
责任型：Singleton（单例模式）、Observer（观察者模式）、Mediator（调停者模式）、Proxy（代理模式）、Chain of Responsibility（责任链模式）、Flyweight（享元模式）
构造型：Builder（建造模式）、Factory Method（工厂方法模式）、Abstract
Factory（抽象工厂模式）、Prototype（原型模式）、Memento（备忘录模式）
操作型：Template（模板方法模式）、State（状态模式）、Strategy（策略模式）、Command（命令模式）、Interpreter（解释器模式）。 扩展型：Decorator（装饰模式）、Iterator（迭代器模式）、Visitor（访问者模式）。 举例：。。。。。。
6. 熟悉何时不了解迭代开发 p29，初始阶段 p39，细化阶段 p96, 迭 代计划 p489
7. 简述 TDD、重构及其关系。 See at:
http://wenku.http://www.35331.cn//link?url=CJPkrsSg1mHfakjgLjauzz9IVZ3UMHIymhVBsRBZtDXnJcgXVaFpRzekQQW0AChvNxddUD8yqU0kTH3XyQGPfIhQ6WquNlGXY7tRtTMnw2a TDD(Test Drive Development)要在测试类之前编写测试代码，并且开发者要为几乎所有的产品代码编写单元测试。
TDD的基本规律是编写一小段测试代码，然后再编写一小段产品代码，保证其通过测试，然后再编写更多的测试代码，依此类推。 重构：是重写或重新构建已有代码的结构化和规律性方法，但不会改变已有代码的外在行为，而是采用一系列少量转换的步骤，并且每一步都结合了重新执行的测试。
重构和TDD具有关系－－所有的单元测试要支持重构过程。