系统架构师-基础到企业应用架构-单机软件架构

开篇

       系统架构的文章系列，也是搁浅的太久了，最近也是整理了下思路，将目前未完成的内容，写完吧，也不能拖太久，就不太好了。所以就趁周末写一下，今天我

们要说的是单机应用，单击应用软件可以很复杂，也可以很简单。有些单机软件可以没有数据库，也可以有数据库，比如我们平时的一些工具类的软件，写字板，V

S开发工具等，当然，目前很多的单机软件都有联网的功能，单机软件，估计大家有时候回想，单机软件不需要什么特殊的架构设计吧，其实不然，因为有的时候我

们的单机工具，可能是提供给不同的用户群体等，或者是面向不同的人员使用时，适应不同的场景和需求的变化时，就会要求我们的单机软件也需要从架构的角度去

考虑。因为如果想要可持续发展，那么一个软件或者工具不管是单机软件还是联机软件都需要考虑。

 

大纲

       1、开篇

       2、大纲

       3、单机软件的定义

       4、单机软件架构

       5、关于开发出来的单机软件说明

单机软件的定义

        虽然目前互联网很盛行，但是还是有很多的软件我们目前在使用，当然也有很多的软件，他们能够连上互联网，这样的软件不能算作是单机软件。单机软件的广

泛可理解的定义：可以在不通过互联网或者联机的情况下即可运行的软件或系统，称之为单机软件或单机系统。

        比如说我本机的很多应用就是单机版的。

       

        这些本身就能完成自主的功能，不需要联网，也不需要与其他的计算机交互即可完成功能，相当于功能是自治的，这样的软件我们就认为是单机软件。

        我之前也是做过不少的小工具，比如我们做一个winfrom的小工具，完成文本字符串的替换，或者自己开发的易用的小工具，都可以看作是一个建议的单机软件。

VS在某种情况下，我们也称之为功能强大的单机软件。下面我们将会结合我们这次的主角来说明架构设计的必要性。我们这里以AgileEAS.NET平台中的界面设计器

来说明。界面设计器本身就是一个非常独立的可以运行的工具，根据AgileEAS.NET平台的数据模型设计器产生的模型文件来生成界面模型。

单机软件的架构设计

        单机软件一般都是比较简单的，那么从架构设计的角度来说，一般就是在逻辑架构上的要求比较高，物理架构的架构要求几乎为0，当然可能因为未来适应市场

的变化，可能需要单机软件实现局域网或者互联网的信息共享或者互联网应用集成，这时候就需要考虑更高层次的架构，当然我们设计时也需要考虑这方面的因素，

但是我们本篇就从简单的架构说开了去，来说明如何适应这样的变化。

        1、我们刚开的系统架构的设计可能是这样的。系统架构都是需求驱使的，因为一开始需求很简单。例如一开始客户要求我开发一个简单的界面设计器，没有什

么要求，就要求我能够实现简单的拖拽功能。

        我根据要求分析出如下的结构：

       

        通过分层来实现，将通用的拖拽的基础组件等放在基础组件层，同时将开发设计拖拽页面相关的的配置页面放在设计视图层中。

        2、后来，又来了一个需求，说是要能通过向导来生成页面的设计视图，那么此时我想了下，有将系统架构修改成如下：

        这时候需要添加一个新的层，该层负责添加所有的向导页面，然后设计器视图层根据配置来加载界面的组件元素。这时候系统架构如下：

       

        3、再后来，随着需求的变化，有要求可以生成代码，输出winfrom页面代码，要求拖拽页面看到的什么样的界面，要求输出的winfrom界面的代码与设计器看到的

可视化界面相同，这时候我的架构设计如下。

       

        4、通过上面的架构设计，我发现，后续的需求又来了，不过这次我通过设计，已经可以对付这次的需求了，这次的需求变化是，要求支持多种页面表现风格。

        比如，在设计器视图，设计一次，即可生成winfrom的同样的页面，web的页面也布局类似，同事可以支持silverlight和WPF。

        这样的话，不需要进行大的架构重构，只需要修改CodeDOM层中，将原来的设计器视

图调用的代码生成，换成接口调用的方式来解耦，后续如果需要新增，只需要实现接口即可。

        5、这时候又来了新的需求了，想要让工具与原来的其他工具之间集成，例如将AgileEAS.NET平台中的数据模型设计器产生的sdm文件进行集成，支持打开和保存

功能。将设计后的界面模型文件存储到sdm文件中，这是如何处理。

        、

        6、最终差不多算是告一段落了，后续可能还会有新的需求，可能会要求我把单机工具修改为联网软件，或者是设计的界面保存到数据库中，实现应用部署的动

态变更单等，都是非常可能的需求，这时候，可能我的架构有需要发生变化了。

       

       7、未来要求在互联网进行动态的更新该软件，支持软件的智能升级。

      

 

单机软件架构说明

            即便是今天，复杂的单机系统也有很多，它们大多都是专业领域的产品，如CAD/CAM领域的CATIA、ProEngineer，Autodesk的AutoCAD，还有我们熟悉的Photo

shop、CoralDraw，等等（这些系统的高级版本可能提供了一些网络化的功能，但改变不了其单机系统的实质）。

所以这里笔者要说的是，软件架构复杂并不代表软件系统复杂，其实，软件架构设计较为重要的领域只有一个，那就是信息系统领域，即以数据处理（数据存储，传

输，安全，查询，展示等）为核心的软件系统。其他行业的软件应用对该概念其实并不是那么强调。

              微软的.NET的架构图

             

关于单机软件的说明

        比如，上述我们说明的内容，我们下面来演示下该软件工具具有的功能和设计思路。

        1、主界面：

       

        支持打开.sdm文件：

        这时候，我们选择基于AgileEAS.NET中的ORM数据模型设计器产生的解决方案文件，这样

可以实现界面设计器与数据模型设计器的集成和统一，也方便开发人员使用。当然后续可能将工具功能集成到一个控制台中也是可能的。

        所以我们在架构设计的过程中需要考虑，后续的可能的需求，但是我们不能过分的考虑扩展性，因为需求的变化，我们不能预见100%，所以我们只能做到尽可

能的适应变化，据统计，系统架构师所考虑的扩展性，20%的几率在实际的项目中使用到，80%的扩展性的设计，并没有使用到，所以一句话，具体问题具体分析。

        然后就是生成解决方案：

        选择“生成解决方案”出现如下选择页面：

        

         直接将界面设计器的模型文件来生成解决方案。

         通过不断的需求的加入和架构设计的不断扩展，来满足日益变化的需求。这一切都决定了架构的设计成败。

 

更多

         比如我们平时常用的VS2010开发工具，我们可以见证该工具的强大和灵活的设计，强大的扩展性，都和它的架构和设计不无关系，vs通过插件可以扩充很多强

大的功能，vs还支持项目模板的开发，提高开发速度。这些都是我们在设计单机软件工具时应该考虑的问题，当然前提是你做的单机软件工具是为了解决某项问题，

并且能够适应日益的发展变化，当然有些工具，我们不需要过度的设计，过度的设计往往效果并不明显，不要让我们的设计因为不可能出现的80%而造成过度臃肿的

设计，这样的设计反而是失败的设计，这样的例子太多了，我原来也是想的设计的越低耦合，扩展性越强越好，发现实际的项目中并不是这样的。

        一桶水，是有限的，刚刚好最好。

相关信息

       关于更多的系统架构方面的知识，我已建立了交流群，相关资料会第一时间在群里分享，欢迎大家入群互相学习交流：

       微信群：（扫码入群-名额有限）