当前位置:  编程技术>软件工程/软件设计
本页文章导读:
    ▪actor-based programming与构建大规模扩展性的并行系统      1.actor-based  programming  actor based 类似于object based ,但是它比object 多了自己的message queue 和message processor、message handler 也就是说一个actor是一个独立的处理单元,但是他不是真正的物.........
    ▪[技术讨论]系统间调用与边界类的差别——被混淆的两个概念      这里谈到的是系统间的调用关系与分析模型中边界类的区别,另外还提到了在分析模型和设计模型中的一点区别。 2013-03-26       福州-Thomas 男9:45:31 我想问问,在分析.........
    ▪我所理解的设计模式(C++实现)——抽象工厂模式      解决的问题:        在系统里a,b,c三个组件必须同时使用,但是a的同类 a1和a2这三种方法有共同特点但是是互斥的,b,b1,b2和c,c1,c2和a/a1/a2是一样的。就比如说创建在不同操作系统.........

[1]actor-based programming与构建大规模扩展性的并行系统
    来源: 互联网  发布时间: 2013-10-30

1.actor-based  programming

 actor based 类似于object based ,但是它比object 多了自己的message queue 和message processor、message handler

也就是说一个actor是一个独立的处理单元,但是他不是真正的物理上的thread

可以看成是轻量级的thread。

一个actor可以给另一个actor push msg

这样系统中就可以存在大量的独立活动单元,是并行系统的基本组件。

2.Intel TBB(Threading Build Block)

这是intel的一个开源的高性能线程库,它可以很大效率的支持多个任务的并行(这是隐藏实际的物理的thread的),我们可以把上面的actor分配给TBB去调度管理,来实现高性能的并行系统。

这个库还提供了各种thread-safe的container,而我们知道标准c++的stl的container都是线程不安全的。

 

感想

这种actor-based方法让我想到了QT中的Qwidget,他们可以互相通信,有各自的message queue,但是不同的是Qwidget是单线程的,没有一个多线程库去对他们之间做并发。

 

使用actor-based方法构建并行系统,比我们单纯使用多线程来实现的好处是:

1.纯多线程的系统受线程数量的影响,当系统复杂度提高时,线程数目要升高,会降低性能甚至不能扩展系统。

2.纯多线程的系统一般要使用lock critical area等来对线程进行互斥,当系统复杂度提升时,各种dead lock等问题也会出来,降低性能。而actor-based是share nothing的,一个actor里面的数据是相互独立的,不必使用线程间的互斥和等待。

但是个人认为这种情况是理想的,有时还是要用锁的,关于这个,现在有一种transactional memory的东西来实现无锁的多线程并发,不过还处于实验阶段。

作者:leonwei 发表于2013-3-28 12:59:06 原文链接
阅读:52 评论:0 查看评论

    
[2][技术讨论]系统间调用与边界类的差别——被混淆的两个概念
    来源: 互联网  发布时间: 2013-10-30

这里谈到的是系统间的调用关系与分析模型中边界类的区别,另外还提到了在分析模型和设计模型中的一点区别。

 

2013-03-26      

福州-Thomas 男9:45:31

我想问问,在分析类中,如果某个控制类需要和第三方通信,那么第三方应该当作一个边界,那么在画图的时候是控制类发送消息到第三方的边界类去? 

北京青润10:57:12

这应该是接口类,不是边界类。

北京青润 10:57:46

接口类属于非UI类型的类,有人把它划作边界类来定位。

北京青润 10:58:12

但是一般情况下,边界类指的就是UI相关的用户操作界面类。

福州-Thomas 男 15:18:56

分析类不是只有3种类型吗

福州-Thomas 男 15:19:08

边界控制 实体, 哪里的接口类?

福州-Thomas 男 15:25:49

分析类时序图,在搞支付平台,我们对接支付宝等,别的子系统再接我们平台

北京青润 15:25:54

这个要看你的整体架构设计是在哪一层进行数据通信的。

北京青润 15:26:08

一般来说这样的数据通信不可能在界面层。

福州-Thomas 男 15:26:14

福州-Thomas 男 15:26:22

在 service层

北京青润 15:27:29

这个接口的提供属于外部连接的实现,也就是系统内的逻辑关系体现,要看你的整体的架构实现思想。

一般来说都应该是在控制层进行的实现。

