谈架构(Architecture)和架构描述(Architectural Description, AD)

ASPICE模型、功能安全(ISO26262)标准中，都包括系统架构设计活动和软件架构设计活动，并要求架构设计中包括动态设计和静态设计。

实际项目中，工程师常常纠结于：需要通过哪些视图来展示架构才能满足要求呢？

这个问题没有标准答案，是要“根据需要”，选择“合适的视图”来展示架构。

本文谈谈如何“根据需要“，选择”合适的视图“。

说明：本文内容参考自”IEEE Std 1471-2000: IEEE Recommended Practice for Architectural Description of Software-Intensive Systems”

第一部分：

System(系统)是为完成特定的功能或功能集合而组织起来的组件(components)的集合，需要满足其Mission(使命)。例如：BMS是电池管理系统，负责….

System(系统)不是孤立的，是与外界有交互的，是存在于Environment(环境)中并受其影响的。

System(系统)会有Architecture(架构)，包括系统的构成、组件之间的关系等。

Architecture(架构)通过Architecture Description(架构描述)来描述和展示。

Architecture Description(架构描述)提供了System(系统)采用该Architecture(架构)的Rationale(理由)。

第二部分：

System(系统)会有多个Stakeholder(相关方)。

例如：

从系统的设计实现方面来说，相关方会包括如：软件工程师、HW工程师、ME工程师、Process工程师、测试工程师、功能安全工程师等。

第三部分：

Stakeholder(相关方)会有其Concern(关注点)，不同的Concern(关注点)，就会有不同的Viewpoint(视角)（即：从不同的角度来看”架构”）

例如：

• 功能安全工程师关注“安全机制，安全机制的充分性和有效性、不同组件的ASIL等级“，其看架构的视角是”功能安全Viewpoint(视角)“。
• 应用软件工程师关注”系统功能逻辑“，其看架构的视角是”功能Viewpoint(视角)“。
• 底层软件工程师关注”与硬件的交互”，其看架构的视角是”软硬件交互Viewpoint(视角)“。

第四部分：

完整的描述每个Viewpoint(视角)，需要选择合适的View(视图)。例如：sequence diagram, data flow diagram, state flow diagram, scheduler diagram, timing chart等。

为了更好的理解Viewpoint和View之间的关系，大家可以回忆一下UML中提到的4+1视图：

• Viewpoint(视角)：场景视图、逻辑视图、开发视图、进程视图、部署视图
• View(视图)：用例图、类图、对象图、状态图、时序图、协作图、活动图、组件图、配置图

总结：

问：架构设计中需要使用哪些“view(视图)“呢？

答：”View(视图)”需要有效满足System Stakeholders的Concerns

附录1，完整的上述图例：

附录2，IEEE Std 1471中的图例：

文章转载自公众号：仨人谈起