标签：软件工程

（转自：http://www.matrix.org.cn/resource/news/463_Up+Front+vs+Continuous.html）

设计已死？ 预先设计 Vs. 持续设计

chris 发表于2006-01-18

作者:chris 来自:matrix

评论数:13 点击数:775

摘要:

在很多刚开始接触XP的人看来，XP仿佛给软件设计判了死刑！在XP中，软件设计不仅被讥笑为"Big Up Front Design"。甚至一些软件设计技术，比如UML（统一建模语言）、灵活框架技术、模板设计等似乎都不那么重要了。 文章工具

收藏

发表评论

复制链接

在很多刚开始接触XP的人看来，XP仿佛给软件设计判了死刑！

在XP中，软件设计不仅被讥笑为"Big Up Front Design"。甚至一些软件设计技术，比如UML（统一建模语言）、灵活框架技术、模板设计等似乎都不那么重要了。

up-front design，也就是预先设计，需要提前考虑软件的整体需求，甚至必须预测到开发过程中软件需求发生的变化，这往往是很困难的。因为处理变更需求的方式之一是做灵活的设计，以便当需求有所变动时，你就可以轻易的变更设计。然而，这需要你对将要发生的变动有深刻的洞察力。甚至很多人开始专注于研究需求工程过程(requirements engineering processes)，希望得到更准确的需求以避免后面对设计的修改。但是即使朝这个方向去做一样无法解决问题。很多无法预知的需求变更起因于业务的变化。这是不能避免的。

而持续设计则完全相反。

通过不断迭代，持续设计可以在迭代过程中不断演进，从而适合新的需求。XP中有许多启动实践，其中最重要的是测试(Testing)和持续集成(Continuous Integration)。

然而，演进式设计可能因为特定的设计策略(ad hoc design decisions)和照成软件开发混乱而行不通，进入恶梦般的"code and fix"。所以，持续设计也被很多人讥笑，说这是"黑客式开发"。

关于，预先设计 和  持续设计，你有什么看法呢？ 正在使用XP的人，发表下见解吧!

本页面地址:  

→用户评论列表

#7832 评论作者： littlebat 发表时间：2006-01-20 10:40

　　不懂xp，也不懂设计，只知中国有“中庸”一词很有道理。我觉得我们征对任何一件事要寻求适合这件事的平衡点。

#7819 评论作者： softtiger 发表时间：2006-01-19 10:46

在我看来，当项目具有一定的复杂度时，结论就非常明显了。象一般的应用，由于采用了现成的框架，设计工作很小（业务上的调查还是不能避免的）；对于嵌入式平台的开发，若没有一个相对较长的预研工作，二周左右的初始迭代只能是个笑话。总而言之，要视项目的具体情况，灵活采用相应的开发过程。

#7796 评论作者： cleverpig 发表时间：2006-01-19 09:02

to li_nummereins:

完全同意你的见解。

#7786 评论作者： matrix_victor 发表时间：2006-01-18 04:45

有一定道理，不过预先设计还是很重要的。不过个人觉得预先设计可以尽可能做好，在实际进行中不断改进，也算是持续设计了。在此期间文档就没必要那么详细八股了，以协作人员方便交流为原则，等系统测试完成后在形成最后的文档，这样比较好

#7785 评论作者： li_nummereins 发表时间：2006-01-18 03:18

对待“过渡设计”，我们必须在初始设计阶段就做好沟通，做到需求驱动设计。这点是最最重要的。可往往很多项目都力争马上编码，这样做非常错误。我反对在具体技术实现上耍“学术”。只要是能够使用户满意，开发顺利的技术就是好技术。我们的目的是解决问题，而不是制造问题。

#7784 评论作者： topreap 发表时间：2006-01-18 02:41

可以讨论一下“过度设计”的问题，预先设计如果是过度设计往往导致项目延期。。。。但如何避免过度设计关系到管理上的问题，特别是项目经理的管理能力、经验。。。。。

#7782 评论作者： goodsuperstar 发表时间：2006-01-18 02:05

预先设计总是有必要的

首先对整体有个大致的了解，明确方向，起着纲举目张的作用

