1。软件架构设计的生命周期1.软件开发过程2.关于套路3.先刚性，后优化，再固化4.佛说：知我言，如筏2.需求调研与需求分析1.功能需求2.质量属性3.条件约束4.画用例图5.写用例描述6.确定关键需求1.软件架构设计生命周期什么是架构？如果你问十个人，你可能会得到十一个不同的答案；如果你翻阅相关的书籍，每本都可能给出不同的定义。所以，我们不必执着于那些概念，只要方法对了，能完成项目任务，黑猫白猫无所谓，能抓到老鼠就是了一只好猫！一、软件开发流程一个软件项目，从立项开始到最终交付要经历很多环节。具体到软件设计的生命周期，可以包括这些阶段：需求研究-需求分析-概要设计-详细设计-架构验证-开发-单元测试-集成测试。上面的步骤还是很粗略的概念。在实际操作中，每个步骤又可以细分为很多具体的执行环节。例如：需求调研：应该怎么做？应该用什么方法？指导思想是什么？有什么好的工具？需求分析：应该怎么分析？是否应该分析所有需求？软件工程中比较实用的方法有哪些？如何分层？如何划分模块？这些都是软件设计过程中需要涉及的问题。那么软件设计的最终目标是什么？这些是以下文件：逻辑架构；物理架构；操作架构；开发架构；领域，任何行业。当我们进入一个新的领域，比如：让你设计一个车辆调度系统，一个机器人控制系统，或者设计一个对讲机，一个物联网网关，如果你刚接触这个领域，那你肯定蒙着眼睛：我我不完全不懂这个领域，怎么设计？这让我想起了一个小故事：有一次我刚进了一家新公司，接手了一位前同事的工作。当时进行了KPI考核，bug通过率（即一次解决bug的比例，QA人员不会再给你踢bug）是一个重要的指标。面对系统这么多的bug，领导问我：你要花多长时间解决这些问题？我说：我以前没有接触过这种工作，所以不能给出一个准确的时间。领导说：没关系，先给我一个具体的时间。我当时傻眼了。这时，最重要的是快速了解和掌握该领域的基础和重要背景知识。那么我们应该怎么做呢？找规律！不要贪图一切，也不要指望掌握所有相关内容，那是不可能的，尤其是在短时间内。我们的目标是做好工作，完成项目。这时候，我一般的做法是：找套路！这么说可能有点虚幻，那我们就以软件开发中的架构设计为例。在有关软件工程或项目管理的书籍和资料中找到以下相关内容：其他人如何设计架构？设计过程中需要哪些步骤？在每一步中，输入是什么？输出是什么？在每一步中，需要考虑哪些要点？有什么好的软件工具？如何与项目相关人员（项目经理、开发人员、测试人员、甲方客户）沟通？梳理完上面别人的经验，我们可以总结出一套适合自己的“方法论”，然后在具体实施时按照这个套路一步一步来，根据实际情况适时动态调整。一般来说，你可以顺利推进一个项目。3、先整脊，再优化，再固化。这九个字是华为领导人任正非在介绍管理体制时提出的。这是一个非常实用的方法。僵化：站在巨人的肩膀上：学习初期“削足适履”；优化：掌握自我批评的武器：在实践中不断吸收、完善、创新、优化自己；凝固：创新是阶段性的、有限制的，如果没有限制，创新就是混乱无序的创新。需要像夯土一样，一层层夯实，一步步固化阶段性优化成果；对于软件架构设计，我们也可以按照这些步骤进行。第一步是要死板，也就是要有固定的套路。虽然可能会“落入俗套”，但至少可以保证自己走在正确的道路上，不会误入歧途。这是最重要的！如果别人觉得是“落入俗套”，那又是什么意思呢？意味着别人已经认为你的做法符合这个领域最“通用”的工作流程，相当于承认你真的进入了这个领域，这是好事！作为一个初学者，被别人这样评价，难道不应该感到自豪吗？毕竟我们心里都清楚：我只是一个刚刚进入这个领域的新手。4、佛言：“知我言如筏”。写这篇文章的目的，主要是想谈谈我是如何“死板”地设计软件架构的。我们刚进入软件开发行业的时候，日常工作主要是编码，可能还不够资格设计整个系统架构。但这并不妨碍我们主动自学。机会是留给有准备的人的。如果有一天，项目组的架构设计出了坑，领导会找哪个胡萝卜来填坑？因此，本文主要介绍最初级、最基本的软件设计步骤，以及每个步骤中使用的指导思想和得心应手的工具。如果你已经是高级软件设计工程师，可以喝杯咖啡，享受生活。当然，你也可以分享你的方法论，我们可以互相学习！这些内容不是我自己找的，而是在项目开发过程中通过看书，查资料，总结，比较适合我所面临的项目，我只是一个知识的搬运工。之前主要是参考了几本软件架构设计方面的书籍，相互借鉴，总结出一套适合自己的方法。上次搬家丢了很多书，电脑里只剩下零碎的笔记。本文的素材来源就是这些笔记。当然，大部分内容都来自书本，我只是做了一些选择和删减。《金刚经》第六回，如来常言：诸比丘，汝知我法，比喻如筏，法当弃绝，何况非法。佛法就像渡河的木筏。你应该把木筏扔掉，不要再在脑海里想木筏了。筏如法，法当弃，何况是非法之物，何必还愁。所以我这里说的设计套路也类似于一个木筏，在你刚进入软件架构设计的时候，作为一个脚手架来帮助你。当你进入第二层“优化”时，你可以把这个脚手架扔掉。到时候，你就可以自信地说：“刀哥在写东西，小儿科，我要往更高级的方向探索。”此时，我向您表示由衷的祝贺！2.需求调研与需求分析大多数人认同“需求决定架构”，但需求如何决定架构呢？这部分先说说我的认识吧。在立项阶段，运气好的话，说不定还能拿到文档《软件功能需求规格书》（日本某公司的需求说明书真是异常详细）。如果运气不好，没有文件，所有的要求都需要自己收集整理。从狭义上讲，需求是功能；广义上还包括质量属性、条件约束等非功能性需求。1.功能需求功能需求部分是最直观的，也是我们设计的软件需要完成的。在一个系统中，各种功能之间不可能有明确的界限。各个小模块之间通过一定的交互作用，形成“协作链”，完成指定的功能。比如下图是我之前写的一篇文章：物联网网关开发：基于MQTT消息总线的设计流程（上），不同模块之间的交互模型，红色和蓝色部分是2条不同的Collaboration链。当然，这张图是最终设计的系统架构（分层，分模块）。在拿到这张图之前，我们首先要收集整理所有的功能需求。在这个阶段，最重要的是做什么，而不是怎么做。另外，作为设计师，需要时刻问自己一个问题：所有的需求都掌握了吗？有没有遗漏？2.质量属性我们可以根据不同的阶段对质量需求进行分类：开发阶段的可重用性，不要做重复的工作；灵活、易于扩展（想想开发人员在发生需求变化时的心理活动）；易于理解（当你接手别人的项目时想想）；易于测试（单元测试、集成测试）；可移植（尤其是嵌入式项目需要在不同平台上运行）；系统在运行阶段必须是可靠的；性能必须满足一定的要求（吞吐量、响应时间等）；无漏洞，系统安全；可扩展性好，易于扩展部署；3.ConditionalConstraintsConstraints主要是指一些限制条件，比如：团队成员的技术栈（如果大家都用C，就不要选C++）；领导者提供了哪些资源；如果使用一些开源软件，是否有bug？方便二次开发吗？项目开发周期有多长？软件的运行平台有哪些？有什么限制？4.画出用例图。A：用例图是用来描述由参与者（Actor）、用例（UseCase）、边界以及它们之间的关系组成的系统功能的视图。用例图（UserCase）是系统功能的模型图，可以被外部用户（称为参与者）观察到。用例图是系统的蓝图。用例图展示了一些参与者、一些用例以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。这里面有几个概念：Actor：不是具体的一个人，而是在系统之外，扮演着使用系统或者与系统交互的角色。用例：是对一系列动作的描述，包括变量，系统执行这些动作以产生可观察的结果，为特定的参与者传递价值。系统边界：用于表示被建模系统的边界。边界的内部代表系统的组件，边界的外部代表系统的外部。箭头：用于指示通过向彼此发送信号或消息进行交互的参与者和系统之间的关联。作用：（1）获取需求；(2)导向测试；(3)在整个过程中还可以对其他工作流程起到指导作用。从网上找了几个用例图，里面每个圆圈代表一个功能。通过用例图，你可以一目了然地看到系统提供的所有功能。5.写用例描述但用例图没有详细描述每个用例的执行过程，也就是说：用例图描述了系统整体的需求，但没有描述行为过程。因此，我们可以为每个用例附加一个简单或详细的用例描述，从而更具体地确认这个用例的行为过程。下面也是在网上找到的两个用例描述的例子。可见，没有统一的格式，需要根据项目性质增减。6.确定关键需求假设我们在不断的收集分析中已经尽可能的列出了所有的需求（功能需求、质量属性、条件约束），接下来我们应该做什么？要求那么多，应该从哪一个入手呢？要求呢？关键需求=关键功能+关键品质。它定义了架构的总体方向。首先，让我们明确一点：并非所有需求都是平等的。我们需要从众多用例中找出以下三类需求：关键功能需求：涉及模块最多、模块间协作最具代表性的功能，并从中选择关键功能的子集；关键质量属性：在开发和运行阶段，哪些质量属性对软件架构的影响较大，如果质量属性之间存在冲突，应该优先考虑哪个？高风险部分：从技术难度来看，哪些功能在技术实现上存在风险，需要提前经历技术验证？这三类需求是我们需要关注的需求，也是下一步（领域建模）的输入素材。本文转载自微信?“IOT物联网小镇”，可通过以下二维码关注。转载本文请联系物联网小镇。
