ASP．NET系统分析与设计思路探讨

（以前做的一片文章，是学完3层结构后写在）

         ASP．NET是以浏览器为用户界面的，与WINDOWS方式最大的区别在于无法保持状态。假如用户必须完成1个操作界面才能进入另外1个操作界面，在WINDOWS方式下是很自然的，但在ASP．NET下，就难以实现。因此，假如要用ASP．NET实现一个管理系统，如何实现页面之间的逻辑关系就显得十分重要。

         同时，还有一个严重的问题是用户的权限。在一般的设计中，通常在打开页面时验证用户的权限的目标。这样，如何设计实现用户权限管理就显得非常重要。

n         有的设计，将页面进行级别划分，与此相应的是用户的权限也是按级别来赋予。但这是非常失败的权限管理方式。就简单的理由就是：对于一个大的系统而言，页面可能是多种专业或应用方向的，而任何一个专业都可能形成一个权限级别，你不可能将一维的权限来实现多维的专业管理。

n         微软公司为我们设计了用户域的管理，将页面和用户作用域联系起来。表面看起来解决了用户对用户操作权限的要求，但在实际应用过程中我们会发现，以此来建立一个系统还是难以理解和使用。

u       首先，这种管理在可能自动增加级别和栏目的系统中是无法起作用的。

u       其次，用户域与页面之间的关系必须由专业人员来完成，这是很难达到用户操作简单化、傻瓜化的要求的。

u       另外，这种做法并没有体现出现实世界中管理权限分配与管理的功能。

n         现实世界中，每个领导有一个管理的范围，管理的范围的下一级的领导及其所有的下属成员，乃至下属的下属，都是该领导的管理范围。而且管理范围是按专业性来管理的，而不是按单位来管理。这就对我们用ASP．NET编写信息管理系统提出了要求：如何模仿实现现实生活中的权限管理？

         我们常常说，C语言是面向对象编程语言，她模范了现实世界。另外，还有人提出，用JAVA可以实现面向事件编程。其实C语言也可以实现面向事件编程。是否面向事件编程与系统设计有关，与语言关系不大。

n         那我们不妨问一下：

u       面向对象编程与面向事件编程之间的区别何在？

u       我们如何设计一个软件系统？

         我们可以探讨一下现实世界的情况：

n         现实世界中，每天都会发生各种各样的事件，每个事件中都有相关的对象参与其中。世界总是象电影一样在连续地上演。每一时刻，世界范围内的每一对象都会处于某种状态之中。也是，世界的每种状态就好像电影中的一张胶片，将所有的世界的状态胶片连接起来就形成了世界的发展史。

n         但是，由于世界的纷繁复杂性，如果用事件为主来描述这个世界的话，往往无法理出一个头绪来，于是有人提出，世界也是有物质对象来构成的。事件由于没有物质性，所以难以表达，但是对象是有实体的，我们可以用对象来表达这个世界。于是，对象性语言C语言就这样产生了。C#集成了其它版本C语言的有点，规范了C语言的特征，并且还吸收了其它语言的有点。

u       但有一点很重要，就是将事件作为对象的成员。也就是说，任何一个事件都是一个对象的事件。

u       但现实中，事件并不是一个对象的成员。由此可见，C#关于“任何一个事件都是一个对象的事件”的做法有点问题。虽然，这种情况常常发生。而且，任何一个事件，这要将对象的范围扩大，都可以将事件包含在其中。

l         但我们在编程过程中不可能将所有对象建立起来，以包含事件。

n         综上所述，我们发现有以下几个名称概念：

u       对象

u       事件

u       状态

         现在我们再看看我们如何建立一个软件系统？

n         在《软件工程》的理论中，按照工程学的方式来创建软件。其中最重要的就是系统需求分析。内容包括：

u       用途分析

u       用户群体分析

u       产品遵循的标准与规范分析

u       产品范围分析

u       角色分析

提示：阐述本产品的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。

u       功能分析

名称、标识符
功能描述
优先级
输入
操作序列
输出
补充说明

u       用户界面需求分析

u       软硬件环境分析

u       产品质量分析

