Conceptual Architecture,直接翻译为【概念架构】,这是本书的第三个部分,上个阶段按为pre-Architecture阶段【前架构】,我自己对这阶段的理解就是,一栋建筑物的形成过程,在正式架构之前,要了解这栋建筑的用途,居民楼?学生公寓?购物广场?政府大楼……,将情况了解清楚之后,进行概念架构,也就是要求不是特别多的一种大体概括,画出建筑物的草图。将建筑替换成我们的软件,就是首先了解这个软件,这个系统各方各面的需求,然后进行系统的概念设计,具有哪些功能等等,对软件整体有一个理解。
首先本部分开头的两句名言,就引发了我很深的思考,“胜兵先胜而后求战,败兵先战而后求胜。”和“人们常常使用战术,而忽略了战略,战略要求从大局上把握整个架构与设计……架构错误的代价非常高。”。这两句话其实都之处了制定战略,大局看事情的重要性,也就是本阶段【概念架构】中指出的十分重要的一点,在稍稍后面一点,第一个关于小张的故事中,这一点大局观念就体现的十分明显,起初,小张将架构简单理解为一个公式“架构=模块+接口”,显然,这个片面的观点让他吃了大亏,在他后续的搜索过程中,一篇博客上写的“概念性架构就是对系统设计的最初构想,就是把最关键的设计要素和交互的机制确定下来,然后考虑具体技术的运用,设计出实际架构。概念性架构应该抓大局、不拘小节。虽然概念性架构都跳不出“架构=组件+交互”的基本定义,但它们描述架构的具体方式还是有比较大的差异:有的重视逻辑层,有的重视物理层,有的通过隐喻表明机制,有的看上去似乎就是一些设计元素的组合。不同的概念性架构图中,“连接”代表的含义千差万别:有的是依赖方向,有的是控制方向,有的是数据流向,因此,必须根据具体情况而定。”给了他大局观的意识,之后他站在一个比较高的层次看待整个系统,很好的解决了困扰他的问题。
概念架构是大型系统架构设计成败的关键,概念性架构界定系统的高层组件,以及它们之间的关系。概念性架构意在对系统进行适当分解,而不陷入细节。借此,可以与管理人员、市场人员、用户等非技术人员交流架构。概念性架构规定了每个组件的非正式规约及架构图,但不涉及接口细节。根据定义,我们注意到如下几点:
■概念架构满足“架构=组件+. 交互"的基本定义,只不过概念架构仅关注高层组件(high-level components) .
■概念架构对高层组件的“职责”进行了笼统的界定(informal specification) ,并给出了高层组件之间的相互关系(Architecture Diagram)。
■概念架构不应涉 及接口细节( without interface detail)。
概念架构分为以下三个阶段:1.初步设计。基于关键功能,借助鲁棒图进行以发现职责为目的的初步设计。这一步并不;总是需要,但对于架构师而言,是“新系统”就必须重视这-一步。2.高层分割。 对系统这个黑盒子进行高层切分,例如切分复杂系统为多个二级系统,或者直接切分系统为具体子系统。3.考虑非功能需求。概念架构≠理想化架构,所以不仅要考虑功能,也必须考虑非功能。具体方法是采用ADMEMS推荐目标-场最-决策表。
在这个阶段,还要注意的是对系统进行分割,将系统切分为若干子系统,如下图所示: