我们都知道，盖房子都会有一个挖地基，打地基的步骤，而且依据房子的类型及用途，地基的工程以及结构的材料也会有所不同，这些都是经过建筑师专业而仔细的设计及计算才得知的，为的是房子未来的安全及使用需求，甚至是施工过程的安全及顺畅度等等。软件建造的道理，其实是一样的，大家也都希望不仅开工顺利，最后也验收顺利，最好是在保固期内，什么事都不会发生。

建立软件架构的目的，就在于提供系统一个稳固而坚实的发展基础，而其具体的产出，就是一份软件架构书以及依照架构书这个最高设计原则所建构出来的原型（Prototype）。这样就可以让后续加入的工程团队遵循架构设计所表达的美感，并照着原型的建造工法，来继续大部份尚未完成的工程。

当你决定使用以架构为中心的开发方式时，这两个产出是连接架构设计阶段及实作阶段最重要的东西。当然，软件架构的设计不是一、两篇文章就可以解释清楚的，本文仅将一些比较重要的概念及经验提出来，希望能给初入门的读者有个概括的认识。

所有的故事，都是从需求开始
任何一个软件项目的开始，都是为了满足某些特定的需求，这是一句废话，但也是一句非常重要的话，因为当我们在塑造软件架构的时候，显性的需求或其所带来的隐性特质，都可能是影响日后系统成功的关键。显性的需求是客户最直接的期望，他可以明确的告诉你说，他需要在某个画面上加一个按钮，让使用者可以简单的按下按钮，就轻松地订到机票并且自动地完成付款，但是客户可能不会清楚使用者在按下这颗按钮时，不希望等待时间超过10秒钟，他更不会知道从按下按钮，到系统完成所有的工作，是经过几万行的程序并和几个外部系统联机后才会有的结果。而一百或者一千个使用者的规模，对于软件架构以及开发成本，又有着截然不同的设计，往往客户和开发人员的期待落差，就此产生。因此，影响软件项目成败的地方，大部份不是显性的需求，而是隐藏在那背后的邪恶灵魂。

透视需求，找到架构观点
不知道各位有没有做过健康检查？当你在健检中心做检查时，通常会有好多的关卡，而您会像过关斩将般地面对一站一站不同的仪器及医生，每一站所检查的内容都不一样，例如骨科医生看到的，是你的骨质状况；肠胃科看的是你的肠胃健康，他们唯一做的同一件事，就是在检查同一个你。

人类是一个完美而复杂的系统，人体的复杂当然不是只有我们看的到的外表，这是我们都能了解的事实，而软件系统也是一样。以UP（Unified Process）这个软件开发方法论为例，它有几种架构观点（views）；使用案例观点、逻辑观点、执行观点、部署观点、实作观点等等。这些软件的观点，就像是不同科的医生对人所看到的不同观点一样，都是在描述同一个软件系统。

设计架构的工作，其实就像医生角色伴演的游戏，你要伴演各科别的医生，透视软件系统，从外在功能面上的需求，找出隐含在各种观点背后的需求，然后再像建筑师，设计出满足这些需求的架构。
显性的需求通常所描述的是「使用案例」（Use-Case），这是以使用者的观点来看系统的外观长相，看的到的东西都是属于功能性的需求，例如，会员管理、票价查询、订票等等。

在这些显性需求背后所含的隐性特质，就是所谓的SLR（Service Level Requirement），其中包含了可靠性（availability）、可修改性（modifiability）、效能（performance）、安全（security）、可测试性（testability）、可使用性（usability）等等，而满足这些从使用案例观点所发觉出来的SLR，就是「逻辑观点」以及其它的架构观点的责任了。

满足需求再描述设计
在满足SLR及设计架构观点的过程中，我比较建议从「逻辑观点」开始，因为它是在描述软件实作时所需的设计概念。在这个观点里，会有较高层次的设计组件，包括Package、Subsystem、Interface等等，它会直接影响到执行观点以及实作观点的设计，当然，部署观点也是一样。只不过通常部署观点会有需多客户本身的限制，例如，客户需要用掉之前的机器库存或者预算限制等等，因此在项目开始前，这个部份有时是被限制住的。其实这些架构观点都会因为某些需求而互相影响，端看架构师的智慧及经验来取舍。

对于这些架构观点详细的说明或举例，因为篇幅的关系，建议各位去读读UP相关书籍及Craig Larman所著的《Applying UML and Patterns》一书，大家会有更清楚的了解。

「凡走过，必留下痕迹」，以上所说的种种观点，如果没有记录下来，架构的设计也就没有意义了，一般来说，我们会将这些设计内容一一地写到所谓的 SAD（Software Architecture Document）－软件架构书里，这是系统未来开发的最高指导原则。而为了系统后续的开发顺利，在SAD完成后，我们还必须分析并找出架构设计里面的指标因子，例如风险较高的技术、连接子系统的关键、影响程序撰写风格的部份等等，然后进行细部设计及实作这些指标因子，使成为所谓的Prototype。接下来，开发团队的大部份成员就可以遵循着SAD及Prototype的脚步，比较稳健而安全的开发下去。

用Pattern的美感来表达软件架构
Pattern是一个很重要的软件设计技术，从定义中我们可以知道它是在一个特定背景下，已被命名而且为了解决某个特定问题的解决方案，而 Architectural Pattern更是针对架构性的问题所发展出来的，例如在POSA1所提的，Layers、Broker、MVC等等。现在世面上所流行的技术或Open Source Framework，像是RMI、Struts等等，都是基于上述的Architectural Pattern所发展出来，当然，在做架构设计时，reuse这些技术框架也是省时方便的策略。

一般的软件技术，如OO的基本原则，或者系统分析设计方法并不一定能真正地解决特定的SLR，因此这些已验证过的Pattern可以做为设计软件架构时，满足特定隐性需求最佳的架构单位，除了利用Pattern来建构一个稳固的软件架构之外，其利于沟通的特性让你容易地将你的设计记录在SAD里并让后续的开发团队易于了解。让自己的「创意」经由「沟通」而能确实实现，我想是这是每个软件人的希望吧。

对于这些架构观点详细的说明或举例，建议各位去读读UP相关书籍及Craig Larman所著的《Applying UML and Patterns》一书，大家会有更清楚的了解。