SWE.3 软件详细设计和单元构建

毕源彬爸爸

软件详细设计将软件体系结构设计过程中指定的组件细化为软件单元及其接口。这些没有在设计级别上进一步细化的软件单元及其接口是为派生的软件单元生成或开发源代码的基础。组件的详细设计应该通过描述如何静态和动态组织代码的计划来描述满足映射软件需求的方法。它还应描述不同模块将如何相互作用。
详细设计定义的可能的软件需求如:

• 非功能技术需求
  

性能(响应时间、采样时间、周期时间、截止日期、流程);
安全(非功能性安全方面，例如程序流监控);
安全;
具有定义接口的COTS(商用货架)元素等。

• 维护性需求
  

简单;
最大内聚和最小耦合;
可测试性;
可分析性;
可修改性;
应用程序接口;
编码器等。

• 业务需求
  

成本；
可移植性(重用、平台、遗留接口);
可伸缩性。
1. 进行软件详细设计

软件详细设计的描述由反映不同涉众关注点的不同抽象视图组成: 它们主要是软件单元之间关系和接口的结构视图，软件单元交互的动态行为的动态视图，以及软件单元内部行为的动态视图。“利益相关者”一词不仅限于客户，还可以包括供应商的战略规划、项目管理、开发、测试、质量保证、安全等，以及其他实体(如法律机构)。这些视图是软件的沟通、讨论、审查、分析、评估、计划、变更请求分析、影响分析、维护等所需的详细设计可视化或表示形式。
在大多数情况下，软件详细设计是图形表示和/或文本解释的混合。图形表示至少包括提供com的软件单元概述的静态视图及其接口以及描述软件单元交互的指定行为的动态视图。为了描述软件单元的内部行为，使用了图形和/或文本(伪代码)表示。
静态软件详细设计视图允许将软件分解为高内聚和低耦合的可管理软件单元。这些软件单元支持对这些详细设计元素的需求分配，并将帮助组织将工作分配给开发人员。在评估范围之外开发的软件单元(例如，开源软件、平台软件、第三方软件等)也将被纳入软件详细设计的专用元素，也必须考虑接口分析、动态行为等。
将组件分解成软件单元是由以下因素驱动的:
-- 软件单元的封装和模块化需求
-- 需要集成重用的软件单元
-- 需要可测试性
-- 软件单元的复杂性
-- 可维护性的需要
-- 工作的分配
-- 在软件单元上启用并行工作的需要
2. 定义软件单元的接口

软件接口表示软件单元的输入和输出。软件接口由传输数据的发送方、接收方、格式、大小、分辨率、质量信息、频率等定义。
3. 描述动态行为

为了描述软件组件在运行时的动态行为，需要行为描述。
--状态转换图
--序列图
--消息序列图
--用例图
哪些是必需的或适合的，取决于组件的预期应用程序。这同样适用于派生的软件单元: 例如，除了执行时间之外，可能没有必要描述不复杂的软件单元的动态行为。
此外，在定义时必须考虑响应时间，例如:
--任务
--线程的概念
--时间片
--中断
--接口
4. 评估软件详细设计

在实践中应采用以下三种详细设计开发方法中的一种，并应由评估人员识别:
1)开发替代解决方案(例如开发一个全新的组件):
对软件详细设计的几个潜在解决方案进行了描述，至少达到了一个抽象级别，允许识别详细设计之间的主要差异，并允许评估每个潜在解决方案的互操作性、交互、关键性、技术复杂性、风险和可测试性。基于第一次评估，通过执行基本实践(BP1到BP3)，至少有一个提议的解决方案被进一步阐述。必须确保选择供进一步阐述的拟议解决方案能够满足项目的所需需求。最后，根据上述评价标准(BP4)对这些提出的和改进的解决方案进行评价，并做出决策:
--选择/确认一个/建议的解决方案作为用于进一步开发的详细设计或
--拒绝先前提出的解决方案，退回到详细设计发展阶段(BP1)
2)迭代详细设计开发:
在执行基本实践(BP1到BP3)的详细设计开发过程中，使用的详细设计出现了几个变体。一个变体可以是一个完全不同的详细设计，或者一个变体可以不同于一个已经确定的拟议解决方案。因此，所选标准(BP4)的评估可以在详细设计的细化过程中进行几次，详细设计是在最后选定的，并被用作进一步开发的基础。
3)继承和改编现有的详细设计(例如平台开发):
虽然详细设计开发只使用一种解决方法，但必须根据上述评价标准确保所选择的方法适用于项目并有效。因此BP4被简化为只评估一个解决方案。应消除评价过程中查明的弱点，或必须公开所选详细设计中弱点的后果。
5. 开发软件单元

在基于模型的开发中，软件单元的源代码通常是由适当的代码生成工具生成的。软件单元不能包含详细设计中没有描述的内容，例如，这支持可维护性或缺陷分析。
如下是ASPICE给出的一般建议：


下图显示了SWE.3基本实践之间的关系以及它们与其他进程的关系: