【转】程序设计--系统边界

Part1 系统边界的定义

系统边界，即系统包含的功能与系统不包含的功能之间的界限。一般在系统分析阶段定义，只有明确了系统边界，才能继续进行下面的分析、设计等工作。

　　不论这个系统是产品还是项目。所谓边界，也就是将这个系统看成一个黑盒子，和外界的交互。"这，是一个黑色的立方体，长45厘米，宽23厘米，高3厘米，盒子的每个角都不尖锐，上方平坦，并有柔软质感；下方在四角之处都有凹进去的螺丝口，可以接杆子，以作凳子用。"

　　这就是仅仅对其功用的描述，其目标是作凳子用。这可以看作是功能性需求，当然如果还有一些约束，例如"此立方体可以承受300斤胖人之重"，这就可以看作是非功能性需求。但同样还是在描述边界。而对于其内部构造如何，在需求中不要描述，例如盒子是空心的还是实心的，材质用钢板还是木头，这都不是需求，而是已经在设计了。

　　因此，在描述需求的时候，重要的就是界定系统的内外。看过很多的需求，自己也写过很多的需求，界定内外不是容易的事情。有几个原因，一是没有内外的概念，不知道需求描述的是什么；二是知道内外，然而对于边界的定义，没有足够的词语描述清楚，只能用对系统内部设计来代替。这样的结果是，一份需求书，你搞不清楚它是需求还是设计。　　

　　譬如有的需求书，它描述了系统内部模块划分，三层结构，数据存储、中间逻辑等等。比如专题分析的需求中，包含了对挖掘变量的描述，嗬，将上百个变量列在文档中确实能够让页数增加。然而这恐怕不是阅读对象关心的，也不符合分离变化与不变的原则。需求书的阅读对象关心的是系统是什么，而非如何实现。系统是什么是相对不变的，而实现方式却是相对变化的。例如上面盒子的例子，用它作凳子是不变的，而至于用木头或是钢材，是后面考虑，可能会反复变化的。对于专题分析也是如此，这个分析针对的业务问题，诸如哪些客户最有可能离网，这个目标是相对固定的。而你是考虑使用呼转次数或是话费突降的角度来考虑，这是变化的。因此，在需求中，绝对不要将设计的东西加入进去（除非你是想便于说明问题），因为那种东西不能够作为一种"规格"，用于验收、测试的标准。

　　当然，有时候根据客户在作要求的时候，并非完全从系统边界上考虑，而真的会从系统内部提要求。譬如说，这个凳子，你就得用钢板，不能用木板，至于为什么，可能这仅仅是他的喜好。软件系统也是如此，有时候他会提出要求，你就得用某种产品，你就得用分类模型或者是神经元算法来实现。面对这样的要求，我也不知道该如何在需求书中表述，难道写上一堆系统约束——必须用叉叉产品，不得在系统中出现任何英文字母…？

Part2 系统边界的确定

先说说系统边界的确定。这是在工程开发中紧接着需求分析的第二步。顾名思意，这个过程就是要确定我们要开发的系统和外部环境之间的界限，也就是要区分系统本身和它的外部环境。其中的外部环境可能包括用户,其它系统,软硬件条件等。

　　举个例子，一个银行系统，它的系统边界如何确定呢？

　　首先，银行系统的外部活动者有储户,前台出纳员,银行管理员,这些都不属于银行系统本身，他们是此系统的外部环境；

　　其次，银行系统是运行在操作系统上的软件，它在运行过程中可能要进行生成文件,获取时间等操作，这涉及到操作系统的API，所以操作系统对于银行系统来说是外部环境；

　　再次，银行系统要打印交易凭条，打印机对于系统来说是外部环境；

　　第四，银行系统可能与客户的工作单位的工资发放系统有交互，那么客户工作单位的工资发放系统也是外部环境。

　　而对于银行系统来说，使用此系统的银行的建筑格局,人员构成,所处地域等就不是此系统的外部环境。

