求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
     
   
分享到
软件设计是怎样炼成的?
 
火龙果软件    发布于 2014-3-27
 

(1)——什么是优秀的设计?

某项目的设计文档评审会上,各路技术大牛进行了“热烈”的讨论,讨论的焦点是怎样的设计才漂亮!大家围绕着如何OO,如何高内聚低耦合,如何反转控制等话题进行了“热烈”的争论。照这样开下去,这个评审会岂不是变成了“神仙大会”!怎样的设计才叫优秀的设计呢?

1.什么是优秀的设计?

某项目的设计文档评审会上,各路技术大牛进行了“热烈”的讨论,讨论的焦点是怎样的设计才漂亮!大家围绕着如何OO,如何高内聚低耦合,如何反转控制等话题进行了“热烈”的争论。

你觉得以下标准可以成为“漂亮”设计的标准吗?

1)高效

2)可靠

3)易用

4)安全

5)可扩展

6)兼容性强

7)移植性强

……

如果每次设计文档评审,我们都采用上述标准来评审,你觉得这个设计评审会有效果吗?

当时我参加了这样的一个设计评审会,觉得气氛很不对,照这样开下去,这个评审会岂不是变成了“神仙大会”!

于是我问了两个问题:

1)谁能说说这个项目的主要需求?

2)这些需求,设计上是如何考虑实现的?

结果没有人能答上来!

我们从书本上看到的那些”通用“的设计标准,说得难听一点,就是废话!对实际的项目工作基本上没有实质用途!

请看下面4个例子,分别思考这4个案例的软件设计思路,你会发现上述“漂亮设计的标准”,真的是废话!

案例1:某项目要求在很短时间内完成,而且客户对系统的当前认识还是比较初步的,你打算怎样设计这个系统?

案例2:某软件公司接了一个“网页+数据库”类型的项目,这类项目已经做过多个,但这次的业务却是新的,你怎样考虑这个项目的设计?

案例3:某软件公司已经成功为n个医院做了管理系统,现在需要为一家新的大医院做类似这个系统,你会怎样考虑这个系统的设计?

案例4:你接到一个任务,要做一个即时战略游戏,目标是要在当前游戏市场找中杀出一条血路,你怎样考虑这个游戏的设计?

4个案例各有特点,分别代表了4种“典型”:

案例1:需求很朦胧,工期很紧,技术上基本上没有积累。

案例2:需求是新的,但可以重用“网页+数据库”的技术架构。

案例3:需求是类似的,技术架构也是类似的,相信你会直接重用之前的系统。

案例4:这是一个需要创意和高技术含量的游戏,而游戏软件的需求和技术都是充满挑战的。

上述4种情况,相信你采取的设计策略是不一样的,你可能会发现所谓的优秀设计没有固定的标准。

如果硬是要来一个优秀设计的标准呢?

我会这样说:就是做高性价比的设计!

一个优秀的设计应该具备以下特点:

1)优秀的设计都是需求驱动的,不熟悉需求就做出来的设计是不靠谱的;

2)优秀的设计应该是当前团队能理解能实现的,太超前的设计项目团队做不出来,这个设计只能是摆设;

3)优秀的设计应充分考虑当前各种限制条件,适当做出平衡,能保证达成项目的目标:

4)优秀的设计能尽量降低项目的整体工作量,让整个项目更加可控。

2.优秀的设计能节省项目工作量

关于软件设计的话题,如果脱离一些实际案例讨论的话,很容易变成空洞无力的学术讨论,所以本文将会列出很多案例供你参考。

设计案例:开发某线上社区网站

背景:某社区已经举办了多期沙龙活动,为了拓展沙龙的影响力,让更多朋友受益,树立良好品牌,将来实现盈利,有必要建立一个线上的社区网站。

该网站应有这样的功能:

1)发布各种活动信息。

2)发布业界新闻。

3)能开展线上沙龙活动,包括在线视频沙龙。

4)具备SNS社区,可汇聚人气。