但是现在很多预先设计已经走向极端，将一些后期考虑的细节问题过多的放到预先设计中，造成整个项目工期延误。

#7781 评论作者： usherlight 发表时间：2006-01-18 12:55

我还是认为预先是重要而且必要的.

否则后期的改动难以进行.

#7780 评论作者： ginger547 发表时间：2006-01-18 12:32

我非常的同意 持续设计的做法!我也很欣赏 write test first ,write code second ,then refactor!

#7779 评论作者： tcmak 发表时间：2006-01-18 11:33

其實 XP 或者 Agile 等方法, 其重點在於減少 "浪費", 此話其實也很 "禪", 像大道理多於執行手則, XP, 及其他敏捷開發界的人士都常說不要把這些東西當成為必然, Design 是要做的, XP 或者其他敏捷開發方法也沒說不要做任何設計工作, 但是, 我們最不想看到的就是花太多時間去做什麼 UML, Data-flow diagram... 或者其他 "浪費" 的事情.

什麼是 "浪費" 呢? 就是對客人沒用的東西, code 對客人有用, 因為有了 code 系統才會行, 但是一個 data-flow diagram 對客人又有多少價值呢? 敏捷開發中沒有反對做什麼 diagram, 只要有用就可以了. 而且重點是, 就算要做什麼 diagram 都好, 都不用把他們做的像什麼嚴謹的文件, 在白板上手畫的已經很 "足夠" 呢

如果管理層或者客戶真的要什麼嚴謹的文件, 就盡量用 program generate 出來呢.

再者, 敏捷開發也講求 Refactoring, 不是要做少一點 design, 但 Refactoring 也是面對避免不了的改變其一個 "適應" 方法, 使到 code 可以更易維持, 系統亦更易理解

XP界其中Ron Jefferies 其中一文講及 Design:

http://www.xprogramming.com/xpmag/whatisxp.htm#design

Design 在 XP 中也有重要地位, 而且是以不段改善和進化的形式去體現, 如果就設計己死, 那我認為是 "Big Up Front Design is Dead".

XP 或者所有敏捷開發都很講求 "紀律", Coding Standard 是其中一重 "紀律" 的體現, 他們也對 testing 有很高的要求的呢 (上文也有提到測試的要求), 而絕不是黑客式開發. 短的開發週期就是希望不要讓隊伍陷入 "Analysis Paralysis"

最後... "Big Upfront design" 所帶出的主要問題是如何減少在開發過程中的 "浪費", 什麼才是 "足夠", 對客人有 "價值", 如何可以迅速地 "適應" 轉變, 只要掌握到, 那你自己也可以有一套自己敏捷的方法.

另外, 如果還是對 "Big Upfront Design" 念念不忘, 又或者 XP 那樣感覺還是不太舒服, 可以看看以下文章, 提及的 design 比 XP 多, 我想也比較易讓大家理解.

http://www.agilemodeling.com/essays/amdd.htm

(不好意思, 兩篇文章都未有中文版)

#7778 评论作者： icess 发表时间：2006-01-18 11:16

January 15, 2006

Continuous Design

Continuous design, also often called evolutionary design or emergent design, is an alternative to up-front design of software. Traditional up-front design (Big Up-front Design, as extreme programming labels it) involves anticipating the requirements of the software, and even more difficult, how the software's requirements will change over time. Then, based on these assumptions, a design or architecture is put in place that allows developers to efficiently implement the needed functionality in a way that leaves the software open to the anticipated later changes.

Continuous design takes a different approach.

By using an iterative, agile approach to software development, the design of an application's code can evolve over time instead of being specified up-front before development begins. In continuous design, one always designs just for the current iteration's required feature set. Code the new features, then refactor away any code smells. If a new feature cannot be implemented because of the existing design's limitations, then refactor the design into something that will accommodate the new feature. But, stop there! By avoiding the temptation to design for anticipated future change, one keeps unnecessary complexity out of the system. How often have you designed the use of a strategy pattern to accommodate an imaginary need to swap out implementations of a particular interface? But the multiple implementations never materialize.

来源:http://java.about.com/b/a/235746.htm

