概要设计怎么写(你想成为软件设计师吗) [转]

发表者付:
做软件到一定层次了,就要考虑到设计了,设计了很久,就是不系统,系统的设计需要一个记录,记录就用文档,那么对项目所有包括技术上的设计都记录下来,我们就可以理解为软件的概要设计了。

在需求明确、准备开始编码之前,要做概要设计,而详细设计可能大部分公司没有做,有做的也大部分是和编码同步进行,或者在编码之后。因此,对大部分的公司来说,概要设计文档是唯一的设计文档,对后面的开发、测试、实施、维护工作起到关键性的影响。
  一、问题的提出
  概要设计写什么?概要设计怎么做?
  如何判断设计的模块是完整的?
  为什么说设计阶段过于重视业务流程是个误区?
  以需求分析文档还是以概要设计文档来评估开发工作量、指导开发计划准确?
  结构化好还是面向对象好?
  以上问题的答案请在文章中找。
  二、概要设计的目的
  将软件系统需求转换为未来系统的设计;
  逐步开发强壮的系统构架;
  使设计适合于实施环境,为提高性能而进行设计;
  结构应该被分解为模块和库。
  三、概要设计的任务
   制定规范:代码体系、接口规约、命名规则。这是项目小组今后共同作战的基础,有了开发规范和程序模块之间和项目成员彼此之间的接口规则、方式方法,大家就有了共同的工作语言、共同的工作平台,使整个软件开发工作可以协调有序地进行。
  总体结构设计:
  功能(加工)->模块:每个功能用那些模块实现,保证每个功能都有相应的模块来实现;
  模块层次结构:某个角度的软件框架视图;
  模块间的调用关系:模块间的接口的总体描述;
  模块间的接口:传递的信息及其结构;
  处理方式设计:满足功能和性能的算法
  用户界面设计;
  数据结构设计:
  详细的数据结构:表、索引、文件;
  算法相关逻辑数据结构及其操作;
  上述操作的程序模块说明(在前台?在后台?用视图?用过程?······)
  接口控制表的数据结构和使用规则
  其他性能设计。
  四、概要设计写什么
  结构化软件设计说明书结构(因篇幅有限和过时嫌疑,在此不作过多解释)
  任务:目标、环境、需求、局限; Continue reading “概要设计怎么写(你想成为软件设计师吗) [转]”

[翻译]API设计黄金法则

API设计黄金法则

原文: http://programmer.97things.oreilly.com/wiki/index.php/The_Golden_Rule_of_API_Design
API的设计通常是一项艰巨的任务,尤其当设计的API非常庞大时. 如果你设计的API将会有成百上千的用户时,你要考虑今后应该如何扩展来避免不小心把客户端的代码搞挂. 除此之外,你还要考虑用户在使用API的过程中对你的影响.如果你的API类使用它内部的一个方法时,你要记得 – 用户可以通过子类复写(override)他,而这,可能会是灾难性的. 你将不能修改那些方法,因为用户已经这样使用它们了. 你今后的内部实现将无可避免的由你的用户来决定,而不再是你.

API程序员有各种各样的方法来解决这个问题,但最简单的还是禁止用户修改API.如果你用的是Java你可能会把所有的类都声明为final,如果用C#,则声明所有的方法为sealed.无论用什么语言,你都可以通过单例(singleton)或者静态工厂方法来避免用户复写代码,或者不当的扩展和使用你的代码.这些听起来很有道理,但,真是这样吗?

在过去的10年,我们渐渐意识到单元测试是一种非常非常重要的实践,但这一实践却并没有完全被整个行业所认可. 显而易见的是,大多数情况下,为一个未经测试的类编写测试用例时总是很难.你会发现使用了API的代码和API耦合的就像是上了强力胶一样.没有办法去模拟API类的行为,进而容易的测试API和你的代码之间的交互.

经过一段时间后也许会有改善,但只有我们在开始设计API时就考虑到测试问题.不幸的是,这可能需要你(API的设计者)多花一点时间 – 不仅测试自己的代码,还要考虑用户如何测试他们的代码. 这里就引出了伟大的”API设计黄金法则”: 仅仅给API写测试用例是不够的;你还要为使用API的代码写单元测试.只有这样做了,你才会在第一时间体会用户在使用你的API时进行测试时的种种问题.

让API易于测试的方法有很多.static,final和sealed并不见得是不合理的,他们有相应的使用场景.但意识到测试问题是很重要的,最好的办法就是自己去感受.一旦你这样做了,你将更加胜任各种设计挑战.

By Michael Feathers

为什么需要DTO

javaeye上有一篇帖子 – 为什么我的程序传递DTO
讨论了Domain Objec和DTO(Data Transfer Object)的关系,以及用Domain Object代替DTO的可能。我比较赞同其中的一个观点:

得出传递DTO不必要的结论,多半是因为应用过于简单,或者对于构建RichDomainModel缺乏经验导致的。完全OO的DomainModel,确实是值得追求的。

其实说来说去都是依赖谁的问题 – 是依赖Domain Object?还是只依赖服务层?这时就又有一个分歧了,Domain Object到底在你的心目中有多重?而这个问题在每个人的脑子都是不一样的。有时候这样的出发点的差异只会造成每个人都在固守己见而不去关心理解别人的着重点,最终变成毫无意义的争论。而没有对不同的情况系统的分析。

基本的几个着眼点:
1.觉得重复代码很多 – 想办法去写个类似hibernate的工具去帮忙 – 个人觉得已经从山脚下就跑偏了,只能绕着山脚跑
2.Domain Object是充血还是贫血
3.对Domain Object的依赖应该到persist layer,而服务层是面向更多不同的client(local的,remote的)去调用的,所以要避免对Domain Object的依赖,因为可能会暴露业务逻辑,或者存在Domain Object生命周期的问题(比如lazy load)。我觉得这一点却是要看的,如果认为Domain Object 只= (PO)Persistent Object,那么后一种论调可以合理解释。但是如果是纯粹的领域模型设计,那么所有的东西都应该也可以依赖 Domain Object,即便增加了DTO这个(说白了可以理解为Domain Object的proxy的东东)也还是存在Domain Object频繁变化带来的问题(这是个伪问题,领域对象变化的影响当然要“深远”,不可能用DTO来避免)

所以我的结论仍然是: It depends!

设计者与自我设计

在2007年度最佳产品与设计:人本界面里看到这句话

如同控制论之父维纳对于群体目标的论断中谈到的一样,设计者不仅要从事产品的设计,更要不时地进行自我设计,以让自己符合群体性大众的认同。每个人都在寻找自我,每个人对于消费产品的自我标签也越清晰。对于每一位中国经济增长的参与者,在经历个人财富和物质价格波动的岁月,这种混杂恐慌性和炫耀性情绪的身份焦虑更迫切,每个人都生怕自己手持的产品设计形象过时,同时又不希望自己流俗。不希望自己跟别人用一样的手机,开一样的车,喷一样的香水,在精神上寻求物质化的满足时,越来越多的人又不甘心盲目的成为快速消费品经济的宿主。