5)每位会员有自己的博客,能维护自己的个人页面。

6)支持简体中文、繁体中文、英文三种语言随时切换。

7)支持全文搜索。

你打算如何设计上述系统呢?

你可能会问,有工期限制吗?

你说呢?真实项目一定会有工期限制的,这个项目你的工期只有1个月!

你可能会说:你当我是神仙啊,1个月有可能怎样死都死不出啊!

这个时候能帮助你的就是优秀的设计,优秀的设计有可能能让你用很少的工作量就做出来,优秀的设计也不一定需要你全部从零开发的,我们可以拿来主义!有不少开源软件是可以基本满足上述要求的,我们可以直接拿来用,这样你需要付出的工作量就少很多了。

我曾经用某开源软件做了这样的一个网站出来,但发现没有全文搜索功能,结果我想了一个“投机取巧”的办法,自己不写一句代码,直接利用谷歌的这个搜索功能“site:域名 关键字”,让谷歌帮我搞定全文搜索。当然这样做出来的效果还不是很完美,但至少我能在很短时间内能做出个大概啊,如果自己开发还不一定能做出这样的效果呢!

小结:

受工期限制、受能力限制等制约因素,十全十美的设计基本上是很难做到的,但如果因为赶工期而在软件设计上节省时间甚至是直接忽略这步,其实是得不偿失的。在软件设计上“节省”1小时,可能会让你将来多投入成倍的项目时间;越是工期紧,越需要冷静思考软件的设计,合适的设计能大大地降低项目工作量,让你后期的工作轻松很多。

(2)——优秀设计从分析需求开始

设计应该针对需求来做,这个大道理似乎人人都懂,但实际操作时往往就不是这样。所以我们也不说大道理,直接通过一个“很简单”的案例来体验一下优秀设计应该如何从分析需求开始,体验架构设计是如何全面考虑各种需求、项目的工期限制预算限制,还有项目组人员水平后做出来的。

3.优秀设计从分析需求开始

设计应该针对需求来做,这个大道理似乎人人都懂,但实际操作时往往就不是这样。所以我们 也不说大道理,直接通过一个“很简单”的案例来体验一下优秀设计应该如何从分析需求开始。

3.1 案例挑战:考勤系统的软件设计

某公司要做一个内部用的考勤系统,希望达成以下目标:

1)规范员工的上下班、请假、外出工作等行为。

2)方便计算员工的薪金。

3)方便管理各种带薪假期。

你如何考虑本系统的设计呢?

你可能会说:我靠,才三句话的需求,怎样做设计呢?

说得太好了!我们做软件设计的,第一步并不是直接去设计,而是分析需求!

3.2 如何分析需求?

当你接受一个项目的设计任务时,可能会遇到比较尴尬的情况,那就是需求有问题!

具体的情况可能有:

a)需求很简单,几句话或者是一页纸的需求。

b)需求很详细,可能有几十页甚至上百页,这些需求是招标书中提供的,或者是客户直接提供的。不要以为有这么多需求是好事,这些需求通常是前后有点矛盾、逻辑有点混乱,甚至是不知所云滴!

c)你们有专门的部门或者专职完成了需求工作,提供了一份需求文档。你也不要以为这是好事,因为很可能会出现这样的情况:需求文档的提供者认为自己写的需求文档很牛逼,水平很高;但负责实现的开发部门认为该文档质量太差,比方说:不考虑实现的可能性和难度,没有考虑到客户的真正需求等等。有时候甚至出现开发部门忽略掉需求部门,直接找客户重新调研,重新编写需求文档的情况。

上述三种情况一句话总结就是:需求的质量有问题!

我们需要重新分析一次需求,先从业务角度审视一次,然后再从软件设计的视角审视一次。通常我们需要按顺序思考以下问题:

1)什么人会使用这个系统?

2)不同的人将会使用这个系统的什么功能?

3)还有哪些不确定或不具体的需求点?

