zhoujg1978@hotmail.com

快乐学习

像外行一样思考,像专家一样实践
随笔 - 97, 文章 - 1, 评论 - 76, 引用 - 1
数据加载中……

2009年6月28日

敏捷实践大列表(转 noop)

由于瀑布开发的长周期以及不确定性等一系列难处理的问题导致项目失败,敏捷开发现在已经非常流行。以下为搜集的一个敏捷实践方法列表,每个都对应的链接,转载在此以供参考。

Requirements                
Product Vision / Vision Statement   SA       JS    
Product Backlog   SA MG          
User Stories Wiki SA   C2 AM   XP  
Use Cases Wiki     C2 AM   XP  
Usage Scenarios         AM      
Personas Wiki       AM      
Planning Poker Wiki              
Requirement Prioritization Wiki       AM      
Design                
Architectural Spikes / Spike Solutions       C2     XP  
Domain Driven Design Wiki             IXP
Emergent Design / Evolutionary Design Wiki     C2       IXP
CRC Cards Wiki       AM   XP  
Design by Contract Wiki              
System Metaphor             XP  
Construction                
Coding Style / Coding Guidelines / Coding Standard Wiki         JS   IXP
Test Driven Development Wiki     C2     XP  
Behavior Driven Development Wiki              
Pair-Programming / Pairing Wiki     C2   JS XP IXP
Refactoring Wiki     C2     XP IXP
Collective Code Ownership       C2   JS XP IXP
Daily Builds / Automated Builds / Ten-Minute Builds Wiki         JS    
Continuous Integration Wiki     C2   JS XP IXP
Code Reviews / Peer Reviews Wiki              
Software Metrics / Code Metrics & Analysis Wiki              
Source Control / Version Control Wiki         JS    
Issue Tracking / Bug Tracking Wiki              
Configuration Management Wiki              
Frequent Delivery / Frequent Releases       C2     XP IXP
Testing                
Unit Testing Wiki           XP  
Smoke Testing / Build Verification Test Wiki              
Integration Testing Wiki              
System Testing Wiki              
Exploratory Testing Wiki              
Test Automation Wiki SA            
Storytesting / Acceptance Criteria / Acceptance Testing Wiki     C2 AM   XP IXP
Process                
Timeboxing / Fixed Sprints / Fixed Iteration Length Wiki           XP  
Release Planning       C2   JS XP  
Iteration Planning / Planning Game / Sprint Planning Wiki SA MG C2   JS XP IXP
Sprint Backlog   SA MG          
Task Board   SA MG          
Definition of Done / Done Done   SA       JS    
Daily Stand-up Meeting / Daily Scrum Wiki SA MG C2   JS XP  
Velocity             XP  
Sprint Review / Iteration Demo   SA MG     JS    
Value Stream Mapping Wiki              
Root Cause Analysis / 5 Whys Wiki         JS    
Burn Down Charts / Burn Up Charts Wiki SA MG          
Big Visible Charts / Information Radiators           JS    
Retrospective / Reflection Workshop Wiki SA       JS   IXP
Organization                
Small Team               IXP
Cross-Functional Team Wiki              
Self-Organizing Team / Scrum Team     MG          
Colocated Team / Sitting Together / Common Workspace Wiki SA   C2   JS   IXP
On-Site Customer / Product Owner   SA MG C2   JS    
Scrum Master   SA MG          
Sustainable Pace               IXP
Move People Around             XP  
Scrum of Scrums   SA            

References
Wiki = Wikipedia
SA = Scrum Alliance
MG = Mountain Goat Software
C2 = Cunningham & Cunningham
AM = Agile Modeling
JS = James Shore
XP = Extreme Programming
IXP = Industrial XP

posted @ 2009-06-28 18:27 快乐学习 阅读(17) | 评论 (0)编辑

2009年6月15日

需求方法之-原型工具GUI Design Studio

.

上篇需求方法之-原型开发讲过制作原型是业务人员应该掌握的一项基本技能,这篇主要给大家介绍一个我认为比较好的一个工具:GUI Design Studio,大家可以到官方网站下载试用,如果用于个人学习,也可以上网搜到破解:)

