「软件分析」与「软件设计」这样的词眼经常听到，然而要真正理解「软件分析」和「软件设计」的本质是比较难的，本文带你了解软件分析与设计的「逻辑性」到底是什么。
一、系统分析与设计的逻辑性框架
在日常的工作中，「软件分析」与「软件设计」这样的词眼经常听到，然而要真正理解「软件分析」和「软件设计」的本质是比较难的，它依赖极强的工作经验，又加上软件分析与设计没有标准的程式化步骤，导致不同的人有自己不同的方法，也就造成了很多人认为软件分析与设计是非常「空洞」，还不如写具体的代码实在，而大部分的人写的是业务型代码，被嘲弄写CRUD的代码没成就感。
1.1方法
1.1.1分析阶段
软件分析与设计并没有那么神秘，本质来讲还是为了解决现实的问题，和「医生看病」、「工人修车」、「厨师做菜」一样的，都需要方法作为指导，否则没有任何头绪，只能抓瞎。方法是具有普适性，只是不同的行业有各自的特性，具体落地上有差异。
既然是要解决问题，那么总得知道问题是什么吧，就好比医生看病，做各种检查、化验，都是为了全面地了解疾病，所以第一步是需要定义好问题，然而当下很多人都忽略了这一步，直接上来想我要用哪种中间件、哪个框架，连问题都没有定义好，直接想实现无疑是本末倒置。
问题是理想与实现差距的矛盾，现实是不满足理想的诉求，因此，首先需要了解用户的诉求是什么，想解决怎样的问题，这也即为是需求。需求分析最大的挑战是什么是真正想要的，就好比一个病人说了一大堆的症状，他所说的症状表现与书本上的描述有时是有出入的，定义出真正的需求至关重要，接下来就要思考通过怎样的方法去梳理清楚用户需求。
用例只是一个概括的描述，因此还需要细化，一个用例包括一个或多个场景，场景是参与者与系统之间的活动和交互，比如用户下单，有下单成功，有下单失败两个场景。因此到这里还只是分析阶段，分析的目的是了解现状和目标，以及系统要素组成，它不关心如何实现做、如何实现。分析不仅限于软件行业，其它的行业也是如此，只是在分析过程的程式化步骤、方法不一样而已。
1.1.2设计阶段
当我们清楚地知道要做什么之后，接下来要思考如何去实现，实现的途径有很多种，如同一百个厨师做同样的菜，做出来的效果不一样。设计阶段有两点需要考虑的：一是如何将功能细化实现；另一点是如何更好地实现。第一点不管用什么方法都可以实现，难的是第二点，更好地实现是需要遵循一些章法，也需要评判体系，要不然你怎么知道好与不好呢，常见的定量评判指标有：成本、性能、可靠性、效率等，还有一类是定性的评判指标有：开放性、体验性等。
度量的指标相对容易，就像医生看病，看疗效、看成本，软件设计也是一样，归根到底是「多快好省」。然而软件设计的章法就复杂得多，它具有很强的艺术性，正所谓「文无第一，武无第二」，比武一定可以比出个高下，谁打赢了就是胜利一方，然而比文就难了，不能说你写的就一定比我写的好，只是不同人的喜好不一样而已，当然这里指的旗鼓相当地对比，不同层次的对比一眼还是能看得出来的。
在设计阶段最为关键的是定义出「关键的技术问题」，一般分类两类：一是站在用户视角的设计，它重点考量的是「便捷性」和「易理解」；另一个是站在系统层面，重点考量的是「复用性」、「扩展性」和「稳定性」。贴近用户的设计，让用户用最少的理解就能使用它，用户无须感知底层复杂的设计，核心是回答用户最朴素的原始诉求。系统层面的设计要灵活，多用组合正交设计提升系统的复用性和扩展性，在具体方案设计中要考虑到稳定性因素，比如写日志会带来性能问题，这个在方案设计中就要考虑到。洞察到关键技术问题，并非一朝一夕就能练就成，需要在工作中大量地实践，总结经验，保持技术的敏感度才行，在第二节中通过实际的案例方便大家加深理解。
1.2工具
有了方法，接下来要有工具来帮我们更好地做事，与方法对应的，我们软件设计的工具是UML，接下来介绍UML中常用的图。
1.2.1活动图
软件从本质上是在模拟现实业务运行的过程，是由一个个交互活动组成的，因此，在分析阶段需要梳理出业务的活动是怎样的，通过图形的方式记录下来。
活动图要体现出「参与者」、「活动起点」、「活动关键路径」、「活动终点」，比如用户下单，有「浏览」、「加购」、「支付」等活动。通过活动图可以看出业务的生命周期是怎样的，能够抓住业务的关键流程。
1.2.2用例图
用例图是强调用户的目标和观点，是文本化的情节描述，用例从本质上讲并不是图，它是文本，用图形是简化了表达形式，它核心有三点：「参与者」、「要做什么」、「结果是怎样的」。用例图是对活动图的细化，对其中的一个活动定义出要实现怎样的目标。场景又是对用例图的细化，你会发现，从目标到实现，一步一步地细化下来，细化是对扩大对认识的理解，不在认识范围内，也就不会去做。
1.2.3顺序图
将场景通过顺序图表达出来，它核心强调的是系统应该提供怎样的能力，注意顺序图与时序图的区别，顺序图是人与系统的交互，它想表达的是系统应该提供怎样的能力满足用户的诉求，而时序图系统内部实现，强调的是如何实现这种能力。
其实到顺序图这一步，基本上系统要提供的能力就清楚了，当然，这里是知道系统要做什么，至于要怎么实现它并不关心。以上我认为它是分析阶段，把用户想实现的内容清楚地定义出来，接下来就是思考怎么实现。
1.2.4时序图
时序图有两种作用：一是表达功能是如何实现的；另一个是看责任分配是否合理。第一点比较好理解，一个功能实现是由多个不同的对象组合来实现，对象间有交互依赖。第二点是评判对象设计是否合理，如何两个对象频繁交互，是不是可以合并在一起，如何一对象中的操作过多，是不是可以拆解。
1.2.5类图
类图的作用也有两种：一是表达属性和职责；另一个是层次结构。类中的属性和职责是一个统一体，属性体现的是认知能力，职责体现的是行为能力，拥有怎样的认识，就会产生怎样的行为。类不是一个孤零零的个体，它与其它的类之间有依赖、协作关系，因此，类图中体现继承、依赖、泛化、包含等关系。
1.3原则篇
软件设计原则汗牛充栋，简化下来就三点：「复用」、「变化」、「认知复杂度」，好的设计处处体现设计原则，把这些原则刻画到骨子里，而不是刻意体现，如同「没有规矩不成方圆」一样，重点是要理解为什么要这些原则，从本质上讲是为了软件能够「多快好省」地完成。
利润=收入-成本，从这个公式中，很明显我们想要实现利润最大化，怎么办呢，有两个方法：一是收入变多，最好地方式是实现规模化；二是成本降低，不需要或者很少投入成本。从这两点中，引申出「复用」和「变化」两个原则，复用是不投入或者少投入实现功能，相比从头做是不是要节省成本呢，我们的产品不可能一成不变的，那么变化是在所难免的，如果能支撑灵活地扩展是不是也能节省成本呢。
1.3.1复用
从上面的分析看，「复用性」的重要程度不言而喻，比起烟囱式开发，复用的成本要低得多，所以产生出了xx平台、xx中台，它们的本质目的还是为了复用，减少重复开发成本。实现复用的手段有很多，复用的程度也不一样，这个就要靠平时的积累，就像医生积累「药」和「药方」一样，这些都是我们解决问题的「工具」。先要有复用的思维，否则只有工具也是无用的，不知道要怎么用、在哪里用。
不同的场景，复用采用的设计方法是不一样的，举几个例子方便大家理解。
完全复用
最简单的复用是100%的复用，比如加法计算操作，它肯定是100%复用的，只用传输不同的数字进去，就可以计算出结果。一般完全复用的是工具型的能力，它与具体的业务语义无关。
配置化复用
部分复用
然而，在实现世界中，没有太多像完全复用的事情，如果变化还不能通过配置化来实现，可以使用「模板方法」或「策略模式」，将变化延迟到子类中去实现，这种方法在大家日常工作很常见，也有的使用SPI扩展点实现。这一类复用场景是有明确的「主流程」，只有少量的变化随业务变化，变化也是可枚举的，那么就可以抽象出扩展点。
完全不能复用
1.3.2变化
复用和变化是一起出来的，软件唯一不变的是变化，怎么支撑未来更好地扩展是我们要思考的，如果一个功能千年不变，怎么简单就怎么实现，而如果有变化的话，那就需要好好地设计，用最少的成本去支撑未来的变化。比较难的是要洞察出什么在变化，这个还真不是那么好想到的，需要有行业经验积累，看多了、实践多了，会发现里面的一些门道。
举一个应对变化的例子，税务在计税时，不同的业务计税规则不一样，有的金本位要计税，有的不需要计税，有的非金本位要计税，有的不需要。如果放在一个大的扩展点中实现，那么这就是典型的面向过程的设计思维，我们抽象出了「计税表达式」这个实体来应对变化，「计税项」要不要计税、计税口径是怎样的，新业务接入通过「配置化」来解决。
1.3.3认识复杂度
类的设计也是一样的，举一个例子，税务在开发票时，开票这个模型结构需要调用者感知吗，肯定不需要，因为发票中有很多的领域概念，如开票主体、发票行等，用户的目的就是开一张发票，他只用告诉你他知道的信息，不关心你内部要怎么实现，基于这个思考，我们抽象出了「开票申请」这个实体出来，它本质是贴近业务场景的实体，所包含的信息也是有限的，极大地降低了认知复杂度。
二、系统分析与设计的2个案例
2.1日志框架
2.1.1日志框架分析
根据上面的分析，我们很快可以画出日志的概念模型，如下图所示。从本质上讲，我们是将日志信息存储到指定的地方，如存储文件中，输出到控制台上，另外还有日志存储的格式可以有多种，比如普通的格式，还有XML、HTML的格式等。
从概念模型上看，设计一个日志框架并不复杂，但在设计阶段中，还需要挖掘更多的信息，我们输入的信息更多，设计时考虑的因素也就越全，更能满足用户的诉求。
2.1.1日志框架设计2.1.1.1贴近用户的设计
2.1.1.1系统视角的设计
按照这个设计，很快可以设计出一个简易的日志框架，代码结构如下所示。
Appender类如下所示，它定义的是一个模板方法，先调用LayoutPattern获取格式化的日志数据，然后再输出到目标存储上，Appender和LayoutPattern是可以独立变化的，同时将写操作延迟到子类中实现。
再细细想一下，日志本身是为了方便排查问题，但额外日志的存储是有性能开销的，这个在设计时就要着重考虑了。如何减少写日志带来的性能开销呢，从三个方面考虑：
内存映射写文件：传统的IO写数据，操作系统需要从用户态切换到内核态，性能开销会很大，可以使用内存映射的方式写文件，提升IO性能。
同步变异步写文件：同步写文件是需要等文件写好了后再往下执行业务代码，而异步就不一样，它将日志记录存储在一个队列中，开户另一个线程慢慢写到文件中，不阻塞业务逻辑执行。
通过上面的分析，一个简单的日志框架随着对它的理解加深，设计方案也在变化，核心是要能看到关键的技术问题有哪些，能提供哪些增量价值或差异化的价值。
2.2定时任务框架
2.2.1定时任务框架分析
2.2.2定时任务框架设计2.2.2.1贴近用户的设计
站在用户视角，他关心的有三点：
任务要按照怎样的规范去编写，因此需要一个概念「Job」去表达，它定义了一个execute()接口。
任务如何提交，需要一个门面类「Scheduler」去表达，接受用户提交的任务。
2.2.2.2系统视角的设计
站在系统的视角，很快能想到解决方法，用户提交任务后要保存至一个队列中「JobQueue」，「JobQueue」中存储的是「JobDetail」，「JobQueue」包含了「Job」和「Trigger」两部分信息，然后有一个调度线程「SchedulerThread」不断扫描「JobQueue」，判断当前任务是否要被执行，如果需要执行就调用「Job」的execute()方法，类的概念模型如下图所示。
按照这个设计，很快可以设计出一个简易的任务调度框架，代码结构如下所示。
这还是一个简单的任务调度框架，还有很多问题没有考虑到，比如任务分片、分布式定时任务等，还是回到需求分析上，我们要做的功能边界是什么，目标是什么，再去设计对应的解决方案。
三、总结
在日常技术方案设计时，最为关键的是要能定义出关键的技术问题，有两类问题是我们要着重考虑的：一是贴近用户视角的便捷性设计，主要是对业务概念的抽象，用户以最小的知识感知系统；另一个是系统的视角设计，除了完成功能外，还要定义出关键的技术问题以及度量的方法，如打印日志带来的系统开销，怎么做到对系统产生最小的影响；定时任务调度的调度算法设计，选用不同的数据结构的效果是不一样的，普通的排序算法没有堆排序算法好，但堆排序同样涉及到性能开销，这就让我们不断想更好地方案去解决。