u       其它需求分析

n         系统需求分析之后就是体系结构设计：

（1）说明本系统“是什么”，

（2）描述本系统的主要功能。

n         接着就是用户界面设计。

n         然后是数据库设计

n         然后就是功能模块设计

模块名称
功能描述
接口 与 属性	提示：用专业的设计（开发）工具来设计本模块的接口与属性，说明函数功能、输入参数、输出参数、返回值等。此处粘贴即可。
数据结构 与 算法	提示：不论是采用经典的还是专用的数据结构与算法，都应该作必要的描述。不仅用于指导程序的实现，还可以让人们清楚地了解该对象类是如何设计的。
补充说明

n         《软件工程》到此，似乎就可以建立一个系统。事实是这样的吗？Ｎｏ！你做完了这些，你会发现你根本不知道从哪里下手去编写一个ＡＳＰ．ＮＥＴ的软件系统。傻眼了吧。

n         我并没有否认《软件工程》的作用。在做一个Window界面的系统，上述的分析过程似乎大致可以应用于实践。虽然并不完全。

         让我们按客观的思想方法来重新考虑一下如何去完成一个软件系统的设计。

n         我们使用计算机语言去编写程序都是有一定得目的性的。弄清楚我们的目的，这是最重要的开始。也是我们的编写程序的目标。那目标到底如何实现？这是一个严峻的问题。我们可以这样去思考问题：

u       目标事实上就是达到某种对象的状态，要达到这种状态之前必定会经历该对象的上一种状态。由此可见，必须发生一些事件才会从一种状态变成另外一种状态。

l         同时我们应该注意，对于一个目的而言，往往会需要一系列逻辑相关的事件，只有这些事件完成后，一种我们希望的成功状态才会实现。

l         另外，最小的事件往往可以由1个人执行。1个大的事件中，往往包含许多小的事件。

l         任何事件，总是需要一定的条件，包括环境和其它对象的状态，我们可以称之为发生事件的条件。

l         于是，我们必须知道一个事件发生前后2种状态之间需要哪些相关的对象？另外，该事件将会使事件的所属对象的属性（也就是状态）发生哪些改变（也就是事件的作用或功能）？

l         我们画2张图来表达上述内容：

u       对象的表达问题在C语言中已经解决。

u       但功能的表达在C语言中有一些问题。C语言提出用事件来表达对象变化的过程与方法，而且将事件定义为对象的成员，使用委托来定义事件，且事件可以订阅、激发。从上面的分析我们可以发现，C语言的表达方式确实反映了现实世界发生的事件现象。

l         但有时候，事件往往不能定义在一个标准的类的成员。比如：我们要完成一个邮件的发送，那么该事件的目标就是接受邮件的人收到了邮件。在该事件发生前，邮件接受者没有收到邮件，这是一种状态。在事件完成后，邮件接受者收到了这个邮件，这也是一种状态。中间的变化过程就是事件的发生过程。但我们不能定义一个该邮件接收者类的事件成员。但是我们可以建立一个这样的事件。然后确定：

n         事件的对象为：邮件的接收者。

n         事件的目的为：接收到邮件。

n         事件的环境为：在一个互联网页面上书写并发送邮件

n         事件的条件为：

u       邮件的起草人可以执行这个事件（权限）

u       邮件的起草人知道邮件接收者的邮箱地址

u       邮件的起草人完成了事件的所有操作。

u       我们可以发现，事件的顺序有2种，一种是串行连接（一个事件的结束是另外一个事件的开始形成串行事件流）；另一种是并行连接（存在2个或2个以上的串行事件流，事件流的最后作用对象相同）。在一个大的软件项目中，总包含相当多的并行连接的串行事件流，而且，在串行事件流中又可能包含并行连接的方式。

u       从上述描述，我们可以发现，如果要编制一个系统，关键在于分析达到目的的事件流，及事件流的构成形式。这与电子电路有很大的相似性。

u       分析到此，我们还是不能实现一个系统。原因如下：

l         事件往往是随机发生的，我们并不知道谁是事件的执行者，也不知道谁是事件的接受者。

