中国IT动力,最新最全的IT技术教程
最新100篇 | 推荐100篇 | 专题100篇 | 排行榜 | 搜索 | 在线API文档
首 页 | 程序开发 | 操作系统 | 软件应用 | 图形图象 | 网络应用 | 精文荟萃 | 教育认证 | 硬件维护 | 未整理篇 | 站长教程
ASP JS PHP工程 ASP.NET 网站建设 UML J2EESUN .NET VC VB VFP 网络维护 数据库 DB2 SQL2000 Oracle Mysql
服务器 Win2000 Office C DreamWeaver FireWorks Flash PhotoShop 上网宝典 CorelDraw 协议大全 网络安全 微软认证
硬件维护  CPU  主板  硬盘  内存  显卡  显示器  键盘鼠标  声卡音箱  打印机  机箱电源  BIOS  网卡  C#  Java  Delphi  vs.net2005
  当前位置:> 程序开发 > 软件工程 > 系统分析 > 系统设计 > 系统设计
果壳中的宇宙--进入设计
作者:未知 时间:2005-08-07 11:18 出处:系统分析之窗 责编:chinaitpower
              摘要:果壳中的宇宙--进入设计

果壳中的宇宙--进入设计


blueski推荐 [2005-1-9]
出处:CSAI.cn
作者:田晖
 

其实我写出了标题,就可以结束此文了,相信知者已经了然。

  《果壳中的宇宙》是英国物理学家霍金的一本书的名字,也是引自莎士比亚的戏剧〈哈姆雷特〉中的一句台词--"即便把我关在果壳里,仍然自以为无限空间之王!"。
  (这同时也是我做的一个讲座的题目,惭愧)

  "自然科学和艺术在这个境界上是一致的"。

  这是一个可以让人顿悟的隐喻,它所包含的内容太大。本文,我想仅仅从软件系统设计的角度来探讨之,但实际上我也无法把握住问题的全貌,只能抓住几个片段,写下来供大家探讨。

1. 系统的尺寸

  大到宇宙,小到果壳,其实具有同样的原理。以系统的观点来看宇宙,又能说哪个系统大,哪个系统小呢?物理学家们研究宇宙的原理,在大尺度空间上无法解决的问题,转而通过研究量子来解决,纵横捭阖,真正是宇宙之王了。

  软件设计师通过构造软件系统抽象出一个虚拟的世界,并且能够在其中自由驰骋,那也是软件之王了。

  启示一:系统不分大小。

2. 系统的结构

  果壳内还有一个宇宙,宇宙中自然还有果壳了。

  认识到系统是由系统构成的这一点太重要了,这会整个的影响我们的系统观。你当然可以简单的理解为,这是系统的模块划分或者是"自顶向下,逐步细化"之类的老调,可是你知道还可以从系统的行为来分析和判断子系统的行为,或者反其道而行之吗?

  带给软件系统设计的启示是,系统最好设计成"球形"的,不管它有多大,还是有多小,从外观上看起来都应该差不多,内在原理上也应该一致。

  启示二:系统是球形的。

3. 系统的质地

  我们都知道原子核的破裂会带来什么后果,果壳之所以能够包容宇宙,是因为它有坚硬而光滑的外壳。只有这样它才能够承受来自外部的冲撞和内部的压力,并且看起来是一个独立的个体。

  启示三:和果壳一样,系统的表面也应该是坚硬而光滑的。

4. 系统的边界

  系统的边界在哪里,这的确是一个有趣的话题。

  果壳内是什么,果壳外又是什么?

  我们在哪里,是在系统之内,还是在系统之外?

  提一个大胆的问题,我们设计的软件系统可以包含我们自己吗?可以包含人类社会吗?还是只能是依附在机电设备上的BYTE?如果软件系统中能够包含人,软件系统的设计能够包含对人类社会和组织的设计,那会是一种什么样的表现形式?

  也许我们思考到这里,就会对ERP实施中的企业流程再造(BPR)有了新的认识,原来我们是把人类社会和组织当作软件系统的一部分来进行设计。ERP这个果壳包含的不再仅仅是计算机、网络,还有我们自己。

  启示四:系统可以包含我们自己。

5. 系统的体积

  我们熟悉的和能够操控的系统,基本上都是和我们自身的体积差不多的,或者略大一点或者略小一点,只有这样我们才能够精确地观测。虽然我们对比我们大很多的和比我们小很多的世界充满好奇心,但是我们还是习惯于和跟我们差不多大的东西打交道,地球仪就是一个例子。

  从某种角度上说,软件系统对于我们的帮助,就象望远镜或者显微镜一样。

  启示五:系统看起来应该和我们自身的体积差不多。

  还记得一开始我提到的那个讲座吗?没错,果壳中的宇宙--进入设计。

  当时我们是在探讨有关面向对象方法中的用例(USE CASE)方面的话题。为什么我们一定要固守在人机交互的系统边界上来收集用例呢。对于某些系统而言,没有那么多人机交互怎么办,难道我们就设计一个庞大的COMPUTER类吗?还有,即使我们收集到了足够多的需求用例,下一步该做什么呢,拿这些用例就地进行模块划分?这可能是很多人在实际应用当中要走入的一个误区。

  不管是哪种情况,我们所要做的事只有一件,进入系统。让我们置身于系统内部,再做一次需求,或者叫分析,管他叫什么呢。如果有必要,我们可以再次深入系统中的系统。这里就存在一个进入系统的深度的问题。什么时候应该止步?

  评判进入系统的深度是否合理,有两个原则:

  一是观察以你的视点所看到的果壳是否不够坚固,如果有东西频繁地进出,而且随着时间的变迁,果壳很容易破裂,那你一定进入了不稳定的系统,出来一层看看如何;

  二是观察以你的视点所看到的果壳是否太坚固,如果你站在果壳外什么也看不到,什么也没有发生,那不妨进去看看。

  如果我们在一开始没有选择进入系统,而是跳出包容我们的系统,那我们是不是连人的组织和社会也一道设计了呢?ERP可能就是一个例子。而那些鼓吹ERP是变以数据为中心为以流程为中心的论调,也着实让人担忧,在我看来,ERP是以果壳为中心。

  入乎其里,出乎其外。

  在软件世界里,我们仍然自以为无限空间之王。

 

关闭本页
 
首页 | 投资与合作 | 服务条款 | 隐私政策 | 收藏本站 | 设为首页 | 新用户注册 | 免责声明 | 使用帮助
Copyright ©2005-2008 chinaitpower.com All rights reserved. www.chinaitpower.com 版权所有