在
软件开发的过程中，
设计的过程往往比写代码的过程要难得多。因此，通常除了软件测试之外，耗时最多的也就是系统建模了。一个好的软件系统应当具有较高的稳定性（可靠性）、易操作性以及可扩展性支持，尤其是可扩展性。我认为，良好的可扩展性支持是一个软件团队在开发中变被动为主动的必要条件。
对于一个应用，我们希望在用户增加需求时，我们能够用最少的时间、最少的人力来解决问题。当别人在用户快速增长的需求中忙得不可开交时（用户总是不能在第一次需求分析时将需求完完整整的告诉你），而你，你的团队只需要作一点工作就可以让“贪得无厌”的用户得到满足，从而提高了效率，让团队有更多的的时间来创造，而不是去做无谓的修改。
很遗憾的是，在《C#插件构架实战》一文中，我并未考虑到这一点。当然，对于一个十八岁的没有也不可能有团队工作经验的年轻人来说，这样的失误（失误就是失败——老师如是说）是可以原谅的（自我开脱之辞）。不过，我决定对这个插件系统进行重构。
考虑到系统的复杂性，这次我准备使用UML（大上个月才开始学的，画得不好，见笑了）。
1. 着手分析
对于网友 jan 的指教，我大概明了，但人的思维差别太大，我不敢保证我的理解是完全符合 jan 的意思的。但是，我仍然会根据自己对可扩展性的理解构建一个应用
程序框架
模型。
直入正题。我现在假设我属于一个软件团队（就暂且叫她 AbstractSoft 吧），并任系统分析师。任何事物都有它规范的一面，我们希望我们的团队出品的部署在同一平台的所有应用都有相同的框架，相同的部署形式。这样便可以形成独有的团队特色，并在竞争中以效率取胜。因为我们不需要为每一套应用设计不同的框架——这可以节约不少时间！
这样我需要把程序实现与用户界面分开到不同的框架中。我的意思是：
如此一来，在 Application Frame Level 的核心库中存在的是抽象接口以及一些泛化的细节。这些内容在第一次安装团队产品时就已经部署在用户的机器上了。它不会自动销毁，直到用户提交把它从本地移除的请求。GUI Level 提供了团队产品泛化后的统一的界面组件（比如：属性编辑器、数据库操作界面等可重用组件）。特化的产品（Speciallized Application）通过实现 Application Frame Level 中的某些接口实现可扩展性，通过使用 GUI Level 中的的类来实现用户界面。
以下是一个简单的静态图(接口和类的成员将在下面详细阐述)：