l         另外，要发生事件，事件的执行者必须拥有执行权限。如何设置权限？

l         如何在事件发生之前检查执行者的权限？是由环境执行检查检查，还是有专门的机构执行检查，又或者由执行功能前执行检查。

l         另外，如果某个环境事件执行者已经进入，但环境中的功能需要不同的权限，怎样实现这样的限制？

l         另外，如何提供事件流选择？

l         如果串行事件流包含2个以上的页面，且逻辑上要求必须从第一个页面才能进入第二个页面，如何组织用户直接进入第二个画面？

n         让我们重新从整理一下头绪，我们可以得到以下结论：

u       我们给用户提供的是网页。

u       同一个网页处理的对象可能不同，虽然操作的方式是相同的（因为网页的功能是固定的）。

u       由于用户的权限不同，注定不能对所有对象进行相同的操作，所以，对象的范围是用户权限的一个重要因素。

u       除了操作对象的不同外，在某个固定的对象的操作功能，不同的用户也有不同的功能使用限制。因此，权限至少包括操作权限的限制。

u       由于网页就是功能的集合，相同页面唯一不同的知识功能处理的对象（当然操作者--用户也是不同的），因此，一个页面的特定用户的权限就是确定相应于该页面上的所有操作功能，用户能够用该功能处理的对象有哪些？

u       但用户申请打开某页面时，如果该页面需要进行权限验证，那么就应该查看相对于该页面的第一项操作功能，用户申请的操作对象是否是被许可的？（如果只要拥有一个功能就可以进入，那么可以用页面的每一个操作功能来逐项检查用户的范围）

u       或者，首先查看用户的操作对象中是否包含用户当前申请的操作对象，如果有，还要确定是否能够执行本页面的操作功能？（看来还是应该先检查是否有当前操作功能更好一些）

u       从上面分析我们可以确定，对于一个页面的完全的权限检查可以按如下进行：

l         1、首先登记某一个页面的功能操作项

l         2、其次登记所有可能的操作对象

l         3、录入用户所有的[功能操作项+操作对象]信息对，以确定用户的所有权限。

l         4、当用户使用该页面进行操作之前，使用[当前页面的单个功能项+用户当前申请操作对象]逐项检查是否包含在用户的权限范围内。

l         5、标明所有可能的[当前页面的单个功能项+用户当前申请操作对象]的用户操作权限是否可以操作。

l         6、如果页面必须首先通过第一个操作功能，则先用[当前页面的第一个功能项+用户当前申请操作对象]检查用户是否被允许，如果不被允许则直接拒绝用户的页面访问，如果允许，继续用[下一个功能+用户当前申请操作对象]继续权限检查，直到检查完毕为止。

l         7、可以建立一个表，存储[对象+功能]集合，如果要进行权限认证，可以先在本表中查找对应得编码，然后再用户权限中查找是否拥有该编码，以此确定用户是否拥有此项操作权限。这在建立和分配权限时可以更加容易操作一些。

l         在北京**公司为我公司创建的《物质供应系统》的初始化过程中，曾经有一部是设定用户权限，记得是设定每个用户所能够操作的功能和物质供应类别编码。其做法恐怕也与上述想法差不多。

u       由于每个页面的对象种类都是不同的，因此，我们不可能将所有的页面功能检查制定一个相同的规范。虽然，页面的操作功能可以用相同的方式建立，但页面的处理对象就无法按相同的方式进行。

u       由于对象的不同，决定了每一个页面权限管理都必须建立一整套权限信息库。

u       如果仅仅对用户能否进入网页操作功能，权限的管理将会大大简化。

u       当然，也可以将不同类型的对象进行统一编码化处理，但这样必须建立合理的解释程序来解释这些难以理解的编码。

u       同时，还要建立每一个页面的条件接口，将当前的条件转化为可以查询的统一性编码。

u       当然，给每一个页面的回答都可以用相同的方式。因为，当前页面的对象对于当前页面而言是不必制定的。所以，只要告诉当前页面，在当前条件下允许用户执行哪些操作就可以了。这在建立了当前页面操作功能表的程序中应该是十分容易做到的。