#7774 评论作者： jslzl 发表时间：2006-01-18 09:12

楼主的疑惑可以理解，计算机的技术和手段日新月异，面对这些技术，甚至名词，让

人有时不知如何下手。就开发流程来说，有传统的rup过程，xp等。但是bob （Expert One-on-One J2EE Development develop without Ejb 和Spring的作者）的一句话倒是让我深刻：寻证方法也就是说我们应该根据我的项目的经验去寻找更好，更快的解决方法，如何天天琢磨别人的思想，呵呵，很累的。所以我常说“去你的，大师”。其实那些所谓的大师在能够提出些思想方法，不过是在反复总结自己和别人罢了。

所以，楼主要是愿意比较xp和传统rup等，应该至少先使用一种开发过程，并深刻理解，然后才能对比吧。对我而言，开发过程两种方法同时都在使用，怎么快就怎么来吧!

一席废话，呵呵。欢迎拍我

#7773 评论作者： li_nummereins 发表时间：2006-01-18 09:11

预先设计及其重要。这就像打天下，开始必须要有明确的纲领，将主要矛盾突出。这个阶段不能关注细节，要站在战略的高度思考问题。设计以方向性的概要设计为主，以主要、现存的、明显的需求驱动设计。持续设计专著细节，但对待已经存在好的预先设计必须采取迭代式补充，并充分利用绩效，挣值等方法不断进行校验。要知道，欲望是无限的，资源是有限的。要干好一个项目，最主要的是知道那些必须作，哪些决不能做。

  Today,I have learned chapter 11 of this book-I/O and control design.

I think the control design with our LD project,there are three tyies of user in our program,they are admin,register user,non-register user,and we should add another type of user is block-manage user.There isn't affair recording function in the current version of LD program,we should add it in our future program.

  The original resource of the input and output design is DFD or sequence diagram.

  The message that send by actors to the object in the system is the resource of input design.and versus,is the output design.

chapter 12 human-computer interaction

  this chapter is the extend of I/O in the chapter 12,and it throughs emphasis on the human self.From the standard point of user,the interface of application system is system itself.

  In this phase,the interface class has been imported,and it should be embed in the classes of question domain in the sequence diagram and other diagrams.

  I think,the jsp pages should be imported in the sequence diagram or other diagrams.

execute and support

chapter 13 RAD and developement base on component

  1.spiral development approach:the initial plan should include the global plan of whole project.

  2.I think,the jfc and j2se,j2ee and struts,hibernate are all the classes of object-framework,so the struts class should be imported at design phase.for example,the sequence diagram.

  3.There are only two typies of component framework,they are Common Object Request Broker Architecture(CORBA) and Distributed Component Object Model(DCOM) said in this book.But,is the EJB or JavaBean component framework?

chapter 14 execute and support

 from this chapter,I knew the key of success ERP is the people in the company.

  The future of ERP is the deep and wide integrity.the increase point are the supply-chain management and business intelligence.

  I think,there is BPR,should there be LPR(Learning Process Reengeering) too;there is ERP,should there be LRP(Learning Resource Plan) too.but,where is the LPR or LRP?They are in our learndiary.com!

1.unified process:

1)at a minimum,all process will produce class,sequence,and use-case diagram;

2)chapter 2:

this chapter examines how uml,coupled with a sound software process model,such as the unified process,can produce...ever-changing...

3)chapter 3:establishing the project vision:

 inception phase:

(1)actors:

 actors are usually thought of as human beings,but they may be also other system,timer and clocker,or hardware devices.actors stimulate the system and are the initiators of events;they also can recieve stimuli from the system and in this case are considered passive.

(2)events list and events table:

external events and internal events

(3)business rules

4)chapter 4:use-cases

(1)getting to use-cases

features->event list->event table->use-cases

