本文由 千趣源码 – qianqu 发布，转载请注明出处，如有问题请联系我们！系统分析模式的特点-教学设计的系统分析模式

商业数据分析和设计方法。

现阶段，客户的需求量愈来愈繁杂，转变迅速。如果我们依然根据需求管理，需求跟踪等管理方案来限定和降低经常转变的5201;求对软件产品的危害，开发软件全过程会显得肌肉僵硬，程序猿会显得更为疲倦。

除此之外，客户的要求一般来源于某一专业领域，如法律法规，金融业或方式等，每一个重要的要求都是有其独特的多元性，因而基本上没人可以第一时间把握这种专业领域要求的实质。因而，客户的要求通过几回演变后早已变成遍体鳞伤，每一个“生产加工生产制造阶段”都觉得自身在做“恰当的事儿”。在具体工作上，这类状况会反复发生。例如产品运营在宣传教育商品需求分析文档(PRD)时，必须用简单的业务流程语言表达向业务员“汉语翻译”专业名词，用技术性语言表达向开发者“汉语翻译”专业名词，非常容易造成多方接到的消息不公平，业务员和专业技术人员的看法很有可能不一致。

因而，智能化技术工程师引进了灵便的面向对象分析和设计方案(OOAD)方式。面向对象分析设计方案处理繁杂要求的办法是让模型权威专家对要求开展剖析，创建要求中间的关联。

注:面向对象编程的剖析与设计方案分成结构化分析和控制系统设计两一部分。也有2个职业资格考试:“系统分析师”和“系统软件室内设计师”。这类切分的结论是需求分析报告的結果不可以立即设计方案和程序编写，能够运作的编码与市场需求不配对。結果顾客运作手机软件后发觉许多作用都没有自身愿意的，手机软件没法迅速紧跟消费需求的转变。

尽管面向对象编程的解析和设计方案观念给剖析和设计方案产生了4040;大的协调能力，对开发软件造成了空前的危害，但它也是有一定的局限:面向对象编程的解析和设计方案关键偏重于外部经济层级的抽象性，如类和对象案例；针对一个难题行业，一般必须建设一个独立的测试用例分析法。在很多状况下，新项目或设备的方向越来越很模糊不清，难以全局性自动控制系统的目标。因而，这类结构化分析和设计方法具备较大的风险性。

面向对象分析与设计方案的局限激发了针对服务项目的剖析与设计方案(SOAD)方式，合理地填补了面向对象分析与设计方案的局限。此外，朝向服务项目构架(SOA)也进入了大家的视线，快速兴起。

朝向服务项目剖析与设计方案并非一种最新的剖析与设计方案方法，只不过是是以不一样的抽象性视角去设计方案一种业务模型。面向对象分析与制作能够算是一种自底向顶的制定方法，尽管面向对象编程的方式相比面向对象方法的方式拥有非常大的改善，可是在应对错综复杂的需求时，面向对象分析与设计方案就看起来困窘了，这时就必须从更多的层级溶解市场的需求，朝向服务项目剖析与设计方案应时而生。在做朝向服务项目剖析与设计方案时选用自顶向底的设计方法，最先要分离出来出工作流程和服务项目，随后优化目标。面向对象分析与设计方案与朝向服务项目剖析与设计方案的抽象性关联如图所示3.16所显示。朝向服务项目的解析和设计方案并不是一种最新的解析和设计方法，反而是从不一样抽象性视角设计方案的商业运营模式。面向对象编程的解析和设计方案能够算是一种自上而下的设计方法。尽管面向对象编程的方式对比面向对象方法的方式拥有非常大的改善，可是当面临错综复杂的需求时，面向对象编程的解析和设计方案便会困窘。这时候必须从更多的方面溶解市场的需求，朝向服务项目的解析设计方案应时而生。朝向服务项目的解析和设计方案将选用自顶向下的设计方法。最先，工作流程和服务项目应当分离，随后目标应当优化。面向对象分析与设计方案和朝向服务项目剖析与设计方案中间的抽象性关联如图所示3.16所显示。