　　确定了系统的边界有什么用呢？系统边界一确定，我们就已经知道有哪些外部对象在与系统进行交互，于是我们就可以在系统中为该对象设计相应的接口，从而实现这些交互。用上面的例子说，我们应该给储户,前台出纳,管理员设计不同的接口，还要给客户工作单位的工资发放系统设计接口，为打印机设计接口。这些是我们需要关心的，如果这些外部环境改变了，我们可能要重新设计我们的接口。但不在系统边界上的因素我们就不用考虑，比如我们不必为银行建筑格局的改变而改变我们的系统接口，这是下水管道设计师应该关心的问题。

　　确定系统边界在项目开发中是非常重要的一步，如果系统边界确定得不好，会给接下来的分析设计和编码工作带来障碍，也会给系统的维护带来麻烦。

Part3 用例分析技术：确定系统边界

确定系统边界非常重要，是使用用例技术的基础，小记下！

　　首先让我们定义一下经常在项目中用到的术语。系统是指你打算开发的任何事物，他可能是软件、硬件或者过程；项目是指为了建立一个系统而做的所有事情，包括指定计划、安排进度以及归档等。
　　在项目描述以及风险分析后我们需要做的是确定系统边界，那么如何才能确定系统边界？
　　系统边界通俗点来说就是将项目分割成系统内的和系统外的，系统内的在以后的项目进展中我们必须为创建他们而投入大量的精力，系统外的我们不需要创建，但是需要我们考虑与他们的接口。若要将系统外的事物进行划分，那么系统外部大致可以分为我们产品将要面对的使用者（人），以及为外部别的系统提供的服务（其他的软件），数据存储，硬件设备，以及网络等等，这些都是不需要我们去创建的，但是我们必须考虑到他们甚至以他们为中心来分析我们的系统内部该做些什么。

　　通常我们将系统外部与系统内部交互的的事物统称为执行者，执行者是同系统交互的所有事物，执行者总是在我的系统之外，从来就不是我的系统的一部分，每一个执行者都对应一种特定的角色，每一个系统之外的实体对应多种执行者，就好比一个人在系统中他会有多种角色一样，又或者几个人可以用一个执行者来表示，因为他们对于系统来讲属于同一个的角色。
　　如何寻找系统的执行者？只要能回答一下几个问题，我想系统的执行者大体上也就找到差不多了。
　　　　谁使用这个系统？
　　　　谁安装系统？
　　　　谁启动系统？
　　　　谁维护系统？
　　　　谁关闭系统？
　　　　哪些其他的系统使用这个系统？
　　　　谁从这个系统获取信息？
　　　　谁为这个系统提供信息？
　　　　是否有事情自动在预计的时间发生？

1、找出系统有什么；系统外有什么；确定项目规模，定义要创建系统那些部分。
2、通过确定执行者和用例来确定系统边界。
3、确定执行者：谁使用这个系统，谁安装这个系统,谁启动这个系统，谁维护这个系统，谁关闭这个系统，那些系统使用这个系统，谁从这个系统获取信息，系统为谁提供信息，是否有事情在预计时间自动发生？.....提问的方式最好针对参与者的目标。因为用例建模的观点就是寻找特定参与者及其目标。
4、确定执行者使用的用例：
5、用例是一种系统执行的一系列活动，执行者执行它产生一种可估量（量化）的结果。什么样子才是可量化？一般指用例执行后的结果是具有持久性，稳定性的数据。
6、确定用例：执行者希望系统提供什么样功能？系统存储，创建，更新或删除什么信息？系统是否需要把自身的状态变化通知给执行者？系统必须知道哪些外部的事件？执行者怎样通知系统这些事件？
7、言简意骇的描述执行者和用例。
8、发现新需求问一些问题：
这些需求是必须的？是系统逻辑上必须完成的吗？是否会影响到风险分析？需求是否能被现有的执行者处理？是客户希望的系统能做的吗？会使产品在市场上变得与众不同吗？
9、系统边界确定后必须确定项目 范围：划分系统需求的优先级，确定预算。

 

采用问问题方式非常棒，就像小学时老师教我们写文章样的，新手照葫芦画瓢问自己总能写出好文章：时间，地点，人物，事件，以及四者的出现排序......几句话，作文一直到高考都是拿高分。

 

晃到一些感觉：就像找个人帮忙，不仅用例分析时把系统当作一个乐于助人的人，和他对话，而且我们在代码编写使用设计模式的时候也可以使用找人帮忙。这种心理模拟似乎不错，哈哈