(2)happy.alternative.expective pathway(I don't know them.)

(3)shadow use-cases:

the use-cases that not a "functional  requirement".

they includes:security,parameter maintenance,audit,archiving,architecture infrastructure

This is a question:Are there use-cases involving the struts framwork?

(4)the increment plan for the project

this is the end of inception  phase,the result is requirement model.

22:06 05-1-5 p111

16:03 05-1-10

chapter 5 class

1.This is the begin of the elaboration phase.

2.this chapter tell us how to build a class diagram,includes identifing the class,three typies of class:entity,boundary,control class,relationship of classes.

3.I have seen the jsp is a special boundary class that extends from servlet.

the fruit at the end of this chapter is the analysis model.

I found a difference between the traditional model and the Unifield Process:  traditional model:analysis phase:event table,use-cases,class diagram,interaction diagram,state diagram;design phase:design class diagram,database,interface.

Unifield Process:first inception phase:events table,use-cases,increment plan;

elaboration phase:class diagram,dynamic diagram(interaction,state...),database,interface...

Maybe,I havn't uderstood the Unifield Process really.

chapter 6 building prototype

1.this chapter is in the elaboration phase.

2.tell us:

  1)how to build a user interface prototype?

  2)screen structure chart

  3)get feedback from user which studing the user interface prototype.

chapter 7 dynamic diagram

1.in the elaboration phase

2.tell us:

  how to build all kinds of dynamic diagram:interaction diagram(sequence diagram,collaboration diagram),state diagram,activity diagram,and some non-UML in the design named usage matrices.

3.A sentence in the end of chapter 8 that is:After the requirements have been solidified and the design work has begun, three architectures must be considered.from this sentence,I knew the fruit in the chapter 7 is the result of traditional analysis phase.

chapter 8 exection architecture design

1.in the elaboration phase

2.the java,jsp,j2ee,javabean,EJB,all of these concrete technique are presented in this chapter,the result of this chapter is exection architecture  of the project.

3.the system structure:

there are six logical tier:

Presentation Services,Business Context Services,Business Rule Services,Data Translation Services,Data Access Services,Database Services

21:40 05-1-10

p253

12:18 05-1-11

p280

the address of this book:www.jacksonreed.com OR www.awl.com

13:39 05-1-11

p293

the summary of chapter 9-12

chapter 9 data persistence: store object

1.in the elaboration phase

2.map the relationship to the ralation database:

simple Association,inheritance,generalization/specialization,aggregation and composition,reflexive