图3.16。

那麼，朝向服务项目的解析和设计方案是较好的吗？它的局限是啥？

大家都知道，开发软件的步骤一般为要求，剖析，设计方案，开发设计，检测和交货。无论是在面向对象分析与设计方案中或是在朝向服务项目剖析与设计方案中，对结构化分析和设计方案全是单独的，隔断的，即剖析工作人员从行业中搜集基本上的业务流程定义，控制系统设计工作人员再将基本上的业务流程定义投射为对应的编程工具的结构部件。在这个环节中，因为分析法和模型设计不一样，在解析和设计方案中间产生一条差距，如图所示3.17所显示。大家都知道，开发软件的全过程一般是要求，剖析，设计方案，开发设计，检测和交货。不论是面向对象编程的剖析与设计方案，或是朝向服务项目的剖析与设计方案，结构化分析与设计方案全是分离出来的，泛娱乐化的，即剖析工作人员从行业中搜集基本上的业务流程定义，控制系统设计工作人员将基本上的业务流程定义投射到相对应编程工具的搭建部件中。在这个环节中，因为分析法和模型设计的不一样，在解析和设计方案中间产生了一个差距，如图所示3.17所显示。

图3.17。

2004年，知名模型权威专家Eric Evans发布了他极具知名度的经典著作《域驱动-设计架构》，在其中提到的域推动设计方案(DDD)方式摆脱了剖析与设计方案分离出来的情况，得出了域实体模型的定义，革除了剖析与设计方案分离出来的作法，应用统一的实体模型来达到剖析与设计方案的要求，使系统软件开发可以更为灵便，迅速地回应市场需求的转变。

留意:DevOps的发生进一步弥补了开发设计和布署中间的空缺。特别注意的是，没什么新的工艺或定义是用空的人想像出來的，反而是致力于处理大家在日常生活和工作时碰到的难题。系统架构师还必须有工作能力发觉系统软件中的情况并得出对应的解决方法。

结构化分析与设计方案的三个发展趋势环节。

大家来谈一谈结构化分析和涉及的三个发展趋势环节。

数据驱动的解析和设计方案。

数据驱动的解析和设计方案是结构化分析和涉及的第一阶段。

软件开发一直从设计方案数据库查询以及字段名逐渐的，这一时期的特点便是紧紧围绕数据库编程，软件系统是非常典型的双层构架，分成展现层和数据库查询层。该时期的经典技术性为Delphi和VB等，如图所示3.18所显示。软件开发一直从设计方案数据库查询以及行业逐渐。这一时期的特征是紧紧围绕数据库编程。软件系统是非常典型的双层构架，分成表明层和数据库查询层。目前典型性的技术性有Delphi和VB，如图所示3.18所显示。

图3.18。

这类数据驱动的解析和设计方法造成了面向对象方法的编程思维。因为数据库查询构造是由DBA设计方案，随后由撰写很多SQL句子的程序猿来完成，而且SQL句子是按序实行的，因此大部分程序猿产生了一种面向对象方法的思维方式，假如长期性产生习惯性，难以更改。

面向对象方法是一种思维模式。应对难题时，大家一般会留意解决困难的流程，也就是全过程。例如怎样把小象放入电冰箱，大家想起下列流程:第一步，开启电冰箱；第二步，运载小象；第三步:关掉电冰箱。这也是一种典型性的面向对象方法的思维模式。尽管它能够更立即合理地解决困难，但当应对更繁杂的难题时，解决困难的流程会越来越比较复杂和难以理解。

一样，数据驱动的解析和设计方案有下列显著的缺陷。

◎不可以迅速，合理，全方位地了解和体现要求。在这类剖析设计创意中，全球不仅是由简易的关系数据构成，反而是用关系型数据库来体现真正要求，这不符人们的当然逻辑思维，是一种歪曲的统计分析方法。

