摘要: 一、上章回顾 上章我们主要讲述了系统设计规范与原则中的具体原则与规范及如何实现满足规范的设计,我们也讲述了通过分离功能点的方式来实现,而在软件开发过程中的具体实现方式简单的分为面向过程与面向对象的开发方式,而目前更多的是面向对象的开发设计方式。并且我们也讲述了该如何通过设计手段去分析功能点及设计分离点,应该如何在设计的过程中分析的角度及如何去满足设计规范与原则。首先我们通过下图来回顾下上章要点:二、摘要 本文将已架构的方式去分析分层结构中的业务层的设计,如何写出来内聚度,高耦合的业务逻辑层,并且如何根据我们的项目中的个功能需要去设计业务层。我们本章将会通过几种可能的业务层的设计模式去分析,并且 阅读全文
posted @ 2013-01-31 15:25 于为 阅读(227) 评论(0) 推荐(0) 编辑
摘要: 一、前言 最近也许是由于假期的原因,我发布的文章的速度变慢了,对大家说下抱歉,这个系列的确我很难写,感谢大家对我的支持和关注,的确我在发布后得到大家的支持和认可,让我有了更多的动力,之前发布的有些内容,可能对各层讲解的内容的广度还不够,当然这和我个人的水平面有关,还请各位多多提出宝贵意见和建议。 从本篇开始,我将会采用更加规范的格式,更严谨的求知态度,更加准确的表达,去将接下来的系列文章写完,并且与群中的很多朋友交流后,他们希望出一个总的PDF电子书,这样可以方便阅读,的确谢谢各位的支持,我目前将以后每篇写的内容,放一份PDF格式的在群共享中,有需要的朋友可以进行相应的下载,由于本人的写作水平 阅读全文
posted @ 2013-01-31 15:24 于为 阅读(292) 评论(0) 推荐(0) 编辑
摘要: 一、上章回顾 上篇我们主要讲解了系统架构中的四种架构模式,并且分析了四种架构模式的实现及应用场景,那么先来回顾下架构中的业务逻辑层的使用及总结。如果大家对图中讲述的内容不明白或者说是不深入那么可以参考上篇讲解的内容:系统架构师-基础到企业应用架构-业务逻辑层。二、摘要 本文将已架构的方式去分析分层结构中的服务层的设计,如何设计出来满足我们说的业务需求及设计规范的服务层将是我们的目标,可能我想大家在项目架构的过程中可能有些同仁,没有用到该层,或者说是采用的是常用的分层结构的设计,而没有把服务层单独的抽出来,当然我们必须首先知道服务层是干什么用的?为什么要单独写一个服务层呢?还有就是设计服务层我们 阅读全文
posted @ 2013-01-31 15:24 于为 阅读(284) 评论(0) 推荐(0) 编辑
摘要: 一、上篇回顾 我们先来回顾下上篇讲解的内容,我们前面的几节分别讲述了,业务逻辑层、数据访问层、服务层、表现层,我们了解了这些分层的职责和分层之间的大概的关联关系,本篇可能主要是简单的介绍下企业应用的几类模式,结合这几个分层直接的交互来完成系统功能的构建。我们还是先对我们学习的四个分层的职责和功能做个大概的回顾,我们先来看看下图来回顾下我们讲述的内容。 我想通过上图,大家能回忆起我们讲述的相关内容,然后整理好自己的思路,我们本文将会针对这几个分层进行相应的模式的讲解,并且会结合实例来说明企业应用架构的简单应用。我想这也是大家关心的内容,我也希望大家能多提出宝贵意见,大家共同提高。 之前说是提供P 阅读全文
posted @ 2013-01-31 15:23 于为 阅读(254) 评论(0) 推荐(0) 编辑
摘要: 一、上章回顾 上章我们主要讲述了系统设计规范与原则中的具体原则与规范。如何实现满足规范的设计,我们也讲述了通过分离功能点的方式来实现,而在软件开发过程中的具体实现方式简单的分为面向过程与面向对象的开发方式,而目前更多的是面向对象的开发设计方式。具体的内容请看下图: 上图描述了软件设计的原则:低耦合,高内聚,并且简单说明了,如何实现这2个原则,通过分离关注点的方式。我们把功能称之为关注点。二、摘要 本文将通过实例来讲解如何通过分离功能点,并且讲解分离关注点实现相应功能点时应该注意的问题。比如说一些相关的重要部分的内容。分离功能点是实现软件功能的一项重要基础,随着软件复杂度的不断提高,传统分离关注 阅读全文
posted @ 2013-01-31 15:14 于为 阅读(146) 评论(0) 推荐(0) 编辑
摘要: 一、上章回顾 上一篇:系统架构师-基础到企业应用架构-系统建模[中篇](下)中我们主要讲解了部署图、活动图,我们在这里也是参考上篇的形式,这里不再详细介绍。上篇主要讲解了下面2类建模图:二、摘要 本文将讲解其他的几个类型的建模图当然只是简单的讲解,并且将结合B2C电子商城系统进行分析通过使用我们已经讲解的建模图为例。分析系统可划分的子功能模块,每个功能模块内部的运行步骤等等。 上面的2个不同类型的进行划分的建模图,本章将对上述6个建模图进行分别举例讲解。三、本章内容 1、上章回顾。 2、摘要。 3、本章内容。 4、结构图。 5、行为图。 6、本章总结。 7、系列进度。 8、下篇预告。四、结构图 阅读全文
posted @ 2013-01-31 15:13 于为 阅读(172) 评论(0) 推荐(0) 编辑
摘要: 一、上章回顾 在上篇中我们讲解了几类UML2.0语言新推出的建模图形,总体来说通过这些图形能更详细的将某类信息表达出来。在这里我们简单回顾上篇讲解的内容。 上图中已经简单介绍了上章讲述的内容,具体内容请看:系统架构师-基础到企业应用架构-系统建模[下篇]。二、摘要 本章将主要的简单介绍在系统架构中的设计模式及相应规范准则。并结合相应的代码来说明如何遵循系统架构中的一些基本的设计规范及准则。而我们将在本文介绍几类常用的设计规范,我们先来看看结构化设计的二个基本原则: 当然既然提出了基本的准则,那么我们如何来满足准则呢,并且能更好的设计呢?我们可以通过如下手段来达到这样的要求:当然图中演示了功能分 阅读全文
posted @ 2013-01-31 15:13 于为 阅读(186) 评论(0) 推荐(0) 编辑
摘要: 一、上章回顾 首先、我们先来回顾下,上篇讲解的内容,加深下印象。上篇我们主要讲解了3个建模图形分别是:顺序图(序列图)、组件图、状态图。 具体功能描述如下图:这里不详细解释,如果不清楚请看:系统架构师-基础到企业应用架构-系统建模[中篇](上) 由于全部放在一篇中篇幅太长了,所以分开讲解。二、摘要 本文主要讲解:UML建模图中的活动图、部署图等 上图中就是本章要讲解的内容,本质将仔细的剖析,部署图与组件图的关系与区别,活动图与状态图的关系与区别。三、本章内容 1、上章回顾。 2、摘要。 3、本章内容。 4、建模中的抽象模型图之部署图、活动图。 5、本章总结。 6、系列进度。 7、下篇预告。四、 阅读全文
posted @ 2013-01-31 15:12 于为 阅读(177) 评论(0) 推荐(0) 编辑
摘要: 一、摘要 本文主要从系统架构中的建模开始讲解,本文讲述的内容主要是我在工作和学习过程中的总结和经验,不足之处还请大家多多批评指出,有更好的建议也可以留言说明。本意主旨是为不熟悉系统架构建模过程和不知道如何使用建模工具,或者不熟悉如何根据需求去建立模型的角度出发,简单的阐述了在系统架构的过程中我们应该从什么样的角度出发去分析需求并且建立抽象模型。这应该说是架构师必备的技能。 本文由浅入深,本篇将简单的介绍如何使用使用UML建模中的各个结构图与行为图,去完成抽象模型的建立。二、本章内容 1、摘要。 2、本章内容。 3、建模工具介绍及使用。 4、建模中的抽象模型图。 5、本质总结。 6、系列进度。 阅读全文
posted @ 2013-01-31 15:11 于为 阅读(189) 评论(0) 推荐(0) 编辑
摘要: 一、上章回顾 上篇文章主要简单的介绍了建模中使用的标准建模语言UML的相关内容,包括用例图与类图的使用方法及如何建模。相信大家对UML建模语言已经有了初步的认识,还请大家谨记UML不同的建模图形的用处。比如,用例图主要用来描述系统的功能需求。类图主要用来描述实体间的关系。谨记这些就可以帮助我们在系统架构的过程中深入的分析。 首先向大家道歉,上篇中有部分描述错误的地方,可能对大家造成一定的错误引导。这是上篇给出的图,我描述的是组合关系。 特别更正为:这是正确的结果。箭头指向聚合类。描述的信息并无任何错误。希望能对大家指正。二、摘要 本文主要从系统架构中的建模开始讲解,本文讲述的内容主要是我在工作 阅读全文
posted @ 2013-01-31 15:11 于为 阅读(161) 评论(0) 推荐(0) 编辑
摘要: 开篇说明 由于是自己对这些技术的学习总结和心得体会,错误之处在所难免,怀着技术交流的心态,现在发表出来,所以希望大家能够多多指点,这样能使一部分人受益同时也能纠正我的错误观点,以便和各位共同提高!软件架构到底是什么 软件架构可以被简单的描述为,一系列组件之间的组合,交互,继承的关系。当然这样的解释基本上人人都可以接收。不过在我们看来,这样的说法有点过于抽象。 软件架构有这标准的定义,就是参考ANSI/IEEE的标准,软件架构可以理解为软件密集型系统中对系统的实现和部署起决定性作用的的系统。 软件架构中的关键点是应该符合项目干系人的目标,功能上当然细分成功能性的和非功能性的需求。 软件架构有一定 阅读全文
posted @ 2013-01-31 15:10 于为 阅读(175) 评论(0) 推荐(0) 编辑
摘要: 开篇 上篇,我们介绍了,单机软件的架构,其实不管什么软件系统,都是为了解决实际中的一些问题,软件上为了更好的解决实际的问题才会产生,那么对于单机软件的架构则也是在不断的变化和发展,当然好的软件架构会对软件的生命周期起到决定的作用。好的软件架构,无疑会延长单机软件的生命周期,同时适应后期的不断的衍生的需求变化,.NET FrameWork的架构设计和体系结构设计,我相信是非常优秀的。 本篇,将会讲述大家比较常见的架构模式,客户端-服务器的模式,可以理解成C/S架构模式。现在的C/S架构已经从原来的简单的客户端-服务器的形式,变成了更多衍生的架构模式,C/A/S,C/S/M/S。包括多层C/S的架 阅读全文
posted @ 2013-01-31 15:08 于为 阅读(322) 评论(0) 推荐(0) 编辑
摘要: 开篇 系统架构的文章系列,也是搁浅的太久了,最近也是整理了下思路,将目前未完成的内容,写完吧,也不能拖太久,就不太好了。所以就趁周末写一下,今天我们要说的是单机应用,单击应用软件可以很复杂,也可以很简单。有些单机软件可以没有数据库,也可以有数据库,比如我们平时的一些工具类的软件,写字板,VS开发工具等,当然,目前很多的单机软件都有联网的功能,单机软件,估计大家有时候回想,单机软件不需要什么特殊的架构设计吧,其实不然,因为有的时候我们的单机工具,可能是提供给不同的用户群体等,或者是面向不同的人员使用时,适应不同的场景和需求的变化时,就会要求我们的单机软件也需要从架构的角度去考虑。因为如果想要可持 阅读全文
posted @ 2013-01-31 15:07 于为 阅读(399) 评论(0) 推荐(0) 编辑
摘要: 一、开篇 上一篇我们讲述了结构型模式中的代理模式。本篇,我们将会开始讲述行为型模式中的命令模式,在设计模式的这些基本的模式完成后,我将会将一些经常用的其他的一些扩展的模式进行讲解,希望能够引起大家的共鸣。 我们先来看看命令模式的定义吧: 命令模式是将一类对象的功能操作进行抽象,一般来说,这些对象有相同的方法,所以这类对象有着类似的操作,我们通过抽象,就可以定义出一个命令对象,通过这样的方式,用户程序在使用的时候,只与该命令对象打交道,而不用与一类对象打交道,降低了耦合性,提高了程序设计的灵活性。 命令模式适应于一组对象他们的操作形式非常的类似,这个时候我们可以把对象的行为进行抽象,抽象成命令对 阅读全文
posted @ 2013-01-31 15:02 于为 阅读(316) 评论(0) 推荐(0) 编辑
摘要: 一、上篇回顾 很久没有更新设计模式系列的文章了,有了很多热心朋友的反馈,我决定继续将这个系列赶快写完,最近由于过年了,有很多相关的事宜要做,所以没有时间来写,也是对大家的说下抱歉,感觉写文章的时间越来越少了,不过我会努力,尽快将这个系列写完,与大家共勉,希望大家有什么意见或建议,都可以帮我提出来,我好改进,谢谢!。 本文主要是讲述设计模式中的结构性模式中的最后一个本系列讲述的模式,也是经常用到的模式,代理模式,由于目前我们在很多的技术中都会用到这个代理模式,所以对我们来说,代理模式是必须掌握的模式之一。我们先来看看代理的思路及原理: 通过上面的图片,我们可以看到,通过增加代理来解耦A与C之间的 阅读全文
posted @ 2013-01-31 15:01 于为 阅读(177) 评论(0) 推荐(0) 编辑
摘要: 一、上篇回顾 通过上篇的简单描述,我们知道了桥接模式主要是为了解决,一个对象的多个维度的变化因素的变化太快,难以控制的问题,我们通过将每个维度的变化因素进行抽象, 然后我们的对象只要依赖于抽象即可,具体的实现调用我们不关心,通过对象组合的方式,我们就能组合出我们想要的对象。无疑这是一种非常灵活的也是满足设计模式的原则的,抽象和实现分离,使他们各自发生变化都不受对方的影响。而且我们也讲述了,使用桥接模式的几个典型的场景,现在我们的实际项目中就有这样的问题,我也是在项目的使用过程中加深对桥接模式的理解的,桥接模式为系统在多个维度的变化的适应性方面提供了很好的参考,特别适合底层框架的开发过程中使用, 阅读全文
posted @ 2013-01-31 15:00 于为 阅读(172) 评论(0) 推荐(0) 编辑
摘要: 一、上篇回顾 通过上篇的讲述,我们知道装饰模式,特别适合对某个类型的对象,动态的增加新的职责,应用程序就像使用原来的对象一样使用对象新增的装饰后的功能,装 饰模式就好像是穿了一层层的外壳,这样的方式避免了通过继承来为类型添加新的职责的形式可取,通过继承的方式容易造成子类的膨胀,但是当装饰类太多的时 候,也是个难以维护的问题,至少是在装饰对象的时候,我们可能需要多步操作来完成对象的装饰,这时候我们可以同上面提出的改进的方案,来完成自动配置装饰 模式,记录操作模式的状态,可以进行有效的回滚操作,以完成撤销操作。 我们先来回顾下装饰模式的使用场景: 1、当我们需要为某个现有的对象,动态的增加一个新的 阅读全文
posted @ 2013-01-31 15:00 于为 阅读(264) 评论(0) 推荐(0) 编辑
摘要: 一、上篇回顾 上篇我们讲述了比较常用的适配器模式,并且分析了适配器的一般使用场景: 1、我们在使用第三方的类库,或者说第三方的API的时候,我们通过适配器转换来满足现有系统的使用需求。 2、我们的旧系统与新系统进行集成的时候,我们发现旧系统的数据无法满足新系统的需求,那么这个时候,我们可能需要适配器,完成调用需求。 3、我们在使用不同数据库之间进行数据同步。(我这里只是分析的是通过程序来说实现的时候的情况。还有其他的很多种方式[数据库同步])。 并且讲述了对象适配器和类适配器的区别: 对象适配器:不是通过继承的方式,而是通过对象组合的方式来进行处理的,我们只要学过OO的设计原则的都知道,组合相 阅读全文
posted @ 2013-01-31 14:59 于为 阅读(665) 评论(0) 推荐(0) 编辑
摘要: 一、上篇回顾 通过上篇的简单讲解,我们知道了,组合模式意图是通过整体与局部之间的关系,通过树形结构的形式进行组织复杂对象,屏蔽对象内部的细节,对外展现统一的方式来操作对象,是我们处理更复杂对象的一个手段和方式。本文以查询控件为例,说明了,查询控件内部的组成元素,及如何操作内部的组成元素,包括添加元素,删除和处理相应事件的Handler,当然组合模式的作用远比这些强大,后面我们肯定会在一些实例代码中运用到组合模式的。组合模式如果在条件允许的情况下,我们尽量使用组合模式来处理复杂对象,远比通过继承出来的对象来的有效。 组合模式-强调的是如何组织整体和局部之间的结构,将整体和局部之间的关系,通过树形 阅读全文
posted @ 2013-01-31 14:58 于为 阅读(193) 评论(0) 推荐(0) 编辑
摘要: 一、上篇回顾上篇我们主要讲述了创建型模式中的最后一个模式-原型模式,我们主要讲述了原型模式的几类实现方案,和原型模式的应用的场景和特点,原型模式适合在哪些场景下使用呢?我们先来回顾一下我们上篇讲述的3个常用的场景。 1、我们在运行态的时候,动态的创建一个动态类型的对象的时候,可能我们使用原型模式,可以动态的创建指定类型的副本,这无疑是好的选择,否则如果通过我们前面讲述的几个创建型模式来实现的话,效率和代价上是非常大的。 2、有的时候我们需要对比一个对象在处理前和处理后进行对象状态的对比,对比是否处理后对象的状态是否发生变化,或者是其他的要求。这个时候通过原型模式来克隆对象的副本,远比通过引入其 阅读全文
posted @ 2013-01-31 14:57 于为 阅读(191) 评论(0) 推荐(0) 编辑