在软件工程中，我如何轻松区分子系统和系统组件？
分别为它们提供详细的定义。
为了让我更清楚，让我们考虑一下系统是一个StackOverflow站点，它的组件和子系统是什么？
我谨慎地回答这个问题部分是因为我们可以根据上下文有很多定义。
例如，您可以在UML文献中搜索系统和组件的定义，并发现它与《操作系统》一书有所不同。
就是说，这些是我对组件和子系统的谦逊定义。我并不是说那是完全正确的。
这只是我在投影应用程序时脑海里整理事物的一种方式。
首先定义“系统”。注意我称“ The”而不是“ a”系统。因为在这里，系统是我们的世界。
该系统是我们正在从事的项目。作为软件工程师/架构师/开发人员，您的使命是使之栩栩如生，进行维护并使之蓬勃发展。
我没有简单的“系统”定义，因为不同的项目具有不同的上下文。
由于内部文化的原因，即使是在不同商店的类似项目，其语言也会略有不同。
恕我直言，定义取决于语言，而语言则取决于文化，文化是从上下文演变而来的。
但是我离题了。在简历中，您的定义取决于您的上下文。
例如，在DDD中，必须定义一个UbiquitousLanguage以确保每个人都在同一页面中。
让我们称其为“蓝图”，因为您用于抽象项目的图与UML，Bizagi等无关。
子系统的通用定义可以是：
从系统的角度来看，它是您最喜欢的蓝图上的黑匣子。通常，子系统本身就有一个蓝图，从这个角度来看，它是系统。
子系统可以自己生存，并且在系统上具有明确定义的目的和意义。
例子：
他们是厨房，卧室，房屋的地下室。
对于SO，您可以说有一个标点符号子系统，负责管理用户如何赚取和失去积分。
请注意，SE站点的每个实例都可以具有这样的子系统，甚至它们可以进行通信以跟踪您在许多SE站点中的观点。
其他示例可以是用于持久化和获取相关数据的持久性子系统。
组件的通用定义可以是：
它们很少出现在“系统蓝图”上，并且自己很少获得蓝图。
通常，组件在系统外部没有意义。它们可以被系统和子系统使用，但目的是通用的。
在房子里，它们是墙壁和家具。虚幻的椅子听起来很不对劲，会议室中的椅子有用途，但不是子系统。对于SO，组件可以是用于编写/编辑答案和问题的在线文本编辑器。
值得一提的是第三方组件：
它们本身可以是系统，甚至可以是非常复杂的系统，例如DBMS或jQuery JavaScript库。
通常，以任何蓝图绘制它们是错误的。它们可以在全球范围内使用并且是出色的工具，但它们是具有通用目的的黑匣子。对于SO，它们可以是SQL DBMS和JavaScript库
总结：
子系统可以不存在其父系统而存在。
组件不能单独使用，必须是系统的一部分才能存在。
打个比方：
汽车是旅行基础设施的子系统。
车轮是汽车的组成部分。
正如我所说的，这只是恕我直言。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句