◎系统软件特性无法提高，非常容易造成手机软件运作时负荷集中化在数据库查询端，使系统软件越来越集中，高危Monolithic，丧失分布式系统群集解决工作能力。

◎面向对象编程的开发语言和关系型数据库自身是隔阂的，由于关系型数据库自身的解析和设计方案是面向对象方法的(这类分歧在今天的完成中依然存有，但在领域驱动的制定中有解决方法)。

面向对象编程和朝向服务项目的解析和设计方案。

伴随着系统软件的复杂性愈来愈高，朝向数据驱动剖析与设计室存在的问题也愈来愈显著，因而发生了具备里程碑式的意义的面向对象编程和服务项目剖析与设计的方法，软件系统也变成了經典的三层架构：展现层，领域模型层和信息网络访问层，如图所示3.19所显示。伴随着系统软件复杂性的持续提升，数据驱动的解析设计方案难题也愈来愈显著，因此造成了一种里程碑式的面向对象编程和业务的剖析设计方法，软件系统变成了传统的三层架构:表明层，领域模型层和信息网络访问层，如图所示3.19所显示。

图3.19。

这时单独剖析设计方案有两个阶段，结构化分析设计方案逐渐升高到一个高些的层级，拥有自身的一套科学研究的，造型艺术的科学方法论，但也提供了一个致命性的缺陷:设计阶段和设计不可以有效的对接，导致了难以逾越的差距，由于投资分析师承担从要求行业搜集基本要素， 而设计师则承担强调一组可以融入新项目中编程工具结构的部件，而且这种部件应该可以在总体目标自然环境中合理实行而且可以。

能够看得出，设计阶段和设计的总体目标并不一致:剖析工作人员只关心需求分析报告，而不关心是不是合适设计方案或是能不能导出来合适设计方案的剖析結果；室内设计师发觉剖析結果太简易，没法编号。結果设计阶段和设计没法对接，造成全部新项目不成功。

此外，尽管在设计阶段和设计都应用了UML，可是UML并不是一种观念方式，反而是一种剖析和设计工具。假如把UML比成CAD绘图软件，懂CAD的绘图员是建筑设计师吗？显而易见并不是。因而，UML并不是一颗银弹，都不相当于剖析和设计方法。

朝向难题行业的解析和设计方案。

难题领域模型有一个简单的名字:领域模型，是现实世界或行业中目标的数据可视化表明，可分成数据模型，行业领域模型和剖析领域模型。

Eric Evans 在 2004 年 发 表 了 Domain-Driven Design-Tacklingcomplexity in The Heart of Software的毕业论文，主题风格就是领域驱动设计方案，还明确提出领域模型的分层次构架，将这个软件区划为基础设施建设层，行业层，网络层和客户插口层，如图所示3.20所显示。Eric Evans在2004年发布了一篇《领域驱动设计——解决软件核心的复杂性》的毕业论文，主题风格是领域驱动设计方案，明确提出了一种领域模型的分层次构架，将这个软件区划为基础设施建设层，行业层，网络层和操作界面层，如图所示3.20所显示。

图3.20。

领域建模是一门造型艺术，它融合了设计阶段和设计，目地是使繁杂的手机软件可以迅速解决转变。领域模型适用剖析原形和编程设计。假如一个实体模型在建立的情况下不行得通，那就需要找寻新的实体模型。假如实体模型不可以忠诚地表述行业的重要定义，它还务必找寻新的实体模型。因而，在领域建模全过程中，将设计阶段和设计变成单循环环节，剖析和设计方案紧密相连，促使领域建模权威专家不会再只关心要求定义的搜集，反而是关心编程代码的制定和完成。第3.5 ~ 3.7节将详细介绍面向对象分析与设计方案，朝向服务项目剖析与设计方案，领域驱动设计方案的详尽使用方法。