
软件架构
文章平均质量分 82
极简Qt
Qt让数字化更简单,专业Qt软件开发
展开
-
系统架构师职责
系统架构师的职责包括:• 系统构架师负责领导和协调整个项目中的技术活动。• 在个人综合素养方面,系统构架师应该具有领导才能,能够在压力下作出关键性的决策并善始善终;• 能够赢得项目经理、客户、用户群体以及管理团队的认同和尊敬,尤其要善于和项目经理紧密协作;• 在各个方面都能展现出面向目标的实干作风。在专业技能方面,与其他角色相比,系统构架师通常具有全方位的技能,其见解重在广度,而不是深度。 • 系原创 2011-06-30 09:22:00 · 1545 阅读 · 0 评论 -
实时数据缓存管理的初步设计
http://vcsky.net by havenzhao对于实时较大数据量的缓存管理上,设计的方式有很多。在此提出一种初步的、较粗略的思路,仅供参考。背景:系统分为三层,数据采集层(采集底层的数据),消息管理层(对采集上来的数据进行处理)、消息接口层(对消息解析封装、处理客户端的Socket请求等)。在数据的缓存管理上,采用双缓冲区模式的管理机制。http://vcsky.原创 2012-05-10 12:30:01 · 5440 阅读 · 0 评论 -
浅谈几种创建型模式的优缺点及其相关性
本文只是从文字、概念上来描述一下,并没有给出类图和相关代码,适合有一定基础的人阅读。在23种GOF设计模式中,创建模式主要有以下几种:简单工厂模式Simple Factory工厂方法模式Factory Method抽象工厂模式Abstract Factory 单例模式Singleton多例模式Multiton建造模式Builder原型模式 Prototype原创 2011-11-11 23:32:03 · 7928 阅读 · 0 评论 -
软件设计原则----迪米特法则(LoD)
“一个对象应该对其他对象有尽可能少的了解”“Only talk to your immediate friends”“Don’t talk to strangers”“每一个软件单位对其他的单位都只有最少的知识,而且局限于那些与本单位密切相关的软件单位” ……来源:迪米特法则(LoD)最初是用来作为面向对象的系统设计风格的一种法则,是很多著名系统,如火星原创 2011-11-04 10:07:55 · 3342 阅读 · 0 评论 -
软件设计原则----合成/聚合复用原则(CARP)
“要尽量使用合成/聚合,尽量不要使用继承。”陈述:在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分,新对象通过向这些对象的委派达到复用已有功能的目的。引入:如我们所知,在面向对象设计里,不同环境中复用已有设计和实现的基本方法:继承。合成/聚合。1、继承复用继承复用通过扩展一个已有对象的实现来得到新的功能,基类明显地捕获共同的属性和原创 2011-10-29 19:18:37 · 7476 阅读 · 2 评论 -
软件设计原则----接口隔离原则(ISP)
“使用多个专门的接口比使用单一的总接口要好”。“一个类对另外一个类的依赖性应该建立在最小的接口上”。陈述:不应该强迫客户依赖于他们不用的方法。一个类的不内聚的“胖接口”应该被分解成多组方法,每一组方法都服务于一组不同的客户程序。例子: Door可以加锁、解锁、而且可以感知自己是开还是关; Door是抽象基类,客户程序可以依赖于抽象而不是具体的实现。原创 2011-10-26 09:07:59 · 4206 阅读 · 1 评论 -
软件设计原则----依赖倒置原则(DIP)
"要依赖于抽象,不要依赖于具体。”“要针对接口编程,不要针对实现编程。”陈述:高层模块不应该依赖于低层模块。二者应该依赖于抽象。抽象不应该依赖于细节。细节应该依赖于抽象。分析:所谓“倒置”是相对于传统的开发方法(例如结构化方法)中总是倾向于让高层模块依赖于低层模块而言的软件结构而言的。高层包含应用程序的策略和业务模型,而低层包含更多的实现细节,平台相关细原创 2011-10-25 15:48:45 · 4726 阅读 · 0 评论 -
软件设计原则----LisKov替换原则(LSP)
“一个软件实体如果使用的是一个基类的话,一定适用于其子类,而且根本不能觉察出基类对象和子类对象的区别。”陈述:子类型(Subtype)必须能够替换他们的基类型(Basetype)Barbara Liskov对原则的陈述:若对每个类型S的对象o1,都存在一个类型T的对象o2,使得在所有针对T编写的程序P中,用o1替换o2后,程序P的行为功能不变,则S是T的子类型。通俗地讲原创 2011-10-21 10:32:56 · 4001 阅读 · 0 评论 -
软件设计原则----开-闭原则(OCP)
设计一个模块时,应当使该模块在不被修改的前提下被扩展,即可在不必修改源代码的情况下改变该模块的行为。 陈述: 软件实体(类、模块、函数等)应该是可以扩展的,同时还可以是不必修改的,更确切的说,函数实体应该:(1)对扩展是开放的当应用的需求变化时,我们可以对模块进行原创 2011-09-27 08:16:20 · 12544 阅读 · 25 评论 -
软件设计原则----单一职责原则(SRP)
陈述:就一个类而言,应该只有一个导致其变化的原因分析:一个职责就是一个变化的轴线。一个类如果承担的职责过多,就等于将这些职责耦合在一起。一个职责的变化可能会虚弱或者抑止这个类完成其它职责的能力。多职责将导致脆弱性的臭味。示例1: Rect原创 2011-09-26 08:43:02 · 7154 阅读 · 7 评论 -
需求分析知识点滴【二】
1. 完成需求获取的标志用户总是按其重要性的顺序来确定用例的,如果用户不能想出更多的用例; 如果用户开始讨论已讨论过的用例或需求; 如果用户提出新的用例,但却可以从其它用例导出或是其它用例的可选过程;如果所提出的新的需求是针对将来产品的而不是现在讨论的特定产品;如果用原创 2011-09-04 18:46:40 · 2960 阅读 · 1 评论 -
需求分析知识点滴【一】
1. 不同生命周期模型中需求的特点 瀑布模型:使用简单,并且直观明显;必须严格控制;软件需求要有明确的界定;具备如何实施的解决方案的知识。 V型模型:使用简单,并且直观明显;强调核查和验证;软件需求要有明确的界定;软件开发技术和工具必须是已知的。 演原创 2011-08-31 20:49:36 · 1346 阅读 · 0 评论 -
软件系统坏死的症状
“Copy”程序:一个从键盘读入字符并输出到打印机的程序。void Copy(){ int c; while ((c = RdKbd()) != EOF) WrtPtr(c);}用户希望Copy程序能从纸带读入机中读入信息。现实中的约束--不能改变接原创 2011-07-19 09:32:29 · 1428 阅读 · 0 评论 -
The Research and Development of SCADA in Petroleum Industry
The Research and Development of SCADA in Petroleum Industry 1. Primary PurposeSCADA is short for “supervisory control and data acquisition”原创 2011-07-26 08:54:11 · 2491 阅读 · 0 评论 -
技术架构之设计原则
分享一下培训资料总结,关于技术架构中的设计原则与模式。原创 2011-07-06 08:53:30 · 2630 阅读 · 0 评论 -
井场数据采集系统的架构演化
XXX井场数据采集系统,是实现XXX物联网的基础,它从井场设备上采集钻井工程过程中的各种数据,远程传输到地区公司的数据中心,提供实时和准实时数据给远程作业支持中心和专家中心的各种专业软件进行处理,指导井场钻井作业。采集系统最早开始于2012年初着手架构和开发,期间经历了从无到有,从有到优的一个改进过程,共发生过四次架构演化。vcsky.net探索出来的架构这个时期的架构,可以说是一种猜想的原创 2013-09-11 08:24:37 · 6295 阅读 · 0 评论