我的实习论文------------------------------单点登陆的感想

 

2005年6月至今，我参与了本学院董丽丽、周继两位老师开设的横向课题，与西安高压开关股份有限公司的合作开发门户网站、OA系统和决策支持系统。

在此，首先感谢两位老师给我这次学习实践的机会，让我受益匪浅。

我的实习的地点主要安排在本学院实验室，实习时间主要是上课间隙、自习时间及周末时间等业余时间。实习期间曾多次去西开公司，与客户商讨软件需求。通过这多半年的实习，让我感受最深的就是四个字：软件危机。我们花了半年时间，却完成了不到全部工作的三分之一。

这个项目主要是为了响应国家提出的关于实现国有大型企业的信息化建设，西安高压开关股份有限公司结合本公司的实际需要，借助西安建筑科技大学信息与控制工程学院扎实、先进的软件开发实力，双方倾力合作，成为校企合作的又一次典范。

这次合作开发项目的具体内容包括：企业信息门户、协同办公和决策支持系统。其中企业信息门户又可分为公众门户和员工门户两部分，公众门户是企业对外展示、宣传和树立企业形象的窗口，同时向公司客户、供应商提供技术支持的平台，包括公司的简要概况、组织结构、重要新闻、技术文档下载、产品展示，招聘信息等……。企业信息管理人员可以向公众门户发布信息、编辑已有信息和各个版块内容、上传技术资料，也可以根据需要调整网站的布局和主题风格。员工门户侧重于实现单点登陆和个性化配置，为员工提供自己的个性化办公环境。员工门户是企业内部有权使用信息系统的员工，登陆后可以处理自己有权办理业务的场所，不同部门的人可以在门户中办理不同的业务，生产部门的主管可以在自己的门户中发布相应的生产信息，营销部门的人可以查看客户的情况和产品的销售统计，各种报告等。所谓单点登陆是指用户不论使用公司的那个信息化系统，只需要从员工门户一个入口登陆即可，每个人只需要一个账号，一旦登陆成功，拥有不同权限的人就可以使用不同的系统去办理不同的业务。员工门户是个综合的平台容器，各个子系统好比这个平台容器中具有不同功能的各个机器，登陆的用户拥有不同的权限，他们可以根据自己的权限使用不同的机器。子系统开发时只需遵循一定的规范，便可以方便地注册到门户系统，使用统一授权功能，门户管理员可以在门户后台对各个注册的子系统的权限进行统一分配，这样既减轻了管理员的工作量，又方便了授权操作。门户平台的另一大特点是员工可以根据自己的爱好和工作习惯个性化配置自己的门户，员工可以根据需要改变自己的桌面风格、布局，可以设置不同模块的显示位置、显示或隐藏部分模块，实现所见即所得的个性化配置。

办公自动化是为公司的协同办公、公文流转、知识文档管理而设计的信息化子系统，其中包括工作流引擎的开发、实时提醒、即时通信和与手机等移动通信设备交互信息等多个功能模块。决策支持是根据公司的各种数据信息建立数据仓库、生成多维数据表等，并根据这些数据提取、分析生成多种形式的报表、报告，向公司决策者提供参考和建议。

截止到目前为止，这个项目的进展有限，门户平台已搭建完毕，正在测试阶段，协同办公尚处在设计阶段，门户平台的设计开发中所需解决的核心问题是单点登陆、统一授权、角色及功能点权限设置、个性化设置和所见即所得的操作方式。在这个阶段，我主要负责人员分配和部分设计、编码工作。由于管理不当、需求分析不明确、开发人员缺乏经验等诸多原因，前一阶段的工作完成的很艰难，期间走了很多弯路。在我的报告中，将分别就这几个方面进行详细分析阐述。

4. 专题内容分析

这里将一一阐述前一段实习中遇到的问题、解决办法以及所走的弯路，并进行分析，总结。

西开门户平台所采用的开发工具及软硬件环境如下：

（1）软件环境

windows2000以上操作系统 + IIS6.0

VisulStudio.net2005(Beta)