福州-Thomas 男 15:27:30

界面有可能在子系统,我们是做个支付的黑匣子系统,只对外暴露出 SOA 接口,子系统调用我们的接口与支付宝对接

北京青润 15:27:38

也就是mvc中的c中进行实现。

北京青润 15:27:57

到了设计模型阶段才会根据情况分离出来接口类和具体的实现关系。

福州-Thomas 男 15:28:28

哦,我们的 C 在实现时也会是个 serivce,没有 web mvc框架

北京青润 15:28:38

两个子系统或者子模块之间应该是c-c的调用关系。

北京青润 15:28:57

那就不要在分析模型阶段谈设计模型的事情

北京青润 15:29:24

不管它将来是什么形式,每一个阶段都要做自己的事情,跨阶段做开发的结果往往是得不偿失的。

福州-Thomas 男 15:29:44

那你在画支付用例的分析类时序图时候,和支付宝对接 不用表示吗

北京青润 15:30:19

分析模型要有分析模型的形态,只需要标记出来这里连接一个支付系统即可。

福州-Thomas 男 15:31:34

那这个支付系统 是 另外的一个 UML元素,还是 边界类来表示? 按道理说  第三方支付系统相对我们的支付平台也就是个边界,我们发请求给它

北京青润 15:32:16

自己的团队内部统一,可以通过一个message to self,上面加一个标签标识即可。

福州-Thomas 男 15:33:36

那为什么不能把它当作一个边界类呢

北京青润 15:33:56

它本来就不是一个边界类,你为什么非要当作边界类呢?

福州-Thomas 男 15:34:35

相对于我们自己的系统来说它就是个边界啊,我们在这个边界之外向它发送消息

北京青润 15:34:46

那是系统之外。

北京青润 15:34:57

这是系统间关系调用。

福州-Thomas 男 15:35:11

哦,

作者:qingrun 发表于2013-3-28 17:48:15 原文链接
阅读:0 评论:0 查看评论

    
[3]我所理解的设计模式(C++实现)——抽象工厂模式
    来源: 互联网  发布时间: 2013-10-30
解决的问题:
       在系统里a,b,c三个组件必须同时使用,但是a的同类 a1和a2这三种方法有共同特点但是是互斥的,b,b1,b2和c,c1,c2和a/a1/a2是一样的。就比如说创建在不同操作系统的视窗环境下都能够运行的系统时,Unix下面有unixButton和 unixText,Win下面也有winButton和winText,unixButton和unixText必须在一个系统unix里面用,而winButton和winText只能在Win下面用。但是winButton和unixButton这两种东西都是有相同的特点的,比如说按下去之后会触发事件,比如说他上面有文字描述等等,但是winButton和unixButton却又是不可以混用的。

     那么此问题就可以用抽象工厂很好的解决:
     在抽象工厂模式中如何选择使用 winButton ,winText,有具体的工厂类winFactory来负责,因为他们含有选择合适的产品对象的逻辑,所以是与应用系统的商业逻辑紧密相关的。而抽象工厂类来负责定义接口,他才是抽象工厂模式的核心。
     而winButton/macButton则是一种产品族,有共同的特点,他们具体特点有抽象产品类或者接口来定义和描述。但是他们具体的实现有具体的产品类负责,这些是客户端最终想要的东西,所以其内部一定充满了应用系统的商业逻辑(触发逻辑/样式逻辑等)。

类图结构:    


样例实现:
// CplusplusAbstractFactory.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include<typeinfo>
// "AbstractProductA" 草食动物
class Herbivore
{
};

// "AbstractProductB" 食肉动物
class Carnivore
{
public:
	// Methods
	virtual void Eat( Herbivore *h ) {};
};

// "ProductA1"
class Wildebeest : public Herbivore
{
};

// "ProductA2"
class Bison : public Herbivore
{
};

// "ProductB1"
class Lion : public Carnivore
{

public:
	// Methods
	void Eat( Herbivore *h )
	{
		// eat wildebeest	 
		printf("Lion eats %s\n",typeid(h).name());
	}
};

// "ProductB2"
class Wolf : public Carnivore
{

public:
	// Methods
	void Eat( Herbivore *h )
	{
		// Eat bison
		printf("Wolf eats %s\n",typeid(h).name());
	}
};

// "AbstractFactory"
class ContinentFactory
{
public:
	// Methods
	virtual Herbivore* CreateHerbivore()
	{
		return new Herbivore();
	}
	virtual Carnivore* CreateCarnivore()
	{
		return new Carnivore();
	}
};

// "ConcreteFactory1"
class AfricaFactory : public ContinentFactory
{
public:
	// Methods
	Herbivore* CreateHerbivore()
	{ 
		return new Wildebeest(); 
	}

	Carnivore* CreateCarnivore()
	{ 
		return new Lion(); 
	}
};

// "ConcreteFactory2"
class AmericaFactory : public ContinentFactory
{
public:
	// Methods
	Herbivore* CreateHerbivore()
	{ 
		return new Bison(); 
	}

	Carnivore* CreateCarnivore()
	{ 
		return new Wolf(); 
	}
};



// "Client"
class AnimalWorld
{
private:
	// Fields
	Herbivore* herbivore;
	Carnivore* carnivore;

public:
	// Constructors
	AnimalWorld( ContinentFactory *factory )
	{
		carnivore = factory->CreateCarnivore();
		herbivore = factory->CreateHerbivore();
	}

	// Methods
	void RunFoodChain()
	{ 
		carnivore->Eat(herbivore); 
	}
};


int _tmain(int argc, _TCHAR* argv[])
{
	// Create and run the Africa animal world
	ContinentFactory *africa = new AfricaFactory();
	AnimalWorld *world = new AnimalWorld( africa );
	world->RunFoodChain();

	// Create and run the America animal world
	ContinentFactory *america = new AmericaFactory();
	world = new AnimalWorld( america );
	world->RunFoodChain();

	return 0;
}

“开放-封闭”原则:

抽象工厂可以很好的应对增加新产品族的问题(即a4/b4/c4),且符合“开放-封闭”原则,但是若是增加新的产品结构的话(即d/d1/d2),就是说a/b/c/d这4中方法必须同时使用了,那就必须修改工厂角色。不符合“开放-封闭”原则。综合来讲,抽象工厂模式以一种倾斜的方式支持增加新的产品,它为新产品族的增加提供方便,而不能为新的产品结构的增加提供这样的方便。

实现要点:

  • 在抽象工厂模式中,选用哪种产品族的问题,需要采用工厂方法或简单工厂模式来配合解决。
  • 抽象工厂模式和工厂方法模式一样,都把对象的创建延迟到了他的子类中。
  • 具体的工厂类可以设计成单例类,他只向外界提供自己唯一的实例。

与其他工厂模式的联系和异同:
  • 抽象工厂模式中的具体工厂负责生产一个产品族的产品。而产品族的增加只需要增加与其对应的具体工厂。
  • 3种工厂模式都是创建型模式,都是创建对象的,但都把产品具体创建的过程给隐藏了。
  • 工厂方法模式是针对一种产品结构,而抽象工厂模式是针对多种产品结构。

适用性:

在以下情况下应当考虑使用抽象工厂模式:

  • 一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节,这对于所有形态的工厂模式都是重要的。
  • 这个系统有多于一个的产品族,而系统只消费其中某一产品族。
  • 同属于同一个产品族的产品是在一起使用的,这一约束必须在系统的设计中体现出来。
  • 系统提供一个产品类的库,所有的产品以同样的接口出现,从而使客户端不依赖于实现。

应用场景:

  • 支持多种观感标准的用户界面工具箱(Kit)。
  • 游戏开发中的多风格系列场景,比如道路,房屋,管道等。

