摘要：
一、摘要 本文主要从系统架构中的建模开始讲解，本文讲述的内容主要是我在工作和学习过程中的总结和经验，不足之处还请大家多多批评指出，有更好的建议也可以留言说明。本意主旨是为不熟悉系统架构建模过程和不知道如何使用建模工具，或者不熟悉如何根据需求去建立模型的角度出发，简单的阐述了在系统架构的过程中我们应该从什么样的角度出发去分析需求并且建立抽象模型。这应该说是架构师必备的技能。 本文由浅入深，本篇将简单的介绍如何使用使用UML建模中的各个结构图与行为图，去完成抽象模型的建立。二、本章内容 1、摘要。 2、本章内容。 3、建模工具介绍及使用。 4、建模中的抽象模型图。 5、本质总结。 6、系列进度。 阅读全文
posted @ 2013-01-31 15:11
于为
阅读(214)
评论(0)
推荐(0)
摘要：
一、上章回顾 上篇文章主要简单的介绍了建模中使用的标准建模语言UML的相关内容，包括用例图与类图的使用方法及如何建模。相信大家对UML建模语言已经有了初步的认识，还请大家谨记UML不同的建模图形的用处。比如，用例图主要用来描述系统的功能需求。类图主要用来描述实体间的关系。谨记这些就可以帮助我们在系统架构的过程中深入的分析。 首先向大家道歉，上篇中有部分描述错误的地方，可能对大家造成一定的错误引导。这是上篇给出的图，我描述的是组合关系。 特别更正为：这是正确的结果。箭头指向聚合类。描述的信息并无任何错误。希望能对大家指正。二、摘要 本文主要从系统架构中的建模开始讲解，本文讲述的内容主要是我在工作 阅读全文
posted @ 2013-01-31 15:11
于为
阅读(183)
评论(0)
推荐(0)
摘要：
开篇说明 由于是自己对这些技术的学习总结和心得体会，错误之处在所难免，怀着技术交流的心态，现在发表出来，所以希望大家能够多多指点，这样能使一部分人受益同时也能纠正我的错误观点，以便和各位共同提高！软件架构到底是什么 软件架构可以被简单的描述为，一系列组件之间的组合，交互，继承的关系。当然这样的解释基本上人人都可以接收。不过在我们看来，这样的说法有点过于抽象。 软件架构有这标准的定义，就是参考ANSI/IEEE的标准，软件架构可以理解为软件密集型系统中对系统的实现和部署起决定性作用的的系统。 软件架构中的关键点是应该符合项目干系人的目标，功能上当然细分成功能性的和非功能性的需求。 软件架构有一定 阅读全文
posted @ 2013-01-31 15:10
于为
阅读(200)
评论(0)
推荐(0)
摘要：
开篇 上篇，我们介绍了，单机软件的架构，其实不管什么软件系统，都是为了解决实际中的一些问题，软件上为了更好的解决实际的问题才会产生，那么对于单机软件的架构则也是在不断的变化和发展，当然好的软件架构会对软件的生命周期起到决定的作用。好的软件架构，无疑会延长单机软件的生命周期，同时适应后期的不断的衍生的需求变化，.NET FrameWork的架构设计和体系结构设计，我相信是非常优秀的。 本篇，将会讲述大家比较常见的架构模式，客户端-服务器的模式，可以理解成C/S架构模式。现在的C/S架构已经从原来的简单的客户端-服务器的形式，变成了更多衍生的架构模式，C/A/S,C/S/M/S。包括多层C/S的架 阅读全文
posted @ 2013-01-31 15:08
于为
阅读(361)
评论(0)
推荐(0)
摘要：
开篇 系统架构的文章系列，也是搁浅的太久了，最近也是整理了下思路，将目前未完成的内容，写完吧，也不能拖太久，就不太好了。所以就趁周末写一下，今天我们要说的是单机应用，单击应用软件可以很复杂，也可以很简单。有些单机软件可以没有数据库，也可以有数据库，比如我们平时的一些工具类的软件，写字板，VS开发工具等，当然，目前很多的单机软件都有联网的功能，单机软件，估计大家有时候回想，单机软件不需要什么特殊的架构设计吧，其实不然，因为有的时候我们的单机工具，可能是提供给不同的用户群体等，或者是面向不同的人员使用时，适应不同的场景和需求的变化时，就会要求我们的单机软件也需要从架构的角度去考虑。因为如果想要可持 阅读全文
posted @ 2013-01-31 15:07
于为
阅读(480)
评论(0)
推荐(0)
摘要：
一、开篇 上一篇我们讲述了结构型模式中的代理模式。本篇，我们将会开始讲述行为型模式中的命令模式，在设计模式的这些基本的模式完成后，我将会将一些经常用的其他的一些扩展的模式进行讲解，希望能够引起大家的共鸣。 我们先来看看命令模式的定义吧： 命令模式是将一类对象的功能操作进行抽象，一般来说，这些对象有相同的方法，所以这类对象有着类似的操作，我们通过抽象，就可以定义出一个命令对象，通过这样的方式，用户程序在使用的时候，只与该命令对象打交道，而不用与一类对象打交道，降低了耦合性，提高了程序设计的灵活性。 命令模式适应于一组对象他们的操作形式非常的类似，这个时候我们可以把对象的行为进行抽象，抽象成命令对 阅读全文
posted @ 2013-01-31 15:02
于为
阅读(340)
评论(0)
推荐(0)
摘要：
一、上篇回顾 很久没有更新设计模式系列的文章了，有了很多热心朋友的反馈，我决定继续将这个系列赶快写完，最近由于过年了，有很多相关的事宜要做，所以没有时间来写，也是对大家的说下抱歉，感觉写文章的时间越来越少了，不过我会努力，尽快将这个系列写完，与大家共勉，希望大家有什么意见或建议，都可以帮我提出来，我好改进，谢谢！。 本文主要是讲述设计模式中的结构性模式中的最后一个本系列讲述的模式，也是经常用到的模式，代理模式，由于目前我们在很多的技术中都会用到这个代理模式，所以对我们来说，代理模式是必须掌握的模式之一。我们先来看看代理的思路及原理： 通过上面的图片，我们可以看到，通过增加代理来解耦A与C之间的 阅读全文
posted @ 2013-01-31 15:01
于为
阅读(197)
评论(0)
推荐(0)
摘要：
一、上篇回顾 通过上篇的简单描述，我们知道了桥接模式主要是为了解决，一个对象的多个维度的变化因素的变化太快，难以控制的问题，我们通过将每个维度的变化因素进行抽象， 然后我们的对象只要依赖于抽象即可，具体的实现调用我们不关心，通过对象组合的方式，我们就能组合出我们想要的对象。无疑这是一种非常灵活的也是满足设计模式的原则的，抽象和实现分离，使他们各自发生变化都不受对方的影响。而且我们也讲述了，使用桥接模式的几个典型的场景，现在我们的实际项目中就有这样的问题，我也是在项目的使用过程中加深对桥接模式的理解的，桥接模式为系统在多个维度的变化的适应性方面提供了很好的参考，特别适合底层框架的开发过程中使用， 阅读全文
posted @ 2013-01-31 15:00
于为
阅读(183)
评论(0)
推荐(0)
摘要：
一、上篇回顾 通过上篇的讲述，我们知道装饰模式，特别适合对某个类型的对象，动态的增加新的职责，应用程序就像使用原来的对象一样使用对象新增的装饰后的功能，装 饰模式就好像是穿了一层层的外壳，这样的方式避免了通过继承来为类型添加新的职责的形式可取，通过继承的方式容易造成子类的膨胀，但是当装饰类太多的时 候，也是个难以维护的问题，至少是在装饰对象的时候，我们可能需要多步操作来完成对象的装饰，这时候我们可以同上面提出的改进的方案，来完成自动配置装饰 模式，记录操作模式的状态，可以进行有效的回滚操作，以完成撤销操作。 我们先来回顾下装饰模式的使用场景： 1、当我们需要为某个现有的对象，动态的增加一个新的 阅读全文
posted @ 2013-01-31 15:00
于为
阅读(285)
评论(0)
推荐(0)
摘要：
一、上篇回顾 上篇我们讲述了比较常用的适配器模式，并且分析了适配器的一般使用场景： 1、我们在使用第三方的类库，或者说第三方的API的时候，我们通过适配器转换来满足现有系统的使用需求。 2、我们的旧系统与新系统进行集成的时候，我们发现旧系统的数据无法满足新系统的需求，那么这个时候，我们可能需要适配器，完成调用需求。 3、我们在使用不同数据库之间进行数据同步。(我这里只是分析的是通过程序来说实现的时候的情况。还有其他的很多种方式[数据库同步])。 并且讲述了对象适配器和类适配器的区别： 对象适配器：不是通过继承的方式，而是通过对象组合的方式来进行处理的，我们只要学过OO的设计原则的都知道，组合相 阅读全文
posted @ 2013-01-31 14:59
于为
阅读(691)
评论(0)
推荐(0)
浙公网安备 33010602011771号