软件接口设计图_Java软件开发流程图

如何设计”好”的软件(模块/类)接口？ 　　写程序也有几年了，经验还算有点，什么难搞定的ｂｕｇ，陌生的技术啊，觉的自己都不怕，也有信心能够搞定，但是唯独对于“接口”这个东东，总感觉琢磨不透；你这样设计，那样设计，功能方面一般总是能够实现的；但是就是有“好”与“不好”的分别；“好”的接口就是容易使用和维护，“好”的接口感受起来就是那么的自然优雅；so…１　如何设计“好”的接口呢？２　有这方面书籍推荐吗？（目前只发现这本书“C语言接口与实现”）３　有什么方法或者建议能够提升“接口”设计的能力吗？ 　　汽车电子领域，无论从系统层级还是软件层级看，接口（Interface）存在的意义都举足轻重，也正是接口（Interface）的存在使得分层分工成为可能： 　　在系统层面， 无论是软件与软件、硬件与硬件、抑或是软硬件之间的接口，完整定义的接口可以大大简化软件开发与硬件交互（fully defined interfaces simplify software development and hardware interaction），从而实现传统服务向车辆开放式服务平台（OSP）的转型——

来源：https://www.aptiv.com/en/insights/article/smart-vehicle-architecture-key-to-the-future-of-automotive-sustainability 　　在软件层面，作为聚焦具体功能应用层（Application Layer）的算法工程师只要根据需要调用接口，而无需BSW（Base Software 基础软件）中各种复杂通信的具体实现细节，只要埋头把属于自己工作范围内的算法实现就可以了。 　　由于接口（Interface）的重要性，作为定义接口的工作产品——接口需求规范（Interface requirements specification）在系统层级和软件层级的多个过程域中都有要求，描述系统和软件层级的要素（Elements）之间的关系，其在ASPICE3.1标准中作为工作产品的编号为17-08，作为输出工作产品应具备如下特性：定义两个产品、过程或过程任务之间的关系定义什么是两者共有的准则和格式定义关键时序依赖关系或顺序排序各系统组件的物理接口描述例如总线接口（CAN、MOST、LIN、Flexray 等）收发器（类型、制造商等）模拟接口数字接口（PWM、I / O）附加接口（IEEE、ISO、蓝牙、USB 等）软件组件和其他软件项的软件接口的识别，依据：进程间通讯机制总线通信机制 　　而这些内容，又因着接口所连接要素所处的层次、以及描述的内容，分属4个不同的过程域，其中需求分析相关过程域（SYS.2/SWE.1）中的接口规范描述的是“做什么”（What）层面的要求，而架构设计相关过程域（SYS.3/SWE.2）中的接口规范则描述“怎么做”（How）层面的说明——“做什么”（What）“怎么做”（How）系统层级SYS.2 系统需求分析SYS.3 系统架构设计软件层级SWE.1 软件需求分析SWE.2 软件架构设计 　　对应到相关过程结果和实践，又可展示为如下列表——过程域接口对应工作产品相关过程结果相关实践SYS.2 系统需求分析17-08 接口需求规范 → [成果1, 3]1) 建立了一组定义的系统需求 ;SYS.2.BP1:定义系统需求。SYS.2.BP3: 分析系统需求3) 分析了系统需求对运行环境的影响;SYS.2.BP4: 分析对运行环境的影响SYS.3 系统架构设计17-08 接口需求规范 → [成果3]3) 定义了每个系统要素的接口；SYS.3.BP3: 定义系统要素的接口SWE.1 软件需求分析17-08 接口需求规范 → [成果1, 3]1) 定义了系统中分配给软件要素的软件需求及其接口；SWE.1.BP1:定义软件需求。3) 分析了软件需求对运行环境的影响；SWE.1.BP4:分析对运行环境的影响。SWE.2 软件架构设计17-08 接口需求规范 → [成果3]3) 定义了每个软件要素的接口；SWE.2.BP3:定义软件要素的接口。 　　这些是理论，举个实际的例子，以车道偏离预警LDW（Lane departure warning）功能为例： 　　SYS.1需求挖掘 　　根据百度百科，“车道偏离预警系统是一种通过报警的方式辅助驾驶员减少汽车因车道偏离而发生交通事故的系统。车道偏离预警系统由图像处理芯片、控制器、传感器等组成”，以上的描述可以作为一个“利益相关方需求（Stakeholder Requirement）”，对应于“SYS.1需求挖掘”过程域。 　　SYS.2 系统需求分析 　　看一个关于本田汽车（HONDA）LDW功能的视频（来自油管搬运）： 　　视频中给出了LDW功能启停的条件说明，其LDW指示灯根据启停状态会相应开关，其中启停状态的条件为： 　　LDW 启动条件时速45 mph（约合72千米/小时）在笔直或略微弯曲的道路上On straight or slightly curved roads 　　LDW 停止条件恶劣天气期间踩下制动器准确度取决于天气、速度和路况 　　以上关于LDW功能启停状态的描述，可以作为“系统需求（System Requirement）”放在系统层级，对应于“SYS.2 系统需求分析”，以下是视频中的相关截图。