4)哪些需求对技术提出了怎样的要求?

5)系统的大致架构应该如何考虑?

下面开始我们看几个图,按顺序逐一思考一下上述的几个问题。本小节回答问题1、2,后面的小节回答其他问题。

1)什么人会使用这个系统?

不少技术人员分析需求时往往是技术的视角,当你问他系统有什么用户时,你可能得到的结果有两种:

a)没有什么用户啊,所有人都是用户,因为系统只需要配置一下权限,谁都可以用。

b)系统有两种用户,就是:用户和管理员。

我们从业务的角度来审视一下考勤系统的可能用户,请看下图:

图2.1 系统可能用户分析

此图列出了如下可能用户:

employee:员工

finance:财务

receptionist:前台

manager:经理

senior manager:高级经理

administrator:管理员

而上述用户还有这样的关系:finanace(财务)、receptionist(前台)、manager(经理)继承employee(员工);senior manager(高级经理)继承manager(经理)。

用户之间的继承关系,是什么意思呢?

我们都知道代码中B类(子类)继承A类(父类),子类就具备了父类的特点。用户之间的继承关系是相同的意思,我们继续看看下图你就可以理解了。

下图将会回答这个问题:

2)不同的人将会使用这个系统的什么功能?

图2.2 系统的需求分析

图2.1和图2.2都是UML的用例图,两个图加在一起比较完整系统地表达了以下问题:

a)什么角色会用本系统?

b)这些角色通过本系统分别能干什么事情?

c)角色之间有可能会有继承关系,请留意父类能干的事情,子类也能干,例如:employee可以打卡,manager也可以打卡,尽管图2.2中manager没有直接与”打卡“相连,但图2.1中已经说明了manager继承employee。

UML是需求分析的有力工具,我的工作中很喜欢用UML。但你的工作中、你的需求文档中可能会没有UML图,不管你们是否用UML图,分析需求时都需要从业务的角度思考这些问题:

a)什么人(角色)会用这个系统?

b)这些人(角色)分别需要用系统的什么功能?

需求分析其实是一个负责的高难度的话题,回答上述两个问题仅仅是需求分析的第一步而已,我们还需要深入分析业务,包括业务流程、业务数据结构等等。如果之前的需求工作不到位,就需要我们立马开展软件设计工作,其实将会埋下很多地雷,后患无穷。关于需求分析的更多分享,请留意我的其他文章。

3.3 找出设计关注点

本小节我们回答这两个问题:

3)还有哪些不确定或不具体的需求点?

4)哪些需求对技术提出了怎样的要求?

软件设计师需要有敏锐的需求及设计触觉,看着图2.1和图2.2 嗅出一些问题,你能嗅出一些问题吗?

请看下图:

图2.3 系统的设计点分析

图2.3主要从设计的视角对需求再进行一次审视,以下是一些建议:

a)你需要更加深入思考需求,考虑到各种不同的业务场景和特殊情况,例如:领导不在公司时如何审批请假?

b)你需要思考需求的细节,例如:报表的具体形式?

c)你需要思考各种技术方案,例如:打卡数据的同步方案,财务软件是否要对接等等?

d)你要做出平衡,用合适的方案和尽量少的工作量来满足需求。

3.4 针对需求做初步的架构设计

本小节将会回答这个问题:

5)系统的大致架构应该如何考虑?

接下来你要做初步的架构设计了,架构设计是难度很高的事情,需要你全面考虑需求,考虑工期限制预算限制,考虑项目组人员的水平,而做出的一种平衡。请看下图:

图2.4 系统架构的考虑

图2.4是UML的部署图,这个图比较粗糙,而且为了降低大家阅读难度,我仅仅是用了部署图的最基本最少的语法来表达。

图2.4中的每一个立体的矩形,表示的就是物理上或者是逻辑上的一台设备,设备之间 有物理连接的话就用线条连接,每台设备中”{ }“括起来的文字是对该设备的进一步说明。

