什么是概念架构
概念性架构界定系统的高层组件,以及它们之间的关系。概念性架构意在对系统进行适当分解,而不陷入细节。借此,可以与管理人员、市场人员、用户等非技术人员交流架构。概念性架构规定了每个组件的非正式规约及架构图,但不涉及接口细节。
实际意义
1.不同系统的架构,为什么不同?
需求不同,所以架构不同。这里需求包括了功能、质量、约束等方面。
2.架构设计中,应何时确立架构大方向的不同?
进行概念架构设计时应确立架构大方向。架构设计贵在有针对性,概念架构针对重大需求、特色需求、高风险需求的要求,给出高层次的解决方案——这就是概念架构的最重要意义。
实践要领
重大需求塑造概念架构
ADMEMS方法Conceptual Arch阶段核心理念:重大需求塑造概念架构,这里重大需求应涵盖功能需求、质量及约束3类需求的关键部分。
概念架构阶段的3个步骤
1.初步设计。基于关键功能,借助鲁棒图进行以发现职责为目的的初步设计。
2.高层分割。对系统这个黑盒子进行高层切分,例如切分复杂系统为多个二级系统,或者直接切分系统为具体子系统。
3.考虑非功能需求
初步设计
初步设计对复杂系统的意义
1.架构师只有在设计复杂系统(或涉及不熟悉的领域,感受“挺复杂”)时才需要初步设计。
2.初步设计的目标:发现职责。无须展开架构设计细节。
后续的架构实际工作必然以初步设计为基础。
鲁棒图简介
鲁棒图包括3种元素,分别是边界对象、控制对象、实体对象:
边界对象对模拟外部环境和未来系统之间的交互进行建模。边界对象负责接收外部输入,处理内部内容的解释,并表达或传递响应的结果。
控制对象对行为进行封装,描述用例中事件流的控制行为。
实体对象对信息进行描述。
基于鲁棒图进行初步设计的10条经验
1.遵守建模规则
2.简化建模语法
3.遵循3种元素的发现思路
4.增量建模
先识别最“明显”的职责->开始考虑职责间的关系,并发现新职责->继续考虑职责间的关系,并发现新职责->直到模型比较完善
5.实体对象≠持久化对象
6.只对关键功能(用例)画鲁棒图
7.每个鲁棒图有2~5个控制对象
8.勿关注细节
9.勿过分关注UI,除非辅助或验证UI设计
10.鲁棒图≠用例规约的可视化
高层分割
高层分割的两种实践套路:
“高层分割”的两种实践讨论:切系统为系统;切系统为子系统
切系统为系统
具体指:
1)系统比较复杂,需要进行两级高层切分。
2)首先,把系统切成更小一级的系统,每个更小一级的系统都可以有单独的需求、设计、实现…
3)之后,针对每个“更小一级的系统”,进行“切系统为子系统”…
例子:
切系统为子系统
最常见就是分层。
例子:
分层式概念架构
分层“3+1种”流派:
Layer:逻辑层
Tier:物理层
按通用性分层
技术堆叠
Layer:逻辑层
逻辑层重视职责的划分,职责之间常常是上层使用下层的关系——但是不关心上层和下层是否能分布在不同的机器。
Tier:物理层
物理层指能分布在不同机器上的软件单元,不同物理层之间必须有跨机器访问的能力——可以通过远程条用、或通信协议等方式。
按通用性分层
指:将通用性不同的部分划归不同的层,以此作为系统的总体切分方式。
一般而言,通用程度越大,所处的层次越靠下。例如
嵌入式系统分层架构通用性越强的层,位于中间,硬件相关部分,以及应用特定部分分别位于下层和上层。例如
技术堆叠
技术堆叠不是独立的架构模式,而是基于分层架构(或其他架构模式)提供的进一步说明。
例如
考虑非功能需求
考虑非功能目标要趁早
概念架构不等于理想化架构。ADMEMS强调:
1)重大需求塑造概念架构。
2)概念架构是一个“架构设计阶段”,必须在细化架构设计阶段之前,针对重大需求、特色需求、高风险需求,形成稳定的高层架构设计成果。
3)如果只考虑“功能需求”来设计概念架构,将导致概念架构沦为“理想化架构”,这个脆弱的架构不就就会面临“大改”的压力,甚至导致投板等工作失败
本文转自:https://my.oschina.net/yaukie/blog/3060580