软件帮助文档有个记事本的例子,如果参考做完就能大致了解如何做原型了. 下面我主要示例一个管理软件常用的界面模式,登录后显示主界面,主界面上面一个公司图标,左边为一个功能列表,点击列表时在工作区页签显示相应的模块窗体。做了一个视频,方便大家更好的快速了解.

主界面

上面为菜单和工具条,工具条主要用的就是连接线,菜单主要用的是Design-Addbitmap添加图片(我也是刚找到的,应该在右边Elements上更好)

右边为界面元素和文档目录管理:

  Project:管理文件目录层次,可以在根目录下放主界面,然后把功能模块分系统新建多个目录保存。对于界面窗体比较多时,尽量按照模块目录分类来保存,千万不要放在一个页面中设计,否则以后就不好维护了。
  Element:界面元素,比如按钮、工具条等界面展现的控件
  Icon:图标,可以软件的安装目录里加入自己的图标后应用在项目中
  Storyboard:增加动态控制界面元素的动作控件。用的最多的是windows placeholder,主要来做显示在Tab页的内容,可以查看软件的帮助文件的索引 Working with tabbed interfaces进一步了解
  Note:给控件加标题和注释,如果加了注释,在原型运行时鼠标放在#上会显示提示

演示:录制movie和demo在大米盘下载

主要说明:使用Storyboard的Window Position Anchor来定位弹出窗体的显示位置, 使用Storyboard的windows placeholder来定位显示窗体的显示位置

原型工具blog链接:

线框图-原型可视化

用Flash Catalyst做交互原型

GUIDESIGNSTUDIO3中文帮助(1)-欢迎使用 GUI Design Studio 3.0


 

posted @ 2009-06-15 16:56 快乐学习 阅读(115) | 评论 (2)编辑

需求方法之-原型开发

业务人员主导原型工作

需求在产品开发中的重要性已经是不需争议的事实,现在需求方法有很多,业界最常用的一种办法就是通过原型展现需求,通过用例表达需求。业务人员掌握制作原型能够更快更清楚的表达业务,同客户和开发可以进行更直观的沟通,使得大家在理解上容易更一致。然而原型工具有非常多,比如大多数人用过的ExcelAccessDelphiPowerPoint、Axure、Balsamiq Mockups、ForeUI、iRise、Lucid Spec、Mockup Screens、Pencil、Serena等,甚至开发工具雅奇等也可以用来做原型。工欲善其事,必先利其器,对于刚刚使用原型方法的业务人员来说,如何选择适合自己的原型工具呢?这就需要首先根据原型的目的明确做原型的粒度。

根据工作现状选择做低保真原型还是高保真原型

原型分低保真原型和高保真原型,低保真原型目标在于表达工作主要内容,体现静态的元素,不需要动态交互。高保真原型目标是作出一个和实际上线后的产品差不多的样子,不仅包括静态的界面,还包括交互,甚至有的还把数据保存、逻辑验证等都包含在内。如果客户要求开发之前必须看到和实际产品一样的原型时,这时就需要做高保真原型,如果对于小型项目,或者只是用来做交流主要需求用时,就可以做低保真原型。

我们可用作介于低保真和高保真之间的原型

在限定时间内能够将需求表达更清晰需要一个合适的工具。业务人员一般都不会有什么编程经验,我们怎么能够做出表达静态元素界面,又能加入动态交互功能的原型呢?为了能在需求阶段都能够更好的采用原型开发方法,我搜集并使用过多种原型工具,希望找打一款比较使用简单,但又能实现一般的交互功能,最好是业务人员学个一个小时就可以完全自己动手使用了。我用过一个原型工具 GUI Design Studio它的主要特点就是操作简单,不需要开发人员帮助,通过半个小时的学习后你将可以自己开始做原型了。后面我会对这个工具的使用进行介绍,希望有更多的业务人员能够更好的应用原型来进行需求开发。

 

