软件结构与软件架构[关闭]

Question

我无法准确了解软件结构和软件架构之间的区别

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

顺便说一句，我使用 UML 来表示架构

Answer 1

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

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

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

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

例子：

• 假设我们要将客户端-服务器系统结构更改为 3 层。这次重组有多难？嗯，可能很难。因此，这是一个架构方面的问题。
• 我们想改变 XML 和 JSON 之间的通信。如果设计得不好，这可能会非常复杂，因此我们会谨慎对待它并将其视为架构需求。
• 如果我们想更改方法中的排序算法怎么办。这种变化很可能是本地化的，而且成本不是很高。因此，这不是架构方面的问题。
• API 或系统的某些核心模块（被许多其他模块和系统使用）的定义变化很可能是一个架构主题。

另一方面，

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

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

更新（在 cmets 之后）

1#关于软件强烈推荐哪个图表的任何提示 架构和软件结构？因为它听起来像那个类 在两种情况下都应该使用图表（架构和结构）

这不是关于制作哪个UML图，而是展示什么重要，哪个方面。

因此，所有图表都可以用来描述架构方面。 然而，最常见且可能是强制性的图表是组件图。它自然地展示了系统模块的高级设计以及它们相互连接的方式。它可以通过部署视图选择性地扩展。 类图用于显示组件的内部结构，通过表示或多或少详细的类结构和关系。并非所有类图都与架构相关，但有些绝对可以（“问问自己……”:)）

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

2#据我了解，详细设计不是一部分 建筑/结构设计，但我可以使用相同类型的 UML 图，例如类和序列图（用于 架构和结构）以及更详细的信息。对吧？

如前所述，这与图表本身的类型无关，而与显示的内容有关。所以，如果你认为内容是相关的，你就把它放在架构下。如果不是，则将其视为详细设计。

示例：可以显示序列以显示与外部设备的关键实时通信。尽管它可能是非常低级的，但它对于满足一项重要要求可能是基础性的。 相同类型的图表可用于显示不那么重要的本地算法或用例场景，因此不属于架构的一部分。

3#高层设计和建筑设计一样吗

你可以这么说。 请记住，虽然架构和非架构之间没有明确的界限。它有时是主观的，重点不是正确区分它们，而是建立一个良好的规范，这将导致成功的产品开发。