图可能是表达设计的最好方式,建议大家用UML,表达系统架构时,用UML的部署图、组件图和包图是比较合适的。我们设计的系统多数是分布式系统,不是单机系统,用部署图来表达分布式系统的架构设计可能是比较合适的。

图2.4针对图2.3中提出的问题进行了初步的回应,图2.4 就是一个初步的架构设计,当然后续我们还需要继续细化这个设计。

3.5 小结:如何需求驱动设计?

本篇的例子告诉我们:

1)优秀的设计是需要从分析需求开始的。

2)需求的质量可能有问题,那么我们需要从业务的角度重新审视一次。

3)从设计的角度审视需求,我们会提出很多需求细化及设计方案的问题。

4)架构设计是全面考虑各种需求、项目的工期限制预算限制,还有项目组人员水平后综合做出来的一种平衡。

(3)——软件系统不是木桶型的

前文提到我们应该需求驱动设计,那就直接来一个更干脆的做法,我们将需求表示为一个一个的用户故事,软件设计分别针对用户故事来做就行了,只要将用户故事逐个实现了,系统也就完成了。果然能这样做吗?

4.软件系统不是木桶型的

4.1 某种“需求直接驱动设计”的工作方法

案例分析:某敏捷实践项目小组的设计方式

某项目小组正在如火如荼地实践敏捷,任务看板上已经粘贴了很多“用户故事”,项目小组经常在看板前讨论问题:

1)讨论每一个用户故事的实现方法,并进行估算;

2)项目小组成员领取用户故事,负责实现该用户故事;

3)每天检讨进度情况和遇到的问题。

该工作模式给项目小组带来了新鲜的动力,调动了大家的工作热情,取得一定的工作成绩,但也带来了一些思考:

1)只要我们将每一个用户故事的设计想好并实现,每个用户故事都能通过测试,软件就能完成?

2)用户故事之间没有关系吗?软件设计不需要统筹考虑全部的用户故事吗?

4.2 软件是木桶型的吗?

请看图:

图3.1 软件是这样工作的吗?

一般我们的系统会采用分层架构,以三层架构为例子:

1)最外面的是表现层,主要就是程序的界面了;

2)界面后面就是我们写的程序;

3)程序后面就是数据库。

按照上述的“需求直接驱动设计”的工作模式,只要有新的需求,其实就是有新的用户故事,那么在这个用户故事驱动下,直接设计对应的界面、程序和数据库表就行了。这样的框架下工作,我们可以无惧需求变更。软件就是一个大木桶,需要实现更多需求,那就增加更多的木条就可以了;如果要修改需求,那就修改某条木条就可以了!

我发现很多系统是按照这样的思路来设计的,举一个某电信网站的例子。

我到该网站交费,发现有免费宽带提速的服务,需要输入电话号码来确认该电话线路是否具备提速的条件。我觉得很郁闷,明明我已经登录系统了,系统应该知道我的电话号码,为啥还要我填一次?好吧,为了免费提速,我就输入一次电话号码吧,提交后系统告诉我一个订单号,告诉我大概什么时候会搞定之类的信息。过了几天再次上这个网站,免费提速宽带的窗口又弹出来,我很烦关掉它:我已经提交订单了,还干嘛一直提示我!但它又继续弹出来,我烦了,那再提交一次订单吧,居然可以提交成功!被这样的系统折腾几次其实也不算什么,只要能免费提速也就值了,但最终的结果是电信一直没有帮我提速,我也懒得去投诉了,按照我以往投诉的历史经验,那是折腾自己的事情!

很多商家在不同时期有很多的促销等市场活动,需要软件系统来支持。我们按照木桶原理来做系统的话,看上去似乎事情变简单,但功能与功能之间其实存在很多交叉点,不考虑这些情况,会导致很多问题:

1)首先是用户体验超级不爽。有些系统甚至没有做到用户信息和权限信息共享,就好像上述这个电信例子。