原型不仅仅是需求,它还是设计

我们可以通过原型来引导用户来使用系统解决问题,但原型不仅仅是需求,它还是设计,所以作原型时不仅需要客户的参与,也需要技术人员的参与,但应该尽量由业务人员而非开发人员来实现原型,这样才能更好的保证做需求不会演变成做开发了。下面是在UCD社区里面看到的一张图,原型最主要功能是表现界面,但要做好界面其实不容易,山下面还有很多东西需要考虑才能支撑界面,其实做原型的过程就是设计系统的过程。我们都希望尽量把开发工作前移,需求能做的工作就不留到开发环节做。如果软件模式一定,那么框架做得好的话就一定可以能够让业务人员业务人员就做一部分属于开发人员的工作(这部分工作本就该属于业务人员),那时大家就能体会到开发软件就如同做原型一样的乐趣了!

 

posted @ 2009-06-15 15:46 快乐学习 阅读(53) | 评论 (0)编辑

2009年6月13日

坚持是学习的最好方法

唐骏在《我的成功可以复制》中说到他招人的标准很简单,一个是工作态度,一个是学习能力。前一篇博文写的责任属于态度,这里我想谈谈学习。

经常有人问我是如何学习的,有什么办法可以学得更好?我认为学习最好的方法其实很简单,那就是坚持,坚持学习坚持实践坚持思考

每天基本上都要学习,坐公交时会拿着手机看电子书,平时工作多加思考,晚上会根据自己对技术的判断进行知识的搜集和学习,我从工作到现在就是这么一直坚持学习的,我很多大学同学都不太相信:)

学习如同加班,也是在业余时间付出额外精力,只不过是学习是主动,加班是被动的。不停的学习,就和不停的加班一样,会使我们处于一个满负荷运作的状态,不可避免的在某一时刻会感到劳累,这时我会停下来休息,和家人去外面度度假,或者连续打几天游戏,用一些办法来舒缓一下疲劳。其实这只是体力带来的疲劳,还有一种疲劳是只见不断学习而不见成果的假学习。这时就要尽量抓准时机坚持实践,只有通过实践回报不断学习的毅力才能达到真正的快乐学习。

而不断的学习、实践是要基于某一些内容来做的,我们不能太贪心,什么都想做,这时就需要不断的坚持思考,思考存在哪些问题,思考自己能解决哪些问题,怎么通过学习和实践来解决。

在确定了某个领域的问题后,就可以通过很多方式来进行学习了:

1 blog订阅:对感兴趣的blog进行搜集,每天都会花一些时间来查看,以便持续学习和关注。《如何阅读一本书》中说到太多的资讯就如同太少的资讯一样,都是一种对理解力的阻碍。当我们订阅blog一定时期后,你会发现已经blog列表已经很长了,这时就需要进行整理一下,否则会发现自己像无头苍蝇一样看很多内容。大家可以通过很多blog订阅工具,我喜欢用google reader来订阅blog。

2 书籍:书籍一般都是经过作者大量思考和实践总结的一些知识,通过别人的总结可以系统的进行学习,这也是我对不熟悉的知识进行系统学习的一个主要途径。现在好多电子版书籍都可以通过网站找到,也可以在豆瓣上管理自己的读书数目

3 网络搜索 :这是我们大家都常用的方法,一般用来解决当前遇到的问题

4 还有其他一些方法,如写blog、写示例、研究现有产品、给其他人培训和交流、实践中反复思考验证等

posted @ 2009-06-13 17:52 快乐学习 阅读(81) | 评论 (1)编辑

2009年6月11日