u       还有一种做法相当简便，就是把一个页面当作一个权限，页面中的所有对象拥有相同的权限。与该做法相同的还有，将一个目录下的所有内容作为一个权限，如：某个目录专门为VIP用户服务。

l         这样的做法就是不仅可以加快权限的验证，也可以加快权限的颁发。

l         尤其是在该用户仅仅分类后，这样的做法更容易进行权限管理。只要在对应的信息分类上著名用户所需要的某种性质的VIP认证就可以了。

l         也可以在页面打开时插入一个检查接口，接口的条件程序员之间是很容易交流的，回答也是简单的true/false。这在中间业务层很容易做到。

l         但上述的做法对于下面的要求是无法实现的：信息分成很多层次，层次越深，需要越高的权限。每一个层次设定管理员，上级可以管理下级。但如此在权限分配上，就可能出现逐步深层次权限申请与批准的行为。（也可能会出现以下错误：某用户拥有深层的权限，而没有上一层的权限，因此，如果没有特殊通道，该用户可能就无法通过正常的界面达到用户所在的界面。当然，也许这正是一种系统功能。）

u       从上诉分析我们可以发现，用户权限管理大致分为2种方式：

l         VIP认证方式

n         可以设立多种VIP以对应多种权限限制。

n         权限限制一般在中间业务层实现。

l         [信息对象+功能]方式

n         可以简化为[信息对象+页面]

u       另外，用户身份的确认在WEB页面中包含以下几种：

l         从用户的客户端的cook中获取用户信息。

n         认证后的信息当然也是存储在用户的客户端的cook中。

n         这样的做法安全性可能有一点问题。但在用户计算机是安全的假设下，以上做法是比较方便的。

l         在页面上相互传递。

n         也就是用户在某个页面上登陆后，用户信息在登陆到新页面时传递给新的页面程序。

n         也就是POST功能。

l         另外，ASP.NET可以在Seeion中传递。虽然也利用了cook功能，但作用方式和保密性能大大提高。甚至可以放在服务器短。

n         也可以用登陆时间来校对。安全性比较高。

         总结：

n         国家规范《软件开发标准范本》中的提出的做法是正确的。

n         从本质来讲：

u       1、明确软件的总体目标。

u       2、完成功能分析

名称、标识符
功能描述
优先级
输入
操作序列
输出
补充说明

l         注意：用户群体分析、角色分析应该与功能分析结合起来。

提示：阐述本产品的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。

u       3、接着就是用户界面设计。

l         因为，你必须确定功能所在的环境。因此，与第2步的功能分析紧密相关。

l         环境的设计需求，也决定了数据结构的设计

l         用户界面设计应该说明（列出）该界面包含的功能。

u       4、然后是数据库设计。

l         先把需要处理的主要信息对象表达出来。

l         在模块分析后，再重复表达各种条件数据的控制要求。

l         辅助权限管理的要求也是在循环设计修正中完成对数据结构的修改。

u       5、然后就是功能模块设计

模块名称
功能描述
接口 与 属性	提示：用专业的设计（开发）工具来设计本模块的接口与属性，说明函数功能、输入参数、输出参数、返回值等。此处粘贴即可。
数据结构 与 算法	提示：不论是采用经典的还是专用的数据结构与算法，都应该作必要的描述。不仅用于指导程序的实现，还可以让人们清楚地了解该对象类是如何设计的。
补充说明

l         注意：功能执行的条件必须作为重点。

l         接口的设计体现往往体现了功能逻辑（中间业务层）、权限等等。

l         输入/输出参数与功能的条件、信息的对象等等有极为密切的关系

u       6、重复3、4、5步骤，直到设计合理为止。

n         另外必须注意：

u       软件环境虽然是模拟现实世界，但从本质来讲，已经形成了一个独立的世界。

u       既然是独立的世界，就必须形成一个独立的权限体系。该体系不是现实世界的翻版，不用倚赖现实世界而行使，按系统本身制定的体系中运行。

u       最重要的是：软件中的权限体现了现实世界的权力的控制。密码，是软件世界的权限行使的最重要的表现方式。软件权限的运行方式，必须在软件（世界）的创建之初，就要与当权者协商并通过，然后贯彻到软件的编制当中。

         本文完成。