SqlServer2000

（2）硬件环境

web 服务器：处理器pentiumIV以上，512兆内存（或以上）

数据服务器：处理器pentiumIII以上，512兆内存（或以上），120G以上磁盘空间。

（3）系统框架图

企业门户

协同

办公

决策

支持

用户角 色

 

 

 

 

 

 

 

图1

4、1 基于功能点的用户角色授权机制

为了更加准确、方便地控制用户权限，双方结合公司的实际情况，进行了大量讨论，最终确定了用户—〉角色—〉功能点的三层权限机制。功能点是对门户直接操作的最底层权限，一个功能点对应门户上的一个具体操作，比如说某种信息的添加、编辑、删除、打印、复制，或某种文件的上传、下载等都属于功能点级的操作。但功能点不能独立存在，脱离模块的功能点是没有意义的，在谈到添加、编辑、删除等功能点时，我们必须指明是哪个模块中的功能点，即每个功能点必须从属于一个模块，模块与功能点的关系是一对多，可用下图表示：

模块一

模块二

模块三

 

……

……

 

功能点

 

 

 

 

 

 

 

 

图2 模块功能点关系图

 

用户

 

角色

 

功能点

 

 

 

 

 

图3 用户—角色—功能点关系图

清楚了这两点之间的关系后，在之后的描述中，暂时先把这两者抛开，以功能点代替两者之间关系。一个模块的功能点是对这个模块的所有操作权限的最小单位，模块的功能点不能动态添加，若要增加某个模块的功能点，必须对该模块的代码进行升级。将这些功能点分组、组合，便可得到角色，在这里角色的含义不单是代表了某种用户身份，而且是功能点的集合，代表了某种权限。这里的角色没有管理员和普通用户之分，只根据拥有功能点集合的大小来确定这种角色的权限大小。一个角色可以拥有多个功能点，同时一个功能点也可以属于多个角色，功能点与角色是多对多的关系。一个用户可以拥有一个或多种角色，这样不同的用户就根据不同的角色信息得到了不同的权限。一个角色也同时可以属于多个用户，两者之间也是多对多的关系。这样，用户—〉角色—〉功能点的关系就明白了，我们用上图3来表示：

经过进一步讨论，我们发现，由于使用系统的人员较多，且每个部门人员权限都大致相同，给相当多的人赋予相同的角色权限，意味着管理员授权时要做大量重复性的工作。怎么样避免这种重复性工作呢？一开始大家都希望有个权限拷贝的操作，即可以把某个用户的权限直接复制给另外一个人，深入讨论后发现这种复制权限的做法只是一种理想的方式，事实上属于同一部门的员工虽然大致具有相同的权限，但大家又各司其职，权限是不可能完全一样的，比如销售部门的人员可能需要知道某些生产信息才可做销售方案，而财务部门又需要了解企业多方面的经营情况，部门之间存在很多权限方面的交叉，复制权限的方法是行不通的，后来我们借鉴了操作系统中对用户分组的机制，添加了用户组，用户组介于用户和角色之间，用户组是对不同角色的分组，用户通过隶属于用户组拥有角色，这样一个用户只要加到某个用户组就拥有了该组的权限，省去了对每个用户做大量的角色授权操作，同时一个用户可以属于多个组，解决了跨部门之间的权限分配，同一部门的人可能都属于某个组，但每个人根据自己的具体业务又有自己特有的组，这里需要明白的是部门与用户组不是对应的，一个员工只属于公司的一个部门，但他可能拥有多个用户组。

虽然经历了很长时间的讨论、设计，表面上看这种权限机制相当灵活、方便了，但后来的实践表明这种做法并不是十分可取的。当授权操作分层很多时，管理员无法直接看到某一个人、或用户组到底有哪些权限，还要一层一层往下找，才能查出来，很不方便。另外，给程序员带来了麻烦，当每编辑一个用户组或角色的权限时，属于该组或拥有该角色的所有用户的权限都要发生改变，编码的复杂导致了运算的复杂，系统的运行效率也因此降低，同时加重了服务器的负担。因此，灵活方便都是相对的，过分的追求灵活必然会产生严重负面影响，降低了运行效率。