责任不仅仅是只做份内的事

  责任心是每一个职员、管理人员、家庭成员都应该具备的素质,在身边也看到很多都是非常有责任心的人。baidu上这么解释责任是指分内应做的事,如职责、尽责任、岗位责任等。有时我们是按照份内应该做的事,但最终可能出现的结果是负责任了但没有取得好成绩。所以我觉得有时候从最终结果来看,责任不应该只是做分内的事情。

  在我以往工作中就有过所谓的“责任”,即使当前的工作与自己意愿不一致时也非常尽心,跟随着大部队加班加点,但最终没有给公司客户带来什么实质的作用,有时想到责任,我反而觉得责任不只是以往的定义,只做分内的事情,有时我们需要停下超负荷的脚本,静下来思考一下达到目标的更好方法,坚持自己的想法,而不只是循规蹈矩的只做份内的事情。有了对责任的这个定义后,有次工作中我竟然会拒绝接受一部分工作而专心做自己认为该做的工作,后来自认为还很满意,比起以前所谓的“责任”要好得多。所以,责任不仅仅是只做分内的事,有时需要去除部分责任,扩充一些责任,对责任做到真正的负责。

 


 

posted @ 2009-06-11 21:35 快乐学习 阅读(67) | 评论 (0)编辑

2009年3月28日

从横向领域和纵向领域来谈业务和技术的关系

现在国内大部分管理软件公司有几类,有的靠关系拉单子,有一单作一单,技术对它们来说不重要,而关系永远是第一。有的专注于用户需求,摸透用户业务,这类公司对业务的关注度很高,也就是横向领域上,业务排在第一。还有一类就是已经在行业很有知名度,要做行业内的专家,公司这时已经认识到了业务和技术的共同重要性,平台概念也主要在这类公司提出。软件工厂主要针对的也是在第三类软件公司下的应用。

在《软件工厂方法》一文中,我介绍了领域工程的基本介绍,领域工程由横向领域和纵向领域组成。平台概念很早就有,我认为对管理软件来说,平台就是能够在纵向领域上研究透业务的基础上使用横向领域的成果来一起来搭建一个满足用户需求的应用。
1. 纵向领域(vertical domain):根据系统类别而组织的领域。如预算软件、材料管理、合同管理、企业报表系统等。
2. 横向领域(horizontal domain):根据软件部件的类别而组织的领域。比如元模型引擎、报表引擎、工作流引擎等。
3. 领域之间有3中类型的关系:
a) 包含:比如成本管理软件包含了材料管理系统
b) 使用:比如管理软件都使用报表引擎,OA系统都使用工作流引擎
c) 类似:领域之间侧重点不同,但有很多的相似性,通过深入研究一个领域,可以取得对另一个领域的更好理解。比如报表引擎中对于表达式解析和索引部分可能与数据关系计算引擎类似。
大部分书籍也是像以上那样简单介绍一下基本定义,以下我从它们在产品线开发中的关系来发表一下看法。

 

经常有人讨论业务和技术的关系,希望争论出到底哪个更重要。如果从商业角度来说,最终的目标都是通过满足客户的需求实现双赢,而业务和技术都是实现 这个大目标的方法和工具而已,业务的深入是让我们能够做正确的事情,技术是让我们能够使用适合的解决方案来正确的做事情,两者必须协调一致才能实现最终的目标。

在认识了这两个领域都很重要的前提下,公司观点不一样,投入可能会出现三种情况,先业务后技术,先技术后业务,技术和业务同时进行。

  • 先业务后技术

  认为业务是技术应用的前提,所以必须完全弄清孵化了业务后才开展技术工作。当业务随着投入有所进展后,开发技术也越来越多不只是简单的增删改了,很多技术其实本应该是由纵向领域去解决的事情了,一年半载就这样过去了,本想着这样对付过去了,等业务请出来再技术重来,但是随着业务深入,用户的使用越来越多,销售和用户已经不能在等你重新进行纵向领域的应用了。先业务后技术的方向,在不是很好管理下即有可能变成了只有业务了,但是会出来产品。

  • 先技术后业务

  认为软件公司没有技术是不行的,所以技术优先。在技术上投入,Vista来了研究Vista,新的语言出现了研究新的语言,派专人进行研究,这种方向下会出现两种结果。如果研究人员本身目标明确,技术可能会成功研究并应用回报公司,也有可能遇到一个本身目标就不明确的研究人员,不知道研究的东西有什么用处,越研究反而越茫然,结果导致公司误认为这个对公司没有什么价值,最后就不了了之。所以先业务后技术的方向,在不是很好管理下即有可能变成了只有业务了。先技术后业务的方向,运气好的话会皆大欢喜,运气不好的话会没有人和成效,反而可能会把有用的技术当成没有的东西。

  • 技术和业务并行

  认为技术和业务是互相关联,缺一不可的,所以会在技术和业务上分别投入人力,并随着回顾两边的情况,不断协调进展。架构框架设计在了解部分需求下就可以进行了,技术的实现对业务也会有影响。在并进过程中,会出现先分后合的情况,因为开发产品时,业界已经有很多模式可以应用。比如你做企业管理软件,做OA,则工作流引擎,报表引擎等纵向领域必须有,公司可以在这方面先期投入而不用等到用户马上要了再来开发。