2)没有能发现功能与功能之间的“重用”部分,没有从架构上和数据库底层上认真规划,其实会带来更大的总体工作量。

3)会留下一些系统漏洞甚至是安全漏洞,万一出问题后果很严重。

4.3 软件的内部架构是怎样的?

请看图:

图3.2 软件常见的工作模式

此图说明了以下问题:

1)需求并不是由一个个孤立的“用户故事"组成的,业务概念、业务流程其实是贯穿多个用户故事的,软件设计应该多从业务概念、业务流程的角度来思考;

2)表面上看上去一个用户故事对应一组界面,其实界面之间是很可能有重用和共享部分的;

3)业务逻辑层中的一些类很难将其分拆开来与用户故事、界面组一一对应,存在交叉、共享和重用的可能;

4)数据操作层的代码,有可能是用工具自动生成的、通用的;

5)数据层中的某张表,通常会支撑多个用户故事而不是一个用户故事。

下面我在列举一下无法单独考虑的设计点,以下列出来的可能都需要从软件架构上做一个整体的考虑:

1)权限控制;

2)性能要求;

3)日志记录;

4)工作流;

5)全文搜索;

6)多数据库支持;

7)搜索引擎优化;

……

实际上很少需求是可以通过单独添加一些类,加一些数据表就搞定的,需要通盘的考虑。如果我们硬生生地将系统看成是木桶型的,去添加系统的木条,会让软件很丑很难用,存在诸多漏洞,而且工作量会更大。

4.4 小结

有时候由于目前能力有限,无法全面考虑需求,只能暂时按照木桶型的方式来设计系统,这样也不是不可以的,但要注意的是至少要做到:

1)用户信息和权限信息是共享的;

2)要杜绝安全漏洞。

木桶型的设计方法其实会让系统很难用、弹性很差、工作量更大,而且部分需求我们无法通过添加木条的方式搞定,我们需要尽快升级我们的设计水平,下一节开始为你介绍比较实用的软件设计方法。

(4)——软件设计的“大道理”

十几年前刚毕业不久,我从事第一份软件开发的工作,要完成一个项目,但没有任何软件设计的思路,于是请教我的老板。我的老板给了我两种思路:1)先假设软件已经做出来了,想好软件的外在表现,由此倒推软件的实现方法;2)思考程序的数据结构,先设计数据库,然后再搭建软件的上层建筑。老板给了我很大的启发,随着工作的开展,后来我又发现了第3种设计的思路。本文将为你分享三种软件设计的思路:1)由顶而下;2)由底而上;3)由中间到上下。

5.软件设计的“大道理”

5.1 我的第一次商业软件的设计经验

1999年刚毕业不久,我从事第一份软件开发工作,当时要负责一个大型桌面软件,但不知道应该如何开展软件设计工作,于是向老板请教。老板也仅仅是年长我几岁,不过公司的核心产品是老板开发的,老板说他其实也没有什么系统的方法,不过有两种思路供我参考:

1)先假设软件已经做出来了,想好软件的外在表现,由此倒推软件的实现方法;

2)思考程序的数据结构,先设计数据库,然后再搭建软件的上层建筑。

上述的两种软件设计思路,相信很多有软件设计经验的朋友都能体会到。后来我又体会到第三种的设计思路,后文将会为你分享我对这三种设计思路的一些体会。

5.2 N层架构是怎么回事?

这三种设计思路都与软件系统的N层架构有关系,我们以常见的四层架构为例子,请看图:

图5.1 四层架构

这个是UML的包图(Package Diagram),图中好像文件夹的那个东西就是“包”,包与包之间的虚线箭头表示的是依赖关系。

上图表示的意思如下:

1)四层架构的四层,分别是指:表现层、逻辑层、数据访问层和数据层;

2)表现层依赖于逻辑层,逻辑层依赖于数据访问层,数据访问层依赖于数据层。

那“依赖”是什么意思呢?

“依赖”可以是以下情况之一:

1)A需要调用B的方法,则A依赖于B;