4、2 应用web service的子系统注册机制

门户系统的单点登陆是指登陆到企业门户之后，就可以直接使用公司的其他系统，无需再次经过验证。门户是各个系统的大门，各个系统只有按照一定规则与门户捆绑到一起，才可以实现统一认证。因此，需要有个子系统注册机制，使各个子系统可以注册到门户中。由于子系统的个数、存在的位置都不确定，所以子系统与门户不能有太大的耦合度。经讨论，我们采取了这样的机制。在门户数据库中，建立用户中心，所有的用户信息都记录在门户数据库中，门户系统中还有功能点注册表，将各个系统的功能点信息注册到门户数据库，并根据功能点生成各个系统的角色信息。子系统的配置及功能点信息以XML格式存储在具有特定名称的文件中，注册时将文件路径写入注册表单，门户系统将远程读取文件内容，并将注册信息插入到数据库中。当一个子系统注册成功后，管理员就可以根据注册的功能点信息为子系统建立角色、用户组，进行授权。

下面对web service 进行简单描述。Web Service体系结构包含了三个角色：服务提供者（Service provider）、服务代理者（Service broker）和服务请求者(Service request)。服务提供者提供可通过网络访问的软件模块（Web 服务的一个商业处理功能），并通过 WSDL描述服务中所含的功能、要使用此功能所需输入的数据，以及预期的输出结果。服务提供者把它发布到服务代理者。服务代理者的核心是UDDI数据库，它允许服务提供者公告服务内容并使服务请求者能找到这些服务。服务请求者使用查找操作来从本地或服务代理者处检索服务描述，然后使用服务描述与服务提供者进行绑定并调用Web Service 功能。图1显示了这些操作和提供这些操作的组件以及它们之间的交互。

发布WSDL

查找UDDI

SOAP绑定

服务代理者

服务请求者

服务提供者

图4 Web Service的体系结构

在每个子系统内部,都要对当前登陆用户进行权限验证,这个验证过程就是调用远程方法来做的,子系统在加载功能点时,将当前用户信息与功能点发送到Web Service, Web 服务通过查询权限数据库,验证该用户是否有权限使用该操作,然后反馈结果到子系统,子系统再根据验证结果判断是否显示该操作。

门户

数据

中心

子系统

验证

 

 

 

 

 

图5 子系统权限验证图

通过Web服务是解决了子系统远程注册的问题，但这种设计模式也有弊端。子系统的权限和用户模块完全依赖于门户平台，使得第三方开发子系统必须遵循门户标准，降低了系统开发的灵活性。另外一种更为灵活的方式是将子系统完全作为一个独立的系统去开发，然后通过用户绑定的机制将两者的权限信息统一起来，实现单点登陆。我认为这样做虽然使管理员的工作量加大了一些，但却给实现上降低了很大难度，是目前实现单点登陆比较理想的方式。

4、3 桌面个性化配置

在门户系统中，每个员工都拥有自己的桌面，桌面根据用户喜好和工作需要，可以布局常用子系统的快捷方式，或者一些小工具，还有一些板块。比如说新闻、日历、记事本或OA的快捷方式。由于每个用户的桌面都是个性化的，某个人更改自己的设置不能影响其他人，所以必须为每一个人创建一份个性化配置信息，但桌面可以布局的必须是用户有权限的信息，由前面叙述可知，读取权限信息运算是十分复杂的，所以最好把权限也写入用户个性化配置中。个性化配置信息可以以数据库或文件两种形式存储。在前一阶段，我们为了避免频繁的数据库操作，采取了XML文件方式存储。