以上三种方向,我们该采取哪一种呢,我想这个需要视企业情况来看,如果企业发展初期,那么先业务和技术,先把业务吃透了,提高企业在行业内的知名度比吃透技术要紧,对于已经发展不错的企业,则应该采用技术和业务并进,不断的在业务和技术两方面协调发展。而如果企业已经衣食无忧,那么可以先技术后也业务,因为在业务不是很明确的情况下,技术也可以带动业务的发展。

技术和业务并进在第三类公司可能占多数,所以我们在投入时也需要认清他们的关系,哪些该并行进行,哪些该先后串行,不同领域由哪些人用什么方法完成,进行过程中如何不断回顾提炼方法。做开发和其他事情一样,开始之前没有具体的目标是绝对不行的,没有目标,推进研究像前是没有必要的,毫无意义的,但是一旦有了目标就不同了,有了具体目标后就算研究进行不下去了,也有那个具体的目标作为前进路线上的防线,指示着要走向哪里。有时候目标也会变化,或者更高,或者有所降低,如果目标更高了,当然相应最终结果也会更好。

软件产品线范围很广,有技术、管理、人员各方面的内容,包括纵向领域和横向领域,每个领域里面又包含很多领域。我们在开始之前又该如何确定我们的目标呢?一般制定大目标时,都会通过将目标拆解为多个小目标来细化,然后由不同的人各自实现小目标,在实现过程中并不断的回顾小目标对大目标的影响。

在《软件工厂方法》中讲过产品线的四个核心:范围、通用性、可变性和扩展点。纵向领域提炼出721,横向领域为纵向领域提供支持,比如基础设施的支持(各个需要的引擎)最好先期投入,这样当业务进展到一定阶段时,技术的支持就会很顺利了。

 

如果我们知道了作企业化信息管理软件,工作流、报表必需要存在,那么我们可以先期投入人力解决这一块。但是我们又如何保证这些小目标的投入可以给公司带来真正的回报呢。我想每个小目标都需要先从以下几点明晰自己的目标:

  • 愿景和任务:是否能够使用一句话简单的说明自己的愿景和任务
  • 涉众:谁是你的客户
  • 问题:关注哪个领域或者问题
  • 业务价值: 提供什么价值?产品的价值是在大蛋糕中的哪一块?
  • 如何度量成功: 用什么来表示成功?
  • 产品线: 给产品线提供了什么?

 

以下两篇为我以前关于技术和业务的简单观点,相对于上面的浅显一些:)

再谈技术和业务的关系    

业务、技术和语言的关系

posted @ 2009-03-28 14:00 快乐学习 阅读(1362) | 评论 (4)编辑

2009年3月23日

不要在考虑需求之前更多的在意你的职业镀金

软件架构师应该知道的97件事”旨在“为全世界的软件架构师提供洞察力和指导”:每条公理都是给软件架构师的一条建议,内容从维护场景到与合作者沟通。有时间我将逐个翻译一下

1 Don't put your resume ahead of the requirements

As engineers we sometimes recommend technologies, methodologies and approaches for solving problems because deep down we want to have these on our resume and not because they are the best solution for the problem. Such decisions very rarely result in happy outcomes.