　　SYS.3 系统架构设计 　　接下来，如果描绘系统架构，就要考虑相关的视为系统层级的不同要素（Elements），包括硬件和软件的部分。 　　硬件部分：LDW状态灯路况图像的摄像机判断车道偏离的图像处理芯片环境、车速、设备状态的相关硬件传感器相关ECU显示屏…… 　　软件部分：域控制器软件人机交互界面HMI…… 　　确认相关的软硬件要素后，为了实现这些要素的互动，就需要在“SYS.3 系统架构设计”中明确定义相关的接口，例如域控制器中基于接收到的车速、路况、天气等信息作出对LDW启停状态的判定后，需要对LDW信号灯进行相应设置，因此在系统架构的接口规范中，需要明确“域控制器、LDW信号灯之间的接口定义和适用通信协议”的相关内容。 　　SWE.1 软件需求分析 　　在ASPICE中，虽然系统和软件层级的相关组成部分都称为“要素”（Element），但到了软件层级，明显粒度就不一样了，在系统层级，整个域控制器可以作为一个软件要素，而到了软件层级，域控制器中的一个SWC（Software Component）例如LDW模块就可以称为一个要素了。

ASPICE3.1标准截图 　　此时在“SWE.1 软件需求分析”过程域中，就需要把相关的软件需求描述清楚，类似“LDW功能要输出LDW_Status信号给COM，COM再输出到CAN上”的动态行为，在这里要注意需求的定位不在于指导架构的具体实现而在于从软件层级阐明功能和非功能需求，把软件要素（software element）层级的接口规范内容说清就可以，将整个LDW当成黑匣子描述输入输出主要处理，具体实现的细节则放到架构和详设层级。 　　SWE.2 软件架构设计 　　在软件架构部分，上述软件需求相关的“LDW功能模块和COM模块的数据结构+具体信号”就需要在这里说明了。不同于C++、JAVA等面向对象语言中Interface（接口），Interface在嵌入式C语言中并不是保留字，为了实现接口有不同的方法，以AUTOSAR架构为例，就有三类接口的定义，而针对具体实现的定义就需要对应的工程师根据相应的框架进行定义了：AUTOSAR 接口“AUTOSAR 接口”定义了软件组件和/或 BSW 模块之间交换的信息。该描述独立于特定的编程语言、ECU 或网络技术。 AUTOSAR 接口用于定义软件组件和/或 BSW 模块的端口。通过这些端口，软件组件和/或 BSW 模块可以相互通信（发送或接收信息或调用服务）。 AUTOSAR 可以在本地或通过网络实现软件组件和/或 BSW 模块之间的这种通信。标准化的 AUTOSAR 接口“标准化 AUTOSAR 接口”是其语法和语义在 AUTOSAR 中标准化的“AUTOSAR 接口”。 “标准化 AUTOSAR 接口”通常用于定义 AUTOSAR 服务，这是 AUTOSAR 基础软件向应用软件组件提供的标准化服务。标准化接口“标准化接口”是在 AUTOSAR 中标准化的 API，无需使用“AUTOSAR 接口”技术。这些“标准化接口”通常是为特定的编程语言（如“C”）定义的。因此，“标准化接口”通常用于始终位于同一 ECU 上的软件模块之间。当软件模块通过“标准化接口”进行通信时，不可能再通过网络路由软件模块之间的通信。 　　如下图，参考AUTOSAR官方文档定义的组件接口视图——

来源：https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf 　　在实际开发的软件架构中，处于各种考虑当然会有不使用AUTOSAR的情形，即使如此，仍然可以借鉴AUTOSAR中对设计原则例如“SOLID”的应用，以下摘抄自AUTOSAR_EXP_SWArchitecture的节选翻译，可供参考： 　　“8.4.2 SOLID 原则 　　SOLID 原则是AUTOSAR 设计原则的核心部分。虽然这五个原则都是有效的，但只有单一职责原则，接口隔离原则和依赖倒置原则与本文档的抽象级别相关。因此，它们将在下面进行详细说明。 　　8.4.2.1 单一职责原则 　　单一职责原则 (SRP) 指出组件或类应负责软件提供的整体功能的单个部分。该职责应该由组件或类封装。组件或类（通过其接口）提供的服务应与其职责密切相关。单一职责原则最大限度地减少了需要更改其接口的原因（即更改单一职责）。因此，它最大限度地减少对客户的影响，这样的接口并导致更可维护的架构（或代码）。 　　8.4.2.2 接口隔离原则 　　接口隔离原则 (ISP) 、 指出不应强迫客户端依赖于他们不使用的方法。由于接口隔离原则，接口应该被拆分以反映客户端的不同角色。与单一职责原则类似，接口的分离减少了接口更改对分离接口的客户和供应商的影响。 　　8.4.2.3 依赖倒置原则 　　依赖倒置原则 (DIP) 、 指出高级构建块不应依赖于低级构建块。两者都应该依赖于抽象（例如接口）。此外，依赖倒置原则指出抽象（例如接口）不应该依赖于细节。细节（例如具体的实现） 　　应该依赖于抽象。依赖倒置原则导致构建块的实现解耦。这对于扩展实施工作和执行适当的集成测试很重要。” 　　以上根据一个LDW功能的实际例子，描述了SYS.2/SYS.3/SWE.1/SWE.2这四个过程域中，关于接口需求规范应当包含的内容。SYS.2 系统需求分析LDW 启动条件：时速45 mph（约合72千米/小时）；在笔直或略微弯曲的道路上。LDW 停止条件：恶劣天气期间；踩下制动器；准确度取决于天气、速度和路况；SYS.3 系统架构设计域控制器、LDW信号灯之间的接口定义和适用通信协议SWE.1 软件需求分析LDW功能要输出LDW_Status信号给COM，COM再输出到CAN上SWE.2 软件架构设计LDW功能模块和COM模块的数据结构+具体信号 　　那么，这篇文档应当将其内容分散在四个过程域的各自文档，还是作为独立的接口规范文档进行管理，再分别与各自过程域的内容建立链接，每个公司可以有各自的选择。（个人偏好后者，在这里就不展开了）