从需求分析到架构设计

合集下载

如何进行系统架构设计

如何进行系统架构设计

如何进行系统架构设计在软件开发领域,系统架构设计是确保软件系统功能、性能、安全性和可扩展性的关键环节。

一个好的系统架构设计可以帮助开发团队合理规划项目,提高开发效率,同时确保系统的稳定和可维护性。

本文将介绍如何进行系统架构设计,包括需求分析、设计原则、架构模式和最佳实践等方面。

1. 需求分析系统架构设计的第一步是进行需求分析。

了解和理解系统的功能和业务需求,明确系统所需的基本功能以及预期的性能和安全性要求。

此外,还要考虑系统可能面临的未来扩展需求,以确保系统架构具有可扩展性。

2. 设计原则在进行系统架构设计时,需要遵循一些设计原则来确保系统的稳定性和可维护性。

以下是一些常用的设计原则:- 单一职责原则:每个模块或组件应该具有清晰的单一功能。

- 开放封闭原则:系统架构应该对扩展开放,但对修改封闭。

- 依赖倒置原则:模块之间的依赖关系应该依赖于抽象而不是具体实现。

- 接口隔离原则:接口应该小而专一,而不是大而全。

- 里氏替换原则:子类应该能够替代父类并保持系统行为的一致性。

3. 架构模式选择适合系统需求的架构模式是系统架构设计的关键。

以下是一些常用的架构模式:- 分层架构:将系统划分为不同的层次,每个层次负责不同的功能。

常见的分层架构包括三层架构和MVC架构。

- 微服务架构:将系统拆分为多个小型的、独立的服务,每个服务独立部署和扩展。

- 事件驱动架构:系统内各个组件通过事件进行通信和交互。

- 中间件架构:使用中间件来协调不同组件之间的通信和数据传输。

4. 组件选择在进行系统架构设计时,需要选择合适的组件来实现系统的功能。

选择合适的组件可以提高开发效率和系统性能。

在选择组件时,需要考虑以下因素:- 功能是否符合系统需求;- 组件的可靠性和稳定性;- 组件的性能和扩展性;- 组件的兼容性和维护性。

5. 最佳实践系统架构设计并不是一蹴而就,需要在实践中不断调整和优化。

以下是一些最佳实践的建议:- 进行原型设计来验证架构是否满足需求;- 使用设计模式来解决常见的设计问题;- 采用自动化部署和测试工具来提高开发效率;- 使用监控和日志记录工具来监控和诊断系统性能和异常情况;- 进行定期的系统审查和评估,以确保系统架构与业务需求的一致性。

架构设计方法

架构设计方法

架构设计方法架构设计是一项非常重要的任务,它在软件开发生命周期中占据着至关重要的地位。

一个好的架构设计决定了软件的质量和稳定性,因此需要一种科学的方法来辅助架构设计。

在本文中,我们将介绍一些常用的架构设计方法。

1. 需求分析需求分析是架构设计的第一步。

在这一步中,我们需要收集和确定系统的所有功能和问题,这些问题将被作为架构设计的基础。

需求分析应包括用户需求,系统需求和一些非功能需求,如性能、安全等等。

2. 质量属性分析质量属性是指软件的各种方面质量指标,如性能、可用性、可维护性等。

在架构设计中,我们必须考虑所有这些质量属性和其他一些非功能需求。

我们需要分析软件的许多质量属性,并确定我们希望系统满足的权衡。

3. 技术过程架构设计需要各种技术和工具的支持。

我们需要确定我们将使用的技术,并对系统的各种方面进行分析。

通过这种分析,我们可以确保我们选择的技术能够满足系统的需求,并且可以与所有其他组件和功能很好地协同工作。

4. 系统结构系统结构是定义软件系统中各个模块或组件之间关系的方法。

在架构设计中,我们需要确定每个模块或组件之间的接口,并确定如何协调它们的工作。

确定系统结构是一个持续的过程,它要求开发人员在开发过程中反复检查。

5. 模式模式是快速构建高质量软件系统的库和经验的指南。

模式是一种反复出现的解决方案或结构模板,可以在相似的情况下使用。

模式分为架构模式和设计模式。

架构模式是解决复杂系统问题的模板,它指导系统结构的选择。

这些模式一般涉及到系统结构、数据流程和组件之间的关系。