2)A的方法中某些参数的类型是B,则A依赖于B;

3)A的某些方法的返回值类型时B,则A依赖于B。

这样我们大概了解了四层架构是怎么回事了,但我们还会有以下问题:

1)表现层如何将数据传递给逻辑层?

2)逻辑层如何将数据传递给数据访问层?

3)数据访问层如何将数据传递给数据库?

通常我们不会这么老土通过一大堆参数来传递层与层之间的数据,通常我们会将数据装在实体类中,通过实体类来传递数据。所以图5.1可以进一步表示为图5.2:

图5.2 四层架构与实体类

补充说明一下什么实体类?

实体类通常是一个只有属性没有方法的类,通常我们会将某一业务对象的数据装在一个实体类中。例如:某请假单实体类,该类可能有请假人姓名、请假起止时间、请假类别和请假事由等属性。

5.3 “由顶而下”的设计思路

看了图5.1和图5.2,你大概就清楚了什么是软件的“顶”?什么是软件的“ 底”?“顶”就是表现层,“底”就是数据层。那么“由顶而下”的设计思路,其实就是先想清楚软件的表现层,然后再思考逻辑层、数据访问层、数据层的实现。

前文我们提到要“需求驱动设计”,这个说法有点笼统,我们需要进一步思考:“什么需求”驱动“什么设计”?

请看下图:

图5.3 由顶而下的设计思路

这是UML的活动图,横线将图分成了上下两部分,上部分是需求分析,下部分回答了“什么需求”驱动“什么设计”的问题。

说明一下:“需求驱动”及横线不是UML图的标准语法,图加上这些非UML元素是为了更好地表达问题。

“需求分析”这个活动有三种工作产品,分别是:

1)用例/用户故事;

2)业务流程图;

3)业务概念图。

你可以理解为上述三种工作产品是“需求分析”这个活动的“输出”。

“用例/用户故事”和“业务流程图”是“规划界面”这个活动的“输入”;类似,“业务流程图”和“业务概念图”是“设计逻辑层”这个活动的“输入”。其他就不再多解释了,你应该可以看懂这个图了,后续几个图的语法类似,也不再解释了。

上述是对图5.3语法及表达意思的基本解释,这里再稍微小结一下:

1)分析需求是设计的开始,我们还需要将需求至少分解为三部分:软件要满足的功能(用例/用户故事)、业务流程(业务流程图)、业务概念(业务概念图)三部分;

2)设计不同的层时,主要依赖的需求是不太一样的,上述分解的三部分需求对不同的层设计提出了不同的要求。比方说:设计数据库时主要是根据业务概念来设计的,规划界面时主要根据软件需要满足的功能点,还有业务流程来设计。

5.4 “由底而上”的设计思路

经过前面的铺垫后,这个“由底而上”的设计思路,相信你一看图就可以懂了。

图5.4:由底而上的设计思路

这个图也分成了上下两部分,上部分的内容其实和图5.3是一样的,只是左右顺序不太一样而已。

5.5 “由中间到上下”的设计思路

这种设计思路是我从事软件研发工作若干年后才认识的,当时是因为项目出现了特殊状况,为了应对这样的状况而采取的一种设计方法。

案例分享:客户要改SQLServer为Oracle

签订合同时,我们和客户约定的项目技术架构是.net+SQLServer,当时客户没有反对,我们就按这样的技术架构完成了系统,并且部署上线。但是不久客户居然提出了这样的要求:要求我们使用Oracle数据库,而不能用SQLServer数据库!我们通常是按照“由底而上”的思路来设计软件的,如果数据库要更换,基本上整个软件就等于重做!

如果你遇到这样的状况,你会怎么办呢?能不能按需求变更来处理呢?只有客户愿意付钱,我们就愿意干!但客户愿意付钱吗?这可是要付推翻重做的钱啊!!

最后我们的领导决定免费重做,领导决定免费重做的原因是:

这是公司的一个核心项目,我们期望这个项目将来能产品化,能持续赚钱。但我们技术选型主要是根据我们当前的技术情况来决定的,没有充分考虑客户的情况。客户是某重要行业的企业单位,单位体制内的所有企业基本都是用Oracle的,但我们选择“视而不见”,选择了我们最熟悉的SQLServer来开发系统,其实迟早是要遇到问题的。客户除了用我们的系统,还会用其他更大型的更重要的系统,客户的其他系统基本上都是使用Oracle数据库的。所以如果我们要在这个客户领域打开市场,将项目做好,就有必要将系统改造为Oracle数据库。

但是我们已经有部分客户使用了我们的基于SQLServer的系统了,将来也有可能会有部分客户要求用SQLServer,所以我们领导决心改造软件的架构,要让我们的软件可以支持SQLServer,也可以支持Oracle!于是我们按照“由中间到上下”的思路,重新打造了软件架构,请看下图:

图5.5 由中间到上下的设计思路

这个图也分成了上下两部分,上面部分和前面的图内容也是一样的,但下面部分就很不一样了,而且可能比较难理解。

“由中间到上下”基本的思路是这样的:

1)先不考虑表现层,也不考虑数据层;

2)先定义实体类和数据层接口;

3)接口定义好后,往上可以设计逻辑层和表现层,往下可以设计数据层接口的实现和设计数据库。

按照这样的设计思路做出来的软件架构,应该是这样的:

图5.6 由中间到上下的系统架构

图中见到数据操作层接口有两种不同的数据库实现,分别是SQLServer和Oracle,如果要考虑第三种数据库,那么再增加一个实现就搞定了,而系统的上层建筑(表现层、逻辑层)不需要改变。

这样的设计方式看上去很酷,是不是应该所有系统都要考虑用这样的方式来打造呢?

不是滴,这样的设计方式是有缺点的:

1)系统将不能充分利用数据库的特性,一般会禁止在数据库中写存储过程、触发器、甚至是视图等,程序的的性能其实会降低;

2)因为不能充分利用数据库本身的特性,所以大部分甚至是全部的业务逻辑只能靠程序搞定,这样其实增加了程序的复杂度和工作量。

所以每种设计方法都是有针对性的,都很难做到十全十美,一般只能针对主要矛盾做出一些取舍。

5.6 小结

如果系统没有多数据库的要求,我会比较建议你用“由顶而下+由底而上”的设计思路;如果程序需要支持多数据库,那么可能考虑“由中间到上下”。上面介绍的三种设计思路,其实在实际工作中我们往往不会只选其一,往往是结合了多种思路的。不要局限自己的思路,软件设计的可能性是无穷的。

 
相关文章

需求分析师的能力模型
基于模型的需求管理方法与工具
需求管理工具DOORS 的接口
使用Web+EA实现基于模型的需求管理
需求经过大脑的过程:需求分析评估方法
 
相关文档

需求分析与需求管理
需求分析具体要求全解
需求分析与验证
需求分析的核心线索
基于UML的需求分析方法
 
相关课程

需求分析与管理
从需求过渡到设计
业务建模与业务分析
产品需求分析与管理
需求分析最佳实践与沙盘演练
 
分享到
 
 
相关文章
需求分析方法—把测试流程图表化
敏捷需求分析五大关键因素
写好市场需求文档的10种技巧
需求分析中减少客户摩擦的法则
软件项目需求管理复杂性分析
EPC-事件驱动的流程链
更多...   
相关培训课程
软件需求分析与管理实践
业务建模与业务分析
软件需求分析与管理
软件需求分析师
面向产品的需求分析与管理
IT规划体系与实践
成功案例
北京 软件需求分析与管理
某知名基金 软件需求分析
联想 业务需求分析与建模
财税领域某IT服务商 测试需求分析
医疗行业 面向产品的需求管理
某知名IT服务商 测试需求分析>
某高新技术公司 测试架构、需求分析
更多...