软件结构与软件架构

Question

我无法得到软件结构和软件架构之间的确切差异

一个简单的例子解释了非常感激的精确差异

BTW，我使用UML来表示架构

Answer 1

软件架构和软件结构重叠。

软件架构是一套与软件系统相关的重要方面和决策（简单地说）。它包括最重要的要求和所有类型的限制（性能，安全性等），然后是高级系统组织，系统部件之间的主要通信机制，外部依赖性，实现技术和指导，甚至风险等，等等。

我曾经读过一篇关于软件架构的精彩声明：它是一组难以改变的决策。

因此，当您不确定方面/决策是否真的与建筑相关时，请问问自己 - 如果我稍后改变这方面/决定，会产生什么影响？改变它有多难？

示例：

• 假设我们想要将客户端 - 服务器系统结构更改为3层。这次重组有多难？好吧，可能很难。因此，这是一个建筑方面。
• 我们想要改变XML和JSON之间的通信。如果没有精心设计，这可能会非常复杂，所以我们要小心对待并作为建筑要求。
• 如果我们想要在方法中更改排序算法，该怎么办？这种变化很可能是本地化的，而且成本也不高。因此，它不是建筑方面。
• 系统的某些核心模块的API定义的变化，很多其他模块和系统使用的很可能是一个建筑主题。

另一方面，

软件结构实际上是一个系统设计，可以是非常高级的（如显示主要模块或层的方框图），直到非常详细（代码蓝图）

这种软件结构的高级视图肯定会成为软件架构的一部分，而详细设计则不是（可能是一些重要的部分）。

更新（评论后）

  

1＃强烈建议软件使用哪个图表的任何提示   架构和软件结构？因为它听起来像是一类   应该在两种情况下使用图表（架构和结构）

不是要制作哪个UML图，而是显示什么是重要的，哪个方面。

因此，所有图表都可用于描述建筑方面。 最常见但可能是强制性图表是组件图。它自然地显示了系统模块的高级设计以及它们相互连接的方式。可以选择通过部署视图进行扩展。 类图用于通过表示或多或少详细的类结构和关系来显示组件的内部结构。并非所有的类图都是建筑相关的，但有些可以定义为（＆＃34;问自己......＆＃34; :)）

还有很多其他潜在的重要方面，比如系统行为。您可以使用 UML序列，状态机，活动等。其中一些构建了体系结构，另一些则不那么重要，但也很有用。

  

2＃据我所知，详细设计不是其中的一部分   建筑/结构设计，但我可以使用相同类型的   UML图，例如类和序列图（用于   架构和结构）以及更详细的信息。正确？

如上所述，它不是关于图表本身的类型，而是关于显示的内容。因此，如果您认为内容是相关的，请将其置于架构下。如果没有，则将其视为详细设计。

示例：可以显示序列以显示与外部设备的关键实时通信。虽然它可能是非常低级的，但它可能是满足重要要求的基础。 可以使用相同类型的图来显示本地算法或不太重要的用例场景，因此不是架构的一部分。

  

3＃高级设计是否与建筑设计相同

你可以这么说。 请记住，建筑与非建筑之间没有明确的前沿。它有时是主观的，重点不在于它们之间的正确分离，而在于建立一个良好的规范，这将导致产品的成功开发。