设计模式,另一方面,是指在设计单个组件时应用的指南。

6. 演进软件架构是一个动态的过程,它需要不断地进化和改进。

软件的需求也随着时间不断发生变化。

因此,软件架构应该被看作一个基于不断演进和改进的过程。

在新的要求出现时,架构师应该及时调整系统结构,并保证整个系统能够满足现在和未来的需求。

总之,架构设计是软件开发的重要组成部分。

采用上述架构设计方法,可以帮助我们更好地理解和设计软件系统,提高软件质量和可维护性。

IT架构规划方法

IT架构规划方法

IT架构规划方法在进行IT架构规划时,需要遵循一定的方法和步骤,以确保规划的有效性和可持续性。

以下是一个常用的IT架构规划方法,包括四个主要步骤:需求分析、架构设计、实施计划和监控评估。

第一步:需求分析需求分析是IT架构规划的第一步,它的目的是理解业务需求和用户需求,为架构设计提供基础。

在这个阶段,需要进行以下活动:1.了解业务目标:与业务单位合作,了解其长期和短期的业务目标,以及IT对业务的支持需求。

2.收集用户需求:与各类用户交流,了解他们的需求和期望。

这些用户可能包括企业员工、客户和合作伙伴。

3.评估现有系统:评估现有的IT系统和基础设施,包括硬件、软件和数据存储。

这将有助于确定哪些系统可以继续使用,哪些系统需要更新或替换。

4.分析技术趋势:研究当前的技术趋势和最佳实践,特别是与组织的业务目标相关的技术。

第二步:架构设计在需求分析的基础上,进行架构设计以满足业务需求。

架构设计的目标是设计一个具有高性能、可扩展性和可靠性的系统。

在这个步骤中,需要进行以下活动:1.定义架构原则:定义IT架构设计的准则和原则,以指导设计过程。

这些原则可能包括可扩展性、灵活性、安全性等。

2.制定技术架构:设计一个技术架构,包括硬件、软件、网络和数据存储。

确保各个组件之间的互操作性和集成性。

3.制定数据架构:设计一个数据架构,包括数据存储、数据管理和数据流程。

确保数据的一致性、可靠性和安全性。

4.制定应用架构:设计一个应用程序架构,包括应用程序的开发、测试、部署和维护。

确保应用程序的可扩展性、可靠性和安全性。

5.制定安全架构:设计一个安全架构,包括身份验证、授权、加密和网络安全。

确保系统的机密性、完整性和可用性。

第三步:实施计划在进行架构设计之后,需要制定一个详细的实施计划,以确保规划的顺利实施。

在这个步骤中,需要进行以下活动:1.制定项目计划:制定一个详细的项目计划,包括各个阶段的目标、时间表和里程碑。

2.资源规划:确定所需的人力、财力和技术资源,以支持规划的实施。

软件系统设计方案

软件系统设计方案

软件系统设计方案一、引言在当今信息技术高速发展的时代,软件系统已经成为各行各业中不可或缺的一部分。

软件系统的设计方案是确保软件项目成功实施的关键之一。

本文将从需求分析、系统架构设计、模块设计和测试策略等方面,提出一个完整的软件系统设计方案。

二、需求分析需求分析是软件系统设计的第一步,它是确定软件系统应具备的功能和性能要求的过程。

在需求分析阶段,我们将与客户深入沟通,明确软件系统的业务流程、用户需求和系统约束条件。

通过需求分析,我们可以确保软件系统的功能和性能与用户期望相一致。

三、系统架构设计系统架构设计是软件系统设计的核心环节,它决定了软件系统的整体结构和组织方式。

在系统架构设计中,我们将根据需求分析的结果,确定软件系统的模块划分和模块间的关系。

同时,我们还将选择合适的技术框架和平台,确保系统的可扩展性和可维护性。

四、模块设计模块设计是系统架构设计的具体实施过程,它将系统架构转化为具体的模块设计方案。

在模块设计中,我们将根据功能需求,将系统划分为若干个模块,并为每个模块定义清晰的接口和功能。

同时,我们还将考虑模块的内聚性和耦合性,以确保系统的可靠性和可维护性。

五、测试策略测试是软件开发过程中不可或缺的一环,它可以发现和修复软件系统中的缺陷和错误。

在测试策略中,我们将制定详细的测试计划,并选择合适的测试方法和工具。