前期的实现是这样的，为每个用户建立一个个性化配置文件，文件名称根据用户ID自动生成，文件以XML格式存储，文件中记录了用户可以使用的所有模块的名称，属性，和功能点以及这些模块的布局信息，用户登陆后便直接读取配置文件中的信息，设置自己的桌面。这样做读取是非常方便的，但给更新操作带来了灾难性的影响，管理员每改动一个角色或用户组的权限，都要更新所有相关用户的配置文件，才能保证后台与前台同步。文件读写的效率相对数据库较低，用户量一旦增大，文件读写的效率急剧下降，严重影响了系统的效率。在前期阶段，我们为了尽可能扩大系统的灵活性，允许用户定义多个桌面，又给数据库增加了桌面表，每个桌面可以设不同的背景，选不同的模板。原有的系统不断修补，添加补丁，使得个性化配置越来越复杂，经过一段时间的测试，我们最终决定舍弃这种做法，应用XML实现个性化配置的梦想破灭了。

个性化配置信息只能存储在数据库中了，在第二次改版门户时，我们彻底抛弃了XML，采取了功能点和角色权限与员工桌面布局信息分开存储的方式。这样做管理员更新了权限信息之后不能直接重新填写用户的个性化配置表，这样会使用户原先的个性化配置信息丢失。所以必须比较新旧两种用户权限，添加没有的，除去已有的。

经过这样反复地做，我体会到实现用户的个性化配置并不是很难，但要花的代价相当大，尤其在这种权限控制比较详细的管理系统中，个性化配置信息和权限管理信息在同步上总是存在很多冲突，二者要想兼得，要牺牲相当大的系统性能。而个性化配置信息在企业中应用并不大，只是可以作为系统地一个亮点，由于操作人员对计算机的熟悉程度有限，个性化反而会带来很多管理上不必要的麻烦，所以我认为在系统中做个性化的东西是不值得的。相反这种个性化的东西用在对外的公众门户上是正确的，这样管理员可以很方便的改变公众门户的外观，布局，主要在于公众性的东西不存在权限的控制，大家都可以很自由的使用，不需要为每个人建立独立的数据存储，因而代价的开销也相对小一些。

4、4 所见即所得的操作方式

为了方便用户使用，使软件更加人性化，在用户进行个性化设置时，可以用鼠标托拽各个模块，通过拖动来生成网站。这种图形化的操作比普通网页上的表格、文字更直观、更方便，所以叫做所见即所得操作坊式。实现这种所见即所得的操作也是门户开发过程中遇到的一个难点。我们先后采用两种办法来实现这种操作。最先使用的是微软公司提供的WebPart技术，微软的WebPart支持在网页上实现拖动操作，一开始用的开发工具是.net2003，经过努力发现在2003环境下实现WebPart比较困难，需要购买一定的插件才能使用，当时2005的测试版已经发布，而WebPart 在2005上是现成的模块，可以直接使用。为此我们更换了开发工具，现在看来因为一个技术难题而更换工具是一个极端错误的做法。.net 2005下的 WebPart 比较好用，将用户控件加入到区域中，就变成了WebPart ，但不容易动态加载，由于用户要个性化配置，必须纪录每个WebPart在不同用户的桌面中所在位置。WebPart 本身具有纪录位置和样式的特性，但为了达到用户的要求，不得不屏蔽WebPart 本身的性质，自己为WebPart重新建立表格来存储其信息，这样做带来了很多冗余的数据，所幸基本还能满足要求。

在对门户进行改版时，采用了层的机制代替了WebPart 。层的好处是易于拖动，其定位是基于像素的，层的位置可以随鼠标拖放到任意位置，并且不同层之间可以没有任何缝隙。不好的地方是层的所有动作都是靠脚本来支持的，包括层本身，没有了事件得支持，要保存层的位置、状态信息就比较麻烦，必需动态的解析当前页面代码，从中捕获层的信息，整体覆盖到数据库。为了实现所需操作，我们写了大量的脚本，脚本的调试、执行效率都很低，编写测试这些脚本浪费了大量的时间和精力。

经过不断的修改，发现在实现所见即所得做的很失败，得不偿失。所见即所得可以说仅是为了操作方便，是系统的一个亮点，但亮点必须在保证基本功能实现的基础上在做。回顾整个开发过程，无论是WebPart 也好，层也好，都浪费了大量的时间和精力，而系统应该达到的功能却还没有完善，在这一点上捡芝麻、丢西瓜，是最失败的，用层来改版门户花了两个半月的时间，在这期间，真正重要的工作几乎没有什么进展，是很不值得的。