3.

  This week,I have learned chapter 7-10 of this book,this is the second time  learning it.

  There are four typies of diagram in OO analysis.They are class diagram,use-case diagram,interaction diagram(sequence diagram or collaboration diagram),state diagram.

  I have a question is if struts class should be imported in at this phase.I learned a book there is a seqence diagram,it includes struts class.But,I think,we should know what should we do in the analysis phase.the result should be used in any oop design,for example:.net.So,I think struts class shouldn't be imported at this time,but design phase.

  The state diagram is used to create method in a class.But I don't know it clearly.

  After analysis phase,We should choose a plan according with the environment and post it to the manage department.

  In design phase,the package diagram is used to dividing sub system.at this phase,We should use state diagram to write pseudocode of a method's logic of a class.

  The most valuable knowledge come from chapter 10--datebase design for me.especially oodb.The ability of OODB is exciting for me.It can support self definition data type and inheritance and other new charactor that relation db can't support.I should learn it later.

  In our LD project,We should use another db type it between relation db and oo db called hybrid object-relational DBMS.

  In hybrid object-relational DBMS,if there are several child class for a parent class. the child class can be processed in two ways.one is using a table that represent a super set of all these class,another is every child class is a table and the key of this table is outer-key(I can't understand it).

  This week,I have learned chapter 7-14 of this book,this is the second time  learning it.

  There are four typies of diagram in OO analysis.They are class diagram,use-case diagram,interaction diagram(sequence diagram or collaboration diagram),state diagram.

  I have a question is if struts class should be imported in at this phase.I learned a book there is a seqence diagram,it includes struts class.But,I think,we should know what should we do in the analysis phase.the result should be used in any oop design,for example:.net.So,I think struts class shouldn't be imported at this time,but design phase.

  The state diagram is used to create method in a class.But I don't know it clearly.

  After analysis phase,We should choose a plan according with the environment and post it to the manage department.

  In design phase,the package diagram is used to dividing sub system.at this phase,We should use state diagram to write pseudocode of a method's logic of a class.

  The most valuable knowledge come from chapter 10--datebase design for me.especially oodb.The ability of OODB is exciting for me.It can support self definition data type and inheritance and other new charactor that relation db can't support.I should learn it later.

  In our LD project,We should use another db type it between relation db and oo db called hybrid object-relational DBMS.

  In hybrid object-relational DBMS,if there are several child class for a parent class. the child class can be processed in two ways.one is using a table that represent a super set of all these class,another is every child class is a table and the key of this table is outer-key(I can't understand it).

  The main content of Chapter 11,12 if I/O,control design,chapter 12 emphasis Human-Computer Interface design base on chapter 11.It present a thinking is "all is for user".HCI in OOP design can be produced from sequence diagrams.

  The part four of this book tell us knowledge about executing and support,there is chapter 13-15 in this part.

  Chapter 13 tell us RAD and component-based development.RAD cover the knowledge include tool,technique and developing model.

  The risk management of project should put in our mind when developing a project,especially take spirial development approach,like our LDP.In this chapter,I knew the struts is a object framework,like J2SE,J2EE,Hibernate,etc....I knew a object framework should be decided before detail designing also.

  Chapter 14 tell us software package and ERP.Software package schema is the tendency now.The future of ERP will include supply-chain management and business intelligence.I knew an ERP system called SAP in this chapter.

  I have read chapter 2-5 in e-book named <<javauml>> roughly.

  From these chapter,I knew some knowledge below:

  1.the development flow in Unified Process is a spirial development approch;

  2.the working flow in an iteration of project is:collect requirement->event list->use-cases diagram->class diagram...

  3.there is a type of use-case named shdow use-cases,it includes:Security,Audit,Parameter,Maintenance,Archiving,Architecture Infrastructure.

  4.the jsp page is a boundary class that we could indirectly say it will be java classes implementing the servlet inerface.

  next week,I will finish the last chapter of <<system analysis and design>>,and read the remainder content of <<javauml>> roughly.

  We will learn system analysis and design when processing our new learning platform project.

  This week,I have learned chapter 7-10 of this book,this is the second time  learning it.

  There are four typies of diagram in OO analysis.They are class diagram,use-case diagram,interaction diagram(sequence diagram or collaboration diagram),state diagram.

  I have a question is if struts class should be imported in at this phase.I learned a book there is a seqence diagram,it includes struts class.But,I think,we should know what should we do in the analysis phase.the result should be used in any oop design,for example:.net.So,I think struts class shouldn't be imported at this time,but design phase.

  The state diagram is used to create method in a class.But I don't know it clearly.

  After analysis phase,We should choose a plan according with the environment and post it to the manage department.

  In design phase,the package diagram is used to dividing sub system.at this phase,We should use state diagram to write pseudocode of a method's logic of a class.

  The most valuable knowledge come from chapter 10--datebase design for me.especially oodb.The ability of OODB is exciting for me.It can support self definition data type and inheritance and other new charactor that relation db can't support.I should learn it later.

  In our LD project,We should use another db type it between relation db and oo db called hybrid object-relational DBMS.

  In hybrid object-relational DBMS,if there are several child class for a parent class. the child class can be processed in two ways.one is using a table that represent a super set of all these class,another is every child class is a table and the key of this table is outer-key(I can't understand it).

在看<<系统分析与设计>>这本书的同时，我开始看javauml这本英语版的电子书，上周看了１０多页，由于英语水平有限，懂了个大概意思。这本书的起点较低，就是不懂uml和oop的人也可使用，只要有点java基础。作者先前写vbuml。

    这本书的重点是uml，用于jsp+tomcat的非商业应用，没有讲struts。（ucommercially available through Rational Software called the Unified Process and one from my own experiences called Synergy. The greatest emphasis will be placed on the Unified Process.）

    先讲了不应用uml的困境，然后讲了迭代和增量的区别。懂了个大概。

    我看这本书的目的是配合＜＜系统分析与设计＞＞的学习，用于把uml用于jsp程序的建模的实践。

    上周，看了这本书的第２－５章。

    心得如下：

    １、在项目管理中，与成员的充分、深入交流是至关重要的。可我现在连上网的时间都不能保证，看来，与大家的日常交流只有委托其他人了；

    ２、在基于迭代的开发方法中，蛛网模型（也是螺旋模型）是比原型法（增量模型）更彻底的迭代。可以最大程度的抗拒需求不定的风险，但是更难管理。原来yinhe给我提过螺旋模型，我当时搬照＜＜软件工程＞＞的自考书的概念，认为螺旋模型不适用于面向对象的开发方法，现在看来，我对螺旋模型的理解有问题了。我将继续探讨这个问题；

    ３、在需求分析阶段，有多种方法可以用来定义问题。对比我们的开发小组，我觉得可以采取调查表、qq访问等方式来进行，所以，我在章程中添加了开发小组成员如果两周内不回复调查表视为自动退出，不知道这有益还是有害于开发小组工作的开展；

    ４、在需求分析阶段，主要目的是明白问题域，回答让系统“做什么”的问题，因此不会涉及到具体的技术，也就是，需求分析的成果不仅可以用于jsp，也可以用于.net。

    我现在认为，在struts中的类应该在设计阶段引入，作为实施类。我觉得，在rose等工具中，应该可以自动引入某个类库。

    设计阶段与分析阶段的差异主要是类图的具体化，并且引入一些实施类，如界面等，并设计数据库。。。，但我现在现在还不知道jsp页面在设计中怎么处理，有一个英语电子书＜＜javauml＞＞我在下周可以看一下。我把旧电脑搬到乡下去了，不过不能上网。

    希望有朋友看了我的日记可以指出其中的错误，我在这里感激不尽。

    在把这本书大概的游览后，我准备结合我们的学习日记开放源码项目的需求分析来详细的学习一下这本书。

今天学习第一章：现代系统分析员涉及的领域，主要有如下心得：

    １、系统分析大部分工作不是程序设计，书中的系统分析员说她工作时的大部分时间是采访、报告、写信...

    ２、商业的信息系统类型：事务处理系统（TPS）、管理信息系统（MIS）、主管信息系统（EIS) 、决策支持系统（DSS）、通信支持系统、办公支持系统

    ３、系统分析员除了技术知识与技能，还需要商业、人际方面的，还需要诚实与道德

    ４、系统分析员会面临从桌面系统到internet的各种信息系统的配置。

    ５、系统分析员除了完成解决具体商业问题的信息系统，还有可能卷入企业的战略经营问题，如开发主管信息系统、业务流程再造（ＢＰＲ）、ＥＲＰ。

    ６、信息系统战略计划的结果：提交技术结构计划、应用程序结构计划和实施的时间帧。

    ７、系统分析员的工作会贯穿软件生命周期的整个阶段。

我们开发的学习日记是属于辅助教育平台，不在上面所说的商业系统之中，但是分析方法应该是通用的。

    对应商业系统所需的商业技能，这个系统的分析应该具有教育学习知识的技能，尤其是有关信息时代的自助式学习技能，这种技能是我现在严重缺乏的，可以通过两个途径补充：聘请这方面的专家作顾问、及时补充学习有关的知识。

    在学习日记的分析中，我们面临的分析任务是处在internet中的。

    我们在分析中，可以对应于商业系统的业务流程再造的概念，提出“自我教育流程再造”（STPR:self teching process reengineering）的概念，以新的信息时代的学习理论和学习实践，进行信息时代的自助式学习平台的建设。

    这个学习平台是一个通用的平台，应该为大家进行信息时代的自助式学习提供一揽子服务，为了建好这个平台，应该制定一个长期的战略计划。书中的落基山运动用品商店的战略计划用２００１－－２００４年这４年的时间来完成，我们这个平台的战略计划是什么？要用几年来完成呢？慢慢想吧。

       我今天买了一本＜＜系统分析与设计＞＞的书，６５元，John W.Satzinger Robert B.Jackson Stephen D.Burd著，朱群雄，汪晓男 等译。＜＜机械工业出版社＞＞＜＜中信出版社＞＞。我翻了好几天了，觉得还可以样。