我们将进行单元测试、集成测试和系统测试,以确保软件系统的质量和稳定性。

六、总结软件系统设计方案是软件项目成功实施的关键之一。

通过需求分析、系统架构设计、模块设计和测试策略等环节的合理规划和实施,我们可以确保软件系统的功能和性能与用户期望相一致。

同时,我们还可以提高软件系统的可扩展性、可维护性和可靠性。

希望本文提供的软件系统设计方案能够对您的软件项目有所帮助。

七、参考文献[1] Pressman, R. S. (2014). Software Engineering: A Practitioner's Approach. McGraw-Hill Education.[2] Sommerville, I. (2015). Software Engineering. Pearson Education Limited.。

如何进行合理的软件架构设计

如何进行合理的软件架构设计

如何进行合理的软件架构设计软件架构设计是开发一个成功的软件系统所必不可少的一项重要工作。

一个合理的软件架构可以使软件系统具备良好的可维护性、可扩展性和可重用性,同时也能提高开发效率和降低开发成本。

下面将从需求分析、模块划分、技术选择和系统交互等方面讨论如何进行合理的软件架构设计。

1. 需求分析- 了解用户需求:与客户或最终用户充分沟通,理解用户需要什么功能和性能,明确软件系统的主要目标和业务流程。

- 制定系统需求规格说明书:明确系统的功能、性能、非功能需求和约束条件,为后续的架构设计提供依据。

- 划分关键需求和非关键需求:将需求进行优先级排序,确保关键需求在软件架构设计中得到合理的考虑。

2. 模块划分- 根据功能进行模块划分:将系统的功能模块分解成若干相对独立的模块,每个模块负责一个明确的功能,便于各个模块的开发和维护。

- 定义模块之间的接口:明确定义模块之间的接口,确保模块之间的交互符合系统需求,同时也方便模块的替换和升级。

- 考虑模块间的数据流和消息传递:合理规划模块间的数据流和消息传递,确保模块之间的通信高效可靠。

3. 技术选择- 根据系统需求选择适当的技术:根据系统的性能要求、数据处理需求等方面,选择适合的编程语言、数据库、网络通信和图形界面等技术。

- 考虑技术的成熟度和可持续性:选择成熟度高、稳定性好的技术,能够降低系统开发和维护的风险。

- 考虑技术的开放性和可扩展性:选择开放源代码、具有良好接口和可扩展性的技术,方便今后系统的升级和功能扩展。

4. 系统交互- 考虑系统的用户界面设计:根据用户需求和交互习惯,设计友好、易用的用户界面,提高用户的操作效率和满意度。

- 考虑系统的分布式部署:如果系统需要在多个节点上运行,需要考虑节点之间的数据同步、一致性和故障恢复等问题,确保系统的可靠性和性能。

- 考虑系统的安全性和权限控制:根据系统的保密性和合规性要求,合理设计系统的安全机制,确保用户数据和系统的安全。

应用架构设计的步骤

应用架构设计的步骤

应用架构设计的步骤应用架构设计是软件开发过程中的关键步骤,它决定了系统的可扩展性、可维护性和性能。

以下是一个应用架构设计的基本步骤:1、需求分析:首先,我们需要对系统进行全面的需求分析。

这包括对业务需求、用户需求、功能需求和非功能需求的理解和梳理。

这个过程需要与项目干系人进行深入的交流和讨论,以确保对需求的理解准确无误。

2、系统设计:在理解了需求之后,我们需要进行系统设计。

系统设计包括对系统的整体架构、模块划分、模块之间的接口和通信方式等进行设计。

这个过程需要考虑到系统的可扩展性、可维护性和性能等因素。

3、技术选型:在确定了系统设计后,我们需要进行技术选型。

这包括对开发语言、开发框架、数据库系统、服务器等技术的选择。

技术选型需要考虑到项目的实际需求、开发团队的技术水平和经验等因素。

4、架构设计:在完成了需求分析、系统设计和技术选型后,我们需要进行详细的架构设计。

架构设计包括对系统的整体架构、模块划分、模块之间的接口和通信方式等进行详细的设计。

这个过程需要考虑到系统的可扩展性、可维护性和性能等因素,同时还需要考虑到开发团队的技术水平和经验等因素。

5、编码实现:在完成了架构设计后,我们需要进行编码实现。