5. 实习收获体会

5、1 团队合作

在这次实习中，我深深体会到团队合作在项目开发中的重要性。一个团队最重要的是士气，一个没有斗志的团队，就算能力再高，合作再默契，也做不出成绩来。软件开发本身是很枯燥无味的，这就要求研发人员必须具备相当的耐心和毅力，能够始终如一的坚持到底才能顺利完成项目开发。我亲眼目睹了我们这个团队由一开始的斗志高昂到后来的拖拖拉拉、士气低落的样子，原因可能是多方面的，但最主要的是人的毅力不够。我总结了一下经验，感到在合作中讨论是非常重要的，但讨论不宜过多，我们的错误在于动手之前讨论部充分，动手过程中又讨论没完，以至反反复复，越弄越糊涂。另外的一点经验就是一个模块只能由一个人负责，否则这个模块的开发很难进展下去，即便讨论好了，两个人在开发过程中也会不断分歧，而且人多了就会相互产生依赖心里。要求每个人对自己负责的模块做到非常熟悉，十分清楚，其他人不过是对这个人的设计提供参考、质疑，帮助其完善设计。真正的团队合作可能有很多学问，我的经历太少，也许见解很幼稚，写出来的仅仅是自己的一点体会。

5、2 软件工程

这里写软件工程不如叫做软件危机，软件工程的概念本来就很模糊，现在是更模糊了。在开发门户系统时，我们都对软件工程很陌生，主要是轻视了需求的重要性，急于设计、编码，结果在编码做了很多，几乎快要完成时又变化需求，不断修改，有时候推倒重来，这样反反复复，浪费了很多时间和精力，人也疲惫不堪。任何一个软件工程，明确用户需求是最重要的，明确了需求之后，才能确定到底采用什么模型，如何建模。一开始我们并没有按照软件工程的做法去做，而是简单分析后，直接做出了数据库模型，然后仓促进入编码阶段，编码时发现错误就返回去修改数据库，最后数据库被改的面目全非，软件也是七拼八凑，杂乱无章。中间所做的文档，也都是等编码出来后再返回去做的。门户系统的第二次改版完全是错误和不必要的，仅仅是为了改善所见即所得，却付出了重新开发的代价。

吃了不少苦头之后，我也总结了一些经验。碰巧这学期我们开有软件工程这门课，接受了理论的指导和祁老师亲身经验，才如梦初醒，明白了写软件不是胡来，软件工程是规则、有秩序的，但规则不是死的，从我的体会上来讲，我们前期一直在分析需求的，一步一步深入，直到把需要的变成所有的。一开始就建立数据模型，并不是不可以，而是缺少与用户交流，没有得到用户的认可就急于编码。在开始与用户交流阶段，应尽量降低软件开发的负担，满足用户的基本需求即可，只有在满足基本需求情况下，才考虑锦上添花的一些功能。

虽然对软件工程有了一点点了解，我始终认为按照正规的方式开发软件是不划算的，那些方法是给大公司准备的，因为只有大公司才有那样的时间和经费，而普通的开发团队根本耗不起。通过这些周折，我对面向对象的软件设计思路有了一定了的了解，这要感谢祁飞老师的帮助。

5、3 其它方面

经过这次实践，我在软件设计和编码测试方面都有了一定的长进。软件设计主要是在软件工程上，我了解了用例图、类图、时序图、状态图等面向对象设计的方法，对算法的应用也比以前更加熟悉了。通过使用C#语言，对面向对象的程序设计的特点，类、封装、继承有了更清楚地认识。

通过这一阶段的学习和实践，与几位老师、学长和同学相处，从他们的教导和行为中我也学了不少做人的道理，我衷心地感谢他们，在我即将踏入社会之前，给我上了最后而又极为重要的一课。

2006年2月3日