作为工程师,我们在解决问题时提出的技术、方法和方案时实际上是为了让自己履历上拥有更多的资本,而不是应为这是解决问题的最好方案,这样将往往很少能有成功的结果。

The best thing for your career is a long string of happy customers eager to recommend you because you did the right thing by them and for the project. This goodwill will serve you orders of magnitude better than the latest shiny object in the latest shiny language or the latest shiny paradigm. While it is important, even critical, to stay abreast of the latest trends and technologies this should never happen at the cost of the customer. It’s important to remember that you have a fiduciary duty. As an architect you have been entrusted with the well-being of your organization and its expected that you will avoid all conflicts of interest and give the organization your undivided loyalty. If the project isn't cutting edge or challenging enough for your current career needs then find one that is.

     工作中最好的事情是有很多用户因为你为他们的项目做了正确的解决方案而乐意推荐你,这样的好信誉比起会用最炫的语言要有益得多。虽说掌握最新的技术和发展趋势非常重要,甚至对非常关键,但是你应该牢记你的职责是为客户服务,需要为客户提供最好的解决方案,而不是牺牲客户的利益来提高自己的技术。作为一名架构师,组织非常信息你,并且期望你能够处理所有利益冲突,对公司也能够保持高度的忠诚。如果当前的项目对你职业生涯发展没有推进或者不具有挑战,那么最好的办法是去寻找一个满意的项目。


If you can't do that and you are forced to be in such a project, then you and everyone else will be happier using the right technology for the customer rather than for your resume. It’s often difficult to resist utilizing a solution that is new and cool, even when it’s inappropriate for the current situation.  

      如果你找不到合适的项目,并且被迫在这样的项目下工作,那么你和大家应该乐意使用正确度技术为客户提供解决方案,而不只是为了自己的履历拥有更多的技术。即使当当前形式不利于使用新的或者酷炫的技术时,抵制利用这些带来的诱惑也是比较难的。


With the right solution, the project will have a happier team, a happier customer and overall far less stress. This will often give you time to go deeper into the existing older technology or to learn the new stuff on your own time. Or to go take that painting class you always wanted to do. Your family will love you for it, too - they'll notice the difference when you get home.

     使用正确的方案,项目将有一个快乐的团队和满意的客户,大家也感觉不到什么压力,这可以让你有更多时间深入精通已有技术或者有更多自己的时间去学习新的技术,甚至有时间去参加绘画兴趣班,当你回家时你的家人也能感觉到你的变化,并更喜欢你这样。

 

Overall always put the customer's long-term needs ahead of your own short term needs and you won't go wrong.

     总的来说,牢记用户的长期利益高于你个人的短期利益是不会有错的。

 

posted @ 2009-03-23 09:57 快乐学习 阅读(63) | 评论 (0)编辑

2009年2月2日

代码、口头交流与文档都很重要!

  《领域驱动设计》书中在书面的设计文档小节中讲到:每个敏捷过程对于文档编写都有自己的原则,极限编程提倡不适用额外的设计文档,让代码自己来表达含义,但将代码作为设计文档有他的局限性。会使读者负担过多的细节问题。尽管代码的行为是明确的,但并不意味着是明显的。一个行为背后的含义会很难表达出来。团队内部大量的口头交流能够给代码阅读提供一些上下文环境的分析和指导,但也是暂时和局限的,并不只是开发人员需要理解模型。口头交流在语义上弥补了代码的太过细节的问题,但任何规模的团队还是需要能够提供稳定性和共享能力的书面文档,然而编写能够真正帮助团队生产优秀软件的书面文档是一个挑战。

  我认为代码、口头交流和文档都很重要,我们不能绝对的站在任何一边。在敏捷过程中不能要求非常详细的文档,也不能误解敏捷开发而不要任何文档。《敏捷文档》描述了面对面沟通和文档的一些主要特点:

Face-to-face communication Documentation
Direct interaction
Face-to-face communication allows
for quick question-and-answer
cycles. You ask something, someone
answers, you ask back on a specific
detail, you get a more precise
answer, someone else offers their
ideas and so on. Face-to-face
communication involves people in a
very direct way.
Self-determined pace
Different people grasp information
at different speeds. Many people
find they still have questions when a
discussion is over – questions they
didn’t think of in the heat of the
debate. Documents, however, allow
people to read at their own pace,
going back and forth through the
material as they need to.
Non-verbal communication
People don’t communicate through
words exclusively. A large part of
communication takes place in a
non-verbal way – through sound,
gestures and subconscious body
language. These things are possible
only through face-to-face
communication.
Introvert communication
While some people love to engage
in debate, others don’t. Introverted
people are sometimes painfully
silent during discussions, though
they may have a lot to say. They
have their say more easily when
they are given the chance to write
things down, as this allows them to
have second thoughts and take time
to reflect.
Personal involvement
Talking to each other means getting
to know each other. Building trust
happens much faster among people
who are in the same room than
among people who communicate
through writing only.
Scalability
Documents can be made widely
available. You can address an almost
unlimited number of people at a
time. Moreover, documents can
reach the members of a distributed
team – people working in different
places.
Fast availability
In a well-organised project, there
are Experts In Earshot (Cockburn
1998) readily available for
answering questions you may have.
Discussions can come up on the
spur of the moment. Documents
may be available as well, but time
goes by until documents are written
and made available.
Long-term availability
Once a project reaches its end the
team disperses – experts may no
longer be available. The software,
however, will still need maintenance
or even refactoring. Only written
documents are available beyond the
limits of the actual project.


  通过以上对比可以发现,面对面沟通和文档并不是对立的,而是互为补充的,就像我们读书学习一样,我们需要从书本和老师的授课中学习。

posted @ 2009-02-02 20:26 快乐学习 阅读(108) | 评论 (0)编辑

2009年1月31日

The Model Driven Software Network

国外的一个模型驱动软件开发的讨论社区The Model Driven Software Network
这个社区讨论的都是模型驱动开发相关的话题,虽然建立不久,但加入的人越来越多,建立群组的是Mark Dalgarno
以下是一些讨论:

Textual v Graphical models

What is the best open source MDD code generation tools ?

What about pragmatic approach to model driven development?

Book Recommendations on MDSD and complementary areas

Advocating Model Driven Software Development

Model-Driven Development is dying - discuss

How can we make this succeed?

posted @ 2009-01-31 10:37 快乐学习 阅读(45) | 评论 (2)编辑

2009年1月11日

DSL应用的优点

Visual Studio DSL工具特定领域开发指南是一本专门介绍微软DSL工具的一本书籍,其中介绍了应用DSL可以带来如下一些优点:

1. 让我们有能力在问题空间工作,避免以往用通用语言表述问题容易犯的一些错误,降低了犯错的机会
2. 通过在问题空间工作,可以让不熟悉如何实现技术的人,包括商业人士,也能够更了解模型。
3. 使用DSL表达的模型,可以在问题空间这个较高的抽象层次进行验证,这意味着可以在开发周期的更早期发现因为理解和表述而造成的错误。
4. 可以用模型直接模拟一个解决方案,从而立刻得到关于模型适合性的反馈。
5. 可以用模型配置一个包含多种不同技术的实现过程,从而降低使用这些技术实现一个解决方案的技术难度和工作量。
6. 可以用模型生成其他模型,配置其他系统、网络和产品,或许还可以配合别的技术(例如向导)一起使用。
7. 特定领域语言提供特定领域的API来操作它的模型,从而提高开发效率。
8. DSL产生的工作单元不一定是技术实现的工作单元,一个合适的模型可以用来生成构建脚本、订单、文档编制、原料清单、计划或法律合同的框架。
9. 一个模型中具备了重要的业务知识,将解决方案从一种技术迁移到另一种技术,或在同一技术的不同版本之间迁移,就变的相对容易。一般通过适当修改生成器或解释器就可以做到。

 

posted @ 2009-01-11 13:59 快乐学习 阅读(123) | 评论 (0)编辑