这个过程需要根据架构设计进行具体的编码工作,包括模块的开发、测试和调试等。

6、测试与部署:在完成了编码实现后,我们需要进行测试和部署。

测试包括单元测试、集成测试和系统测试等,以确保系统的功能和性能符合需求。

部署则是指将系统部署到生产环境中,以供用户使用。

7、维护与优化:在系统上线后,我们需要对其进行维护和优化。

这包括对系统的监控、故障排除、性能优化等。

同时,我们还需要根据用户反馈和业务变化对系统进行不断的优化和改进。

总之,应用架构设计是软件开发过程中的重要步骤,它决定了系统的整体结构和性能表现。

因此,在进行应用架构设计时,我们需要全面考虑各种因素,以确保设计的合理性和有效性。

软件工程中的需求分析与系统架构设计实践

软件工程中的需求分析与系统架构设计实践

软件工程中的需求分析与系统架构设计实践需求分析与系统架构设计是软件工程中非常重要的两个环节。

需求分析是软件开发的第一步,它确定了软件系统需要解决的问题,并将这些问题转化为明确且可验证的需求。

而系统架构设计则是在需求分析的基础上,按照合理的结构和设计原则,对软件系统的整体架构进行规划和设计。

在需求分析阶段,软件工程师与业务部门紧密合作,从用户、系统、环境等多个角度收集和分析需求。

其目的是了解软件系统的目标、功能、性能、界面等要求,以便在后续的开发工作中能够清晰地定义这些需求。

需求分析的主要任务包括需求获取、需求建模、需求验证和需求管理。

首先,需求获取通过对用户、业务和系统的交流,以及现有的文档和资料进行调研,收集和整理需求。

在需求获取过程中,软件工程师需要运用适当的技术和工具,如面谈、问卷调查、观察等,确保收集到全面、准确的需求。

接下来,需求建模将收集到的需求进行整理、归类和建模,以帮助开发团队更好地理解和分析需求。

建模可以采用用例图、活动图、状态图等各种图形化表示的方法,以及类图、序列图等面向对象的设计方法,来将需求转化为可视化的模型,使得需求更加清晰明了。

然后,需求验证是为了确保收集到的需求是正确的、完整的且可验证的。

验证可以通过多种方法进行,如需求评审、原型验证、模拟实验等。

验证的目的是发现和纠正需求中的错误和缺陷,以提高软件的质量和用户满意度。

最后,需求管理是对需求进行跟踪、变更和控制的过程。

由于需求通常在软件开发的过程中会发生变化,软件工程师需要建立一个有效的需求管理机制,及时处理和跟踪需求变更,并确保所有变更都经过合理的评估和批准。

需求分析完成后,接下来是系统架构设计。

系统架构设计是在需求分析的基础上,将功能和非功能需求转化为一个具体的、可实现的系统架构。

一个好的系统架构能够确保软件系统具备良好的可扩展性、可维护性和可靠性。

系统架构设计通常包括四个主要的工作:系统总体设计、子系统设计、数据设计和界面设计。

实施新架构的步骤包含什么

实施新架构的步骤包含什么

实施新架构的步骤包含什么引言随着技术的不断进步和业务的不断发展,许多组织开始考虑实施新的架构来提高系统的性能、可维护性和可扩展性。

但是,实施新架构是一项复杂的任务,需要经过详细的计划和执行。

本文将介绍实施新架构的步骤,并提供一些建议和最佳实践。

步骤包含实施新架构的步骤可以分为以下几个重要部分:1.需求分析:在开始实施新架构之前,首先需要进行需求分析。

这涉及与利益相关者讨论和确定当前系统存在的问题,以及他们对新架构的期望。

需求分析的结果将指导后续步骤的实施计划。

2.架构设计:在需求分析的基础上,开始进行新架构的设计。

架构设计应包括系统的整体结构、组件之间的关系、数据流程和接口定义等。

此外,还应考虑系统的可扩展性、可维护性和安全性等方面。

3.技术选型:在进行架构设计时,需要选择合适的技术和工具来支持新架构的实施。

这可能包括选择合适的编程语言、开发框架、数据库系统等。

技术选型应综合考虑系统需求、团队技术能力、市场趋势等因素。

4.团队组建:实施新架构需要一个有能力的团队来完成。

根据项目规模和复杂性,确定合适的团队规模,并保证团队成员具备必要的技术背景和经验。

