我是这个领域的新手，正在尝试创建项目设计。作为两个里程碑，我定义了
- 软件的体系结构
- 设计软件
作为子任务/活动，我考虑了
- 软件的体系结构
创建组件图
- 设计软件
创建行为UML图
创建结构UML图
这是正确的吗？
这种顺序方法听起来非常理论化。在实践中，架构和设计是联系在一起的，随着设计的进展，架构出现在工作的早期阶段。
也就是说，系统理论定义了一个系统，它与环境有一个边界，由相互作用的部分组成，以实现系统的目标。从建筑学的角度来看，主要部分通常被称为"；部件"；，当他们是明确的和自立的。
在一个经典的UML视图中，您将首先使用用例图来定义系统的边界和目标。因为没有这一核心理解，其余的一切都没有意义。
然后，您确实要识别和建模主要组件，然后将组件分解为更小的组件，以此类推，直到您得到一些详细的类图。组件和类之间的桥梁是复合结构。同时，在每个级别上，您还将设计不同类的组件或对象之间的交互，以及其他行为方面。
然而，在对系统的早期思考中，要像UML所要求的那样精确和准确并不总是那么容易。例如，用客户端上的一些组件和服务器上的一堆服务来表示web体系结构并不容易简单地用UML表示。这就是为什么越来越多地使用替代的较轻建模方法的原因，例如C4模型：C4允许对体系结构有一个不太正式的高级愿景，可以轻松快速地进行重新设计，当它足够稳定时，您可以考虑在UML中进一步挖掘。