如何进行系统的架构设计
如何进行系统的架构设计
方法/步骤一个软件项目在需求确定后，就可以开始系统的架构设计了。架构设计不同于编写代码，需要遵循严格的语法和编程规范。它没有规范可遵循，存在即合理，适合系统开发和运行的架构就是最合理的系统架构。
系统的架构设计是在业务需求已经清晰的前提下进行的，假定在系统需求分析阶段已经确定了系统的功能和业务范围，也明确了系统运营需求。在上述需求还没有确定的情况下，不适宜开展系统的架构设计，需要回到需求分析阶段完善上述需求后再开展系统的架构设计。
系统架构就是一些模型图，模型图是人们用来理解系统和沟通的工具。这些模型图需要提供给系统相关干系人来理解系统，系统相关干系人有项目经理、产品经理、开发人员、系统运营维护人员、客户、项目投资人等。这些干系人有不同的知识背景，对同一架构模型图也会有不同的认知和理解：如果把开发架构模型图给产品经理或客户看，他们定然看不懂也不能理解；同样的道理，如果只把逻辑架构图给开发人员看，就不能正确地指导开发人员构建开发环境。
因此架构设计师在进行系统架构设计时，需要从系统的不同维度进行设计，以满足系统相关干系人理解系统架构的需求。架构设计模型主要有逻辑架构、开发架构、数据架构、物理架构和运行架构五种模型图。一般来说需要设计的系统架构模型有逻辑架构、开发架构和物理架构三种架构模型图。数据架构模型一般放在数据库中进行设计，运行架构和物理架构基本相近，只是在物理架构中加了数据的流向，因此一些系统设计使用物理架构代替了运行架构。
设计逻辑架构模型
逻辑架构模型主要是确定系统的功能范围和系统划分。在设计逻辑架构模型时，可以抓住两个关键点：一个关键点是对系统进行逻辑划分，将一个大系统划分为多个子系统；另外一个关键点是明确各子系统之间的协作和调用关系。
绘制逻辑架构的模型图有系统流程图和系统结构图：系统流程图描述了系统各子系统、相关文件和数据之间的关系，记录了整个系统的体系结构；系统结构图也称为层次图，它以层次方式描述了系统从顶层到最底层的功能分解。
下图分别是人脉系统的系统流程图和系统结构图。
上面的人脉系统流程图和人脉系统结构图就是依据人脉系统需求规格说明书给出的功能和业务范围绘制的。
设计开发架构模型
开发架构模型图是给开发人员看的，开发架构模型指导开发人员如何来架构系统的开发环境。开发环境包括系统开发框架的选型、开发工具和编程语言、模块划分等内容。下图是人脉系统开发架构模型图。
开发架构模型图给出了技术体系是B/S结构，开发框架选择SSM，开发语言是JavaEE。系统采用三层结构，分别是表示层、WEB应用层和数据层。表现层是JSP页面，在浏览器中运行，表现层是MVC的View。WEB应用层的控制层是MVC的Controller，业务逻辑层是MVC的Service，实体层是MVC的POJO。数据层由MyBaits数据库开发框架组成。
设计物理架构模型
物理架构模型是给系统部署人员和运营维护人员看的，主要给出系统的部署环境模型，包括网络环境、硬件环境和软件环境。下图是系统部署网络环境模型图。
从上面网络环境模型图中可以看出，系统部署只需要一台主机，要求支持HTTP协议和远程桌面协议。系统可以考虑部署到阿里云或腾讯云。
系统的架构设计主要涉及到三种模型图，分别是逻辑架构模型、开发架构模型和物理架构模型。逻辑架构模型一般采用系统流程图和系统结构图建模；开发架构模型没有标准的模型图，可以使用PPT或Visio绘图工具进行绘制；物理架构模型主要是由网路环境、硬件和软件环境组成。
组建无线局域网的意义和目的
收集该组织信息些信息应该包括内容：1.该组织历史与目前状况 2.该组织历史与目前状况
3操作策略与管理程序
4.办公系统应用程序
随着微电子技术的不断发展，无线局域网（WLAN）技术在工业控制网络中发挥着越来越大的作用。无线局域网具有安装便捷、使用灵活、经济节约、易于扩展等有线网络无法比拟的优点，因此无线局域网得到越来越广泛的使用。本文简述了在企业中布置无线局域网的概况，说明了其商业驱动力以及企业将切实感受到的效益。
传统ERP系统部署方法借用了工程和质量定律的概念。它包含定义良好的项目阶段，方法和交付物。简单来说，它的总体思想是三思而后行，目标是部署高质量的系统，同时将返工成本控制到最小，同时控制项目后端应用的延迟最小化。
选择某一种ERP系统部署方案而不是另一种，取决于项目和企业。在大型项目中或者需求复杂的大公司，或者财务投资回报率是主要度量指标的公司，我们应该选择传统方法。这些类型的项目已经意味着更多风险，软件本身可能不会给项目带来益处。
在上面的情况下，通常有许多遗留系统要做替换或集成，有更多的业务流程要重新设计。不管我们是否愿意，这些工作往往需要更长时间。
当然，在许多情况下，ERP系统部署是最佳方案。例如，快速部署更适合于中小规模的企业，他们只有少量的系统要做替换，他们的大部分业务流程都是手工做。因此，任务的自动化或者只有一套集成系统将主要倾向于从业务和最终用户的角度。
在进行系统设计时，不仅要考虑软件的功能性需求，还要考虑非功能性需求，比如软件的性能(Performance)、可扩展性(Scalability)，系统的稳定性(Reliability)、部署(Deployment)和更新(Upgrade)，可维护性(Maintainability)，版本的管理，系统的安全(Security)，界面的友好程度可用性(Usability, User experience)等。要想覆盖所有需求，实现一个简单而优秀的系统，可谓艰难。
大道至简，合适最好
什么是优秀的系统设计？ 这个问题颇有争议，但几乎每个软件工程师和架构师都追求优秀的系统设计。当然，系统设计并不代表结果，系统设计只是架构师或者带头程序员的工作，优秀的系统设计必须经由良好的项目管理和团队努力，经过分析需求、设计、开发、测试、分发、维护，以及迭代或重构的过程。中间哪个环节出了问题，再好的设计都将功亏一篑。
可能每个人都对自己设计的系统很自信很满意，但“实践是检验真理的唯一标准”。如果一个系统设计经过实践证明，大家(指客户或用户)公认为优秀的系统，那就是一个优秀的系统设计。
大道至简，适合的就是最好的。其实设计并没有那么严重，适合的就是最好的，简单最好。软件也是一种服务，这个系统设计出来就是为了服务一些用户还没有被满足的需求，如果你能够恰好满足了这些没有被满足的需求，而且能以比较低的代价提供这种服务，那这就是最好的系统。因为系统设计的来源是商业需求，而商业追求利益最大化。你的软件和服务必须比别人功能更加先进，更加好用，对变化的商业 需求反应更加灵活，推出或者升级的速度更快，开发和维护成本更低，才能证明这个系统设计的优秀性。所以系统简单，不能说明你的系统不优秀，说不定设计者有化繁为简的过人能力；系统复杂，功能繁多，也不能说明系统优秀。
技术人员常常犯的错误是技术至上，技术第一，不计成本的去设计和开发无比先进和灵活的系统，不计风险的去采用最新的没经过实用的新技术。所以作为架构师，不仅仅需要精通技术，更需要良好的沟通协调，去了解业务和客户真正的需求，真正站在客户利益角度和最终用户利益角度思考问题和设计系统，在各种选择中做出权衡。
极限编程人士的一个响亮的口号是“You aren't going to need it”。这其中包含的核心意义就是不要为了考虑程序的可扩展性，把目前不需要的功能加入到软件中来。不要过度设计。抓住重点，合适就好。比如根据二八原则，80%的用户只会使用20%的功能，而这20%的功能就是客户最关注的最需要的功能，也就是软件或服务的“卖点“，系统设计时必须集中精力和充分考虑到这部分需求。如果把精力放在某些花哨的功能上，既不 重要，也没必要，那就是过度设计。要想避免过度设计，我觉得可以遵循敏捷开发方式来做。尽可能的简单设计，当满足不了时，重构；保证产品是可运行的，不断的加入新的特征；产品经常性的提交给客户使用。
