跨过了概念架构的阶段, 下面进入概念架构的阶段. 一般有经验的架构师不会在这个阶段过早进入将系统划分为”模块+接口”的过程, 而是会根据前架构阶段的结果,识别重大需求, 核心需求, 高风险需求, 来设计概念架构. 概念架构应该能用简练的语言清晰阐述, 并能给客户说明如何实现客户价值, 担心的问题如何解决.个人认为概念架构刚好契合了> 一书中一再强调的架构的概念完整性. 其定义:
概念架构满足 “架构=组件+交互” 的基本定义, 仅关注高层设计.
概念架构对高层的职责进行了笼统的界定, 给出了高级组件的交互关系.
概念架构不涉及接口的细节. 举个例子: 比如下面这座斜拉大桥, 分为 索塔, 刚性梁, 斜拉索三个组件, 交互是索塔承重, 斜拉索吊起刚性梁, 这就是桥的概念架构.
图6 鲁棒图的要素
鲁棒图的一些规则: 1)
Boundary->Control->Entity->Control->Boundary->Actor 一次交互过程为一个完整用例, 也就是一个职责链,一般来说概念架构各拥有2-5个Entity, Control, Actor比较合适. 在概念架构只对关键用例画鲁棒图.注意Entity不代表持久化对象.
实践，例子也说明不了这些问题，略去不讲。在这个阶段，我们得到了概念架构的输出：简洁的系统概念归纳和表达。主要模块的交互鲁棒图，分层，分区图等。细化架构的一些东西将在下一篇再聊。
来源：Yu_Zhang
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！