LCL_data原创于CSDN.NET【http://blog.csdn.net/lcl_data/article/details/8733933】
作者:LCL_data 发表于2013-3-28 21:54:29 原文链接
阅读:8 评论:0 查看评论

    
最新技术文章:
▪主-主数据库系统架构    ▪java.lang.UnsupportedClassVersionError: Bad version number i...    ▪eclipse项目出现红色叉叉解决方案
▪Play!framework 项目部署到Tomcat    ▪dedecms如何做中英文网站?    ▪Spring Batch Framework– introduction chapter(上)
▪第三章 AOP 基于@AspectJ的AOP    ▪基于插件的服务集成方式    ▪Online Coding开发模式 (通过在线配置实现一个表...
▪观察者模式(Observer)    ▪工厂模式 - 程序实现(java)    ▪几种web并行化编程实现
▪机器学习理论与实战(二)决策树    ▪Hibernate(四)——全面解析一对多关联映射    ▪我所理解的设计模式(C++实现)——解释器模...
▪利用规则引擎打造轻量级的面向服务编程模式...    ▪google blink的设计计划: Out-of-Progress iframes    ▪FS SIP呼叫的消息线程和状态机线程
▪XML FREESWITCH APPLICATION 实现    ▪Drupal 实战    ▪Blink: Chromium的新渲染引擎
▪(十四)桥接模式详解(都市异能版)    ▪你不知道的Eclipse用法:使用Allocation tracker跟...    ▪Linux内核-进程
▪你不知道的Eclipse用法:使用Metrics 测量复杂度    ▪IT行业为什么没有进度    ▪Exchange Server 2010/2013三种不同的故障转移
▪第二章 IoC Spring自动扫描和管理Bean    ▪CMMI简介    ▪目标检测(Object Detection)原理与实现(六)
▪值班总结(1)——探讨sql语句的执行机制    ▪第二章 IoC Annotation注入    ▪CentOS 6.4下安装Vagrant
▪Java NIO框架Netty1简单发送接受    ▪漫画研发之八:会吃的孩子有奶吃    ▪比较ASP和ASP.NET
▪SPRING中的CONTEXTLOADERLISTENER    ▪在Nginx下对网站进行密码保护    ▪Hibernate从入门到精通(五)一对一单向关联映...
▪.NET领域驱动设计—初尝(三:穿过迷雾走向光...    ▪linux下的块设备驱动(一)    ▪Modem项目工作总结
▪工作流--JBPM简介及开发环境搭建    ▪工作流--JBPM核心服务及表结构    ▪Eclipse:使用JDepend 进行依赖项检查
▪windows下用putty上传文件到远程Linux方法    ▪iBatis和Hibernate的5点区别    ▪基于学习的Indexing算法
▪设计模式11---设计模式之中介者模式(Mediator...    ▪带你走进EJB--JMS编程模型    ▪从抽象谈起(二):观察者模式与回调
▪设计模式09---设计模式之生成器模式(Builder)也...    ▪svn_resin_持续优化中    ▪Bitmap recycle方法与制作Bitmap的内存缓存
▪Hibernate从入门到精通(四)基本映射    ▪设计模式10---设计模式之原型模式(Prototype)    ▪Dreamer 3.0 支持json、xml、文件上传
▪Eclipse:使用PMD预先检测错误    ▪Jspx.net Framework 5.1 发布    ▪从抽象谈起(一):工厂模式与策略模式
▪Eclipse:使用CheckStyle实施编码标准    ▪【论文阅读】《Chain Replication for Supporting High T...    ▪Struts2 Path_路径问题
▪spring 配置文件详解    ▪Struts2第一个工程helloStruts极其基本配置    ▪Python学习入门基础教程(learning Python)--2 Python简...
▪maven springmvc环境配置    ▪基于SCRUM的金融软件开发项目    ▪software quality assurance 常见问题收录
▪Redis集群明细文档    ▪Dreamer 框架 比Struts2 更加灵活    ▪Maven POM入门
▪git 分支篇-----不断更新中    ▪Oracle非主键自增长    ▪php设计模式——UML类图
▪Matlab,Visio等生成的图片的字体嵌入问题解决...    ▪用Darwin和live555实现的直播框架    ▪学习ORM框架—hibernate(二):由hibernate接口谈...
▪(十)装饰器模式详解(与IO不解的情缘)    ▪无锁编程:最简单例子    ▪【虚拟化实战】网络设计之四Teaming
▪OSGi:生命周期层    ▪Javascript/Jquery——简单定时器    ▪java代码 发送GET、POST请求
▪Entity Framework底层操作封装(3)    ▪HttpClient 发送GET、POST请求    ▪使用spring框架,应用启动时,加载数据
▪Linux下Apache网站目录读写权限的设置    ▪单键模式的C++描述    ▪学习ORM框架—hibernate(一):初识hibernate
 


站内导航:


特别声明:169IT网站部分信息来自互联网,如果侵犯您的权利,请及时告知,本站将立即删除!

©2012-2021,,E-mail:www_#163.com(请将#改为@)

浙ICP备11055608号-3