此外,建立良好的沟通和协作机制也是团队组建的重要环节。

5.原型开发:在正式实施新架构之前,建议先进行原型开发。

原型可以帮助验证架构设计的可行性并发现潜在问题。

根据需求和优先级,选择合适的功能点进行原型开发,并通过迭代的方式逐步完善。

6.系统迁移:将现有系统迁移到新架构是实施新架构的关键步骤之一。

在进行系统迁移时,需要考虑数据迁移、业务流程切换、系统兼容性等问题。

为了降低迁移的风险,可以选择渐进式迁移或并行运行方式。

7.测试和验证:在完成系统迁移后,需要进行详细的测试和验证以确保新架构的功能和性能达到预期。

测试应包括单元测试、集成测试和系统测试等方面,并根据测试结果进行必要的优化和调整。

8.部署上线:当新架构经过测试和验证后,可以进行最终的部署上线。

在部署上线之前,需要准备好相应的运维和监控措施,并进行必要的培训和用户支持。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

物理视图:和部署相关的架构决策

软件最终要驻留、安装或部署到硬件才能运行, 而软件架构的物理视图关注“目标程序及其依赖 的运行库和系统软件”最终如何安装或部署到物 理机器,以及如何部署机器和网络来配合软件系 统的可靠性、可伸缩性等要求。
图9所示的物理架构视图表达了设备调试系统软件和硬 件的映射关系。可以看出,嵌入部分驻留在调试机中 (调试机是专用单板机),而PC机上是常见的桌面可 执行程序的形式。
和工程领域的功能需求、约束条件、使用期质量 属性、建造期间的质量属性等类似,软件系统的 需求种类也相当复杂,具体分类如下图所示。
超市系统案例
功能需求
简单而言,功能需求就是“软件有什么用,软件需要做 什么”。同时,注意把握功能需求的层次性是软件需求的 最佳实践。以该超市系统为例: 超市老板希望通过软件来“提高收银效率”。 那么,你可能需要为收银员提供一系列功能来促成这 个目的,比如供收银员使用的“任意商品项可单独取消” 功能有利于提供收银效率(笔者曾在超市有过被迫整单取 消然后一车商品重新扫描收费的痛苦经历)。 而具体到这个超市系统,系统分析员可能会决定要提 供的具体功能为:通过收银终端的按键组合,可以使收银 过程从“逐项录入状态”进入“选择取消状态”,从而取 消某项商品。
运行期质量属性。这类需求主要指软件系 统在运行期间表现出的质量水平。
运行期质量属性非常关键,因为它们直接影响着 客户对软件系统的满意度,大多数客户也不会接 受运行期质量属性拙劣的软件系统。常见的运行 期质量属性包括软件系统的易用性、性能、可伸 缩性、持续可用性、鲁棒性、安全性等。在我们 的超市系统的案例中,用户对高性能提出了具体 要求(真正的性能需求应该量化,表1没体现), 他们不能容忍金额合计超过2秒的延时。
进程视图:设计满足运行期质量属性的架构
性能是软件系统运行期间所表现出的一种质量水 平,一般用系统响应时间和系统吞吐量来衡量。 为了达到高性能的要求,软件架构师应当针对软 件的运行时情况进行分析与设计,这就是我们所 谓的软件架构的进程视图的目标。进程视图关注 进程、线程、对象等运行时概念,以及相关的并 发、同步、通信等问题。
嵌入层。负责对调试设备的具体控制,以及高频度 地从数据采集器读取设备状态数据。
设备控制指令的物理规格被封装在嵌入层内部,读取数采 器的具体细节也被封装在嵌入层内部。
开发视图:设计满足开发期质量属性的架构
软件架构的开发视图应当为开发人员提供切实的指导。任 何影响全局的设计决策都应由架构设计来完成,这些决策 如果“漏”到了后边,最终到了大规模并行开发阶段才发 现,可能造成“程序员碰头儿临时决定”的情况大量出现, 软件质量必然将下降甚至导致项目失败。 其中,采用哪些现成框架、哪些第三方SDK、乃至哪 些中间件平台,都应该考虑是否由软件架构的开发视图确 定下来。图6展示了设备调试系统的(一部分)软件架构 开发视图:应用层将基于MFC设计实现,而通讯层采用了 某串口通讯的第三方SDK。
本案例中架构师为了满足高性能需求,采用了多线程设计: 应用层中的线程代表主程序的运行,它直接利用了MFC 的主窗口线程。无论是用户交互,还是串口的数据到达,均 采取异步事件的方式处理,杜绝了任何“忙等待”无谓的耗 时,也缩短了系统响应时间。 通讯层有独立的线程控制着“上上下下”的数据,并设 置了数据缓冲区,使数据的接收和数据的处理相对独立,从 而数据接收不会因暂时的处理忙碌而停滞,增加了系统吞吐 量。 嵌入层的设计中,分别通过时钟中断和RS232口中断来 激发相应的处理逻辑,达到轮询和收发数据的目的。
开发期质量属性。
这类非功能需求中的某些项人们倒是念念不忘, 可惜很多人并没有意识到“开发期质量属性”和 “运行期质量属性”对架构设计的影响到底有何 不同。开发期质量属性是开发人员最为关心的, 要达到怎样的目标应根据项目的具体情况而定, 而过度设计会花费额外的代价。
什么是软件架构视图 ?
Philippe Kruchten在其著作《Rational统一过程引论》中 写道: 一个架构视图是对于从某一视角或某一点上看到的系 统所做的简化描述,描述中涵盖了系统的某一特定方面, 而省略了于此方面无关的实体。 架构要涵盖的内容和决策太多了,超过了人脑“一蹴而就” 的能力范围,因此采用“分而治之”的办法从不同视角分 别设计;同时,也为软件架构的理解、交流和归档提供了 方便。 1995年,Philippe Kruchten在《IEEE Software》上发表 了题为《The 4+1 View Model of Architecture》的论文, 引起了业界的极大关注,并最终被RU架构视图 都应该关注和遵守的一些设计限制。例如,考虑 到“一部分开发人员没有嵌入式开发经验”这条 约束情况,架构师有必要明确说明系统的目标程 序是如何编译而来的。
图7展示了整个系统的桌面部分的目标程序pcmoduel.exe、以及嵌入式模块rom-module.hex是如何编 译而来的。这个全局性的描述无疑对没有经验的开发人员 提供了实感,利于更全面地理解系统的软件架构。
设备调试系统案例
逻辑视图:设计满足功能需求的架构 应用层。负责设备状态的显示,并提供模拟控制台 供用户发送调试命令。
使用通讯层和嵌入层进行交互,但应用层不知道通讯的细 节。
通讯层。负责在RS232协议之上实现一套专用的 “应用协议”。
当应用层发送来包含调试指令的协议包,由通讯层负责按 RS232协议将之传递给嵌入层。当嵌入层发送来原始数据, 由通讯层将之解释成应用协议包发送给应用层。
从需求分类到多视图架构设计方法
需要架构设计的多重视图方法,从根本上 来说是因为需求种类的复杂性所致。
Eg:设计一座跨江大桥: 我们会考虑“连接南北的公路交通”这个“功能需求”, 从而初步设计出理想化的桥墩支撑的公路桥方案;然后还 要考虑造桥要面临的“约束条件”,这个约束条件可能是 “不能影响万吨轮从桥下通过”,于是细化设计方案,规 定桥墩的高度和桥墩之间的间距;另外还要顾及“大桥的 使用期质量属性”,比如为了“能在湍急的江流中保持稳 固”,可以把大桥桥墩深深地建在岩石层之上,和大地浑 然一体;其实,“建造期间的质量属性”也很值得考虑, 比如在大桥的设计过程中考虑“施工方便性”的一些措施。
非功能需求
约束。要开发出用户满意的软件并不是件容易的 事,而全面理解要设计的软件系统所面临的约束 可以使你向成功迈进一步。
约束性需求既包括企业级的商业考虑(例如“项目预算有 限”),也包括最终用户级的实际情况(例如“用户的平 均电脑操作水平偏低”);既可能包括具体技术的明确要 求(例如“要求能在Linux上运行”),又可能需要考虑 开发团队的真实状况(例如“开发人员分散在不同地 点”)。这些约束性需求当然对架构设计影响很大,比如 受到“项目预算有限”的限制,架构师就不应选择昂贵的 技术或中间件等,而考虑到开发人员分散在不同地点”, 就更应注重软件模块职责划分的合理性、松耦合性等等。
相关文档
最新文档