下面内容删除，仅作参考。

u       一个页面就是一个环境。

u       一个页面内可以包含1个以上的功能，且2个功能之间不一定需要有串联逻辑关系（比如：邮件书写、发送、查看等功能都可以在一个页面地址中完成）。

u       一个用户就是执行者，当未登录时，该用户就是匿名用户，登录后，就是注册用户。

u       页面内逻辑相关的操作构成一个功能，逻辑不相关的操作归属于不同的功能。

n         让我们提出我们的目标：

u       目标：

l         邮件的传递。

l         文章有权限地发表和查阅。

l         人员的注册管理和操作权限管理。

l         文章发表栏目的创建与删除。

l         文章栏目的权限管理

u       系统页面设计答复：

l         功能管理页面

n         为每个功能设定功能编码(按流程分析制定)

n         为每个功能设定功能名称（用于功能菜单查询）

n         为每个功能输入功能介绍

n         为每个功能设定页面链接地址

备注：

Ø         功能编码对应的页面链接地址如果是菜单显示页面则该功能编码表示该级别的菜单

Ø

l         建立用户注册管理系统。

n         如果一个操作人员在操作页面前未执行用户验证，则该用户为匿名用户。

n         如果一个操作人员在操作页面前已经通过了用户验证，则该用户为注册用户。

n         如果一个注册用户得到企业认证，则为企业用户。企业用户划归到企业的具体单位，并确定其职务与职能权限。

n         提出我们的希望：

u       最好编写页面的开发人员不用在页面打开时查看用户的资格，至于进入该页面的权限，则由系统的其他机制完成。（也就是说，页面的开发人员开发的是仅需要条件验证而不需要权限验证的页面，但加入到系统时，有另外一个机制来执行权限验证）

l         上述希望不合理，最好的权限管理仍然是在页面中进行

l         你可以提供给页面开发人员一个权限验证接口，由页面开发人员将权限验证加到页面之中。

u       最好是可以给用户提供一个功能菜单，让用户直接进入功能菜单所在的页面。

l         上述说法不合理，对于用户而言，并不需要知道功能菜单，而仅仅需要知道页面到底可以干什么？所有的逻辑有系统来执行。用户只要知道打开那一个页面去完成什么操作就可以了。

l         一般情况下，用户只能记住一个系统主页地址。

l         如果，系统不允许用户从一个地址直接进入某一个页面，那么，页面应该在打开之前检查用户是否从前一个制定的页面进入，或者，检查，用户打开本页面是否具备充足的条件。其实，后者的检查应该是个别正确的。

u       假如有一个菜单包含许多子菜单，最好可以为这个菜单分配管理员，该管理员可以执行权限管理，批准哪些用户可以进入该级别的菜单以及哪些子菜单和子项目，执行哪些操作等等。用户向某一级菜单申请权限，由菜单管理员负责审批。菜单管理员可以配准哪些人员作为下一级菜单的管理员，并确定下一级菜单是否可以再开子菜单。

u       最好给没有权限获得菜单子项目的用户显示一个该菜单的功能介绍，以便用户知道，有没有必要提出申请。

u

u       可以为事件进行编码，。但我们如果

u       我认为应该仍然用“作用”来表达。既然是虚的（非物质性），那么就应该为这个虚来定义一个勉强可以使用的名称。

l         同时，我们应该提出“功能”的概念。这仍然是虚的名称。但“功能”已经能够与对象挂钩。

n         由此来表达大的对象（世界）的变化如何由小的对象（世界中的对对象）的变化来实现。

n         因此：目标的分解就变成了一连串的功能的完成。

u       每个功能对象包含以下状态：

l         功能编码

l         功能解释

l         逻辑关系（上一个功能代码及下一个功能代码）

l         实现的环境编码（用户界面编码）

l         未进入该功能状态

l         正在执行该功能

l         已经完成该功能

n         于是，用户的信息中可以设定：

u       用户权限（功能编码集合）

u       目前任务（功能对象）