【Asp.net精品源码栏目提醒】:网学会员鉴于大家对Asp.net精品源码十分关注,论文会员在此为大家搜集整理了“【精品】SaaS知识重用 - 大学课件”一文,供大家参考学习
SaaS 知识重用 1 建立并积累自己的开发体系 遵行业界的规定又有自己的特色是我们所追求的目标。
成功的软件公司都有丰 富而可复用的代码组件,几行代码在单个系统里可能无足轻重,但一旦可在大量的 系统中可重复使用那就是价值不菲了。
做单个项目不一定获利,但用前面的项目经 验与代码改造成新项目的成本就少多了。
所以,软件业一定要建立起自己的知识库 并不断地积累,那将是取之不尽的财富。
2 建立可重用性的知识库 l 充分利用开发模板 利用我们自己开发的模板组装我们一般的页面,极大的减少了页面设计代码和 开发代码,提高开发效率。
此模板中包括页面的风格控制,通用的翻页组件,通用的操作功能如打开一个 页面,删除,增加,退出等。
l 控件管理 我们以后一律采用微软的 AjaxControlToolkit 所带的控件,此组控件基本包 括了我们所用的所有控件。
主要特点是无刷新,用集成性好。
l 通用组件管理 组件管理分为可在任何项目中都可用的组件和本项目可用的组件。
这些组件事 实就是由各种类组成的程序集。
编译好的组件我们引用此 DLL 文件就可。
任何项目中都可用的组件放在 CommonLayer 层里。
通用组件的统一管理:通用组件的每个每个方法按标准格式书写,必须提供调 用该方法的事例,参数及返回结果。
3 风格设计 l Themes 的作用 Themes 是
Asp.net v2.0 的另一个定制 Web Site 的增强功能,他的作用是 可以对页面和控件的一些属性进行设定.并且可以将这些设定应用于整个应用程序、 单一页面或者是单一的控件. 主题是一组可视界面设置,包括壁纸、光标、字体、声音和图标。
主题是属性设置的集合,使用这些设置可以定义页面和控件的外观,然后在某个 Web 应用程中的所有页、整个 Web 应用程序或服务器上的所有 Web 应用程中一致地应用此外观。
主题由一组元素组成:外观、级联样式表CSS、图像和其他资源。
主题将至少包含外观。
主题是在网站或 Web 服务器上的特殊目录中定义的。
l Skin 的定义 外观文件具有文件扩展名.skin,它包含各个控件例如,Button、Label、TextBox 或 Calendar 控件的属性设置。
控件外观设置类似于控件标记本身,但只包含您要作为主题的一部分来设置的属性。
例如,下面是 Button 控件的控件外观: 在 theme 文件夹中创建.skin 文件。
一个.skin 文件可以包含一个或多个控件类型的一个或多个控件外观。
可以为每个控件在单独的文件中定义外观,也可以在一个文件中定义所有主题的外观。
有两种类型的控件外观-“默认外观”和“已命名外观”: 当向页应用主题时,默认外观自动应用于同一类型的所有控件。
如果控件外观没有 SkinID 属性,则是默认外观。
例如,如果为 Calendar 控件创建一个默认外观,则该控件外观适用于使用本主题的页面上的所有 Calendar 控件。
默认外观严格按控件类型来匹配,因此 Button 控件外观适用于所有 Button 控件,但不适用于 LinkButton 控件或从 Button 对象派生的控件。
已命名外观是设置了 SkinID 属性的控件外观。
已命名外观不会自动按类型应用于控件。
而应当通过设置控件的 SkinID 属性将已命名外观显式应用于控件。
通过创建已命名外观,可以为应用程序中同一控件的不同实例设置不同的外观。
l 级联样式表 主题还可以包含级联样式表.css 文件。
将.css 文件放在主题目录中时,样式表自动作为主题的一部分应用。
使用文件扩展名.css 在主题文件夹中定义样式表。
l 定义
ASP.NET 主题 1. 在网站上创建名为 App_Themes 的新文件夹。
2. 注意:该文件夹必须命名为 App_Themes。
3. 创建 App_Themes 文件夹的一个新子文件夹来保存主题文件。
该子文件夹的名称就是主题名称。
例如,要创建名为 BlueTheme 的主题,应创建名为App_ThemesBlueTheme 的文件夹。
4. 向新文件夹中添加组成主题的外观、样式表和图像的文件。
l 创建外观 1. 使用.skin 扩展名,在主题子文件夹中创建一个新的文本文件。
2. 典 型 约 定 是 为 每 个 控 件 创 建 一 个 .skin 文 件 , 如 Button.skin 或Calendar.skin。
不过,您可以根据自己的需要创建或多或少的.skin 文件外观文件可包含多个外观定义。
3. 在.skin 文件中,添加常规控件定义使用声明性语法,但仅包含要为主题设 置 的 属 性 Property 且 不 包 括 ID 属 性 Attribute 。
控 件 定 义 必 须 包 含runatquotserverquot属性。
4. 对于要创建的每个控件外观重复步骤 2 和 3。
l 对控件应用外观 主题中定义的外观应用于已应用该主题的应用程序或页中的所有控件实例。
在某些情况下,您可能希望对单个控件应用一组特定属性。
这可以通过创建命名外观.skin 文件中设置了 SkinID 属性的一项,然后按 ID 将它应用于各个控件来实现。
有关创建命名外观的详细信息,请参见如何:定义
ASP.NET 主题。
对控件应用命名外观 设置控件的 SkinID 属性,如下面的示例所示: 如果页面主题不包括与 SkinID 属性匹配的控件外观,则控件使用该控件类型的默认外观。
4 配置管理 采用科学的配置管理思想,辅之以先进的配置管理工具,可以很容易的解决项目开发过程中由于管理上引起的问题。
1. 列出软件开发、运行、维护各阶段所需的软件配置项 所谓软件配置项就是在软件开发工作进展中得到的许多工作产品、阶段产品、使用的工具软件等信息项。
表 1 中列举了若干类软件配置项及其生成的阶段。
表 1 软件配置项 分类阶段实例 环境类软件开发环境或软件维护环境编译器、操作系统、编辑器、数据库管理系统、开发工具、项目管理工具、文档编制工具 定义类需求分析与定义阶段结束后得到的工作产品需求规格说明、项目开发计划、设计标准或设计准则、验收测试计划 设计类设计阶段结束后得到的工作产品系统设计规格说明、程序规格说明、数据库设计、编码标准、用户界面标准、测试标准、系统测试计划、用户手册 编码类编码及单元测试结束后得到的工作产品源代码、目标码、单元测试数据及单元测试结果 维护类进入维护阶段以后生成的工作产品以上任何需要变更的软件配置项 只有明确了各阶段有哪些软件配置项,软件企业才能在实施软件配置管理时胸有成竹、游刃有余。
2. 对现有软件配置项进行分类、补充,进一步完善软件配置 软件企业在实施某一软件时,针对不同的用户都有不同的需求。
表 2 是不同用户的工作环境: 表 2 工作环境 用户计算机配置操作系统后台数据库系统 用户 APIV1.4GWIN2000SQL Server2005 用户 BPIV3.5GWIN2000Oracle9.0 为了满足各个用户的使用要求,我们的软件产品必须考虑到这些差异。
在产品的设计时我们尽可能的作成 3 所示的安排: 表 3 列表安排 用户配置项模块 用户 AA 模块、b 模块、c 模块、e 模块、h 模块 用户 BA 模块、b 模块、c 模块、f 模块、g 模块 为了实现这两种不同的软件配置,在实际开发应用中,我们完全可以将各个配置项分别开发出来,再根据用户的需求,组合成不同的产品,如图 1 所示: 图 1 不同用户组合成不同的产品 3. 对软件项目的变更要实行有效的控制和管理 软件企业在软件的开发、运行、维护过程中必然要遇到软件的变更。
引起软件的变更主要有两方面的因素:一方面是用户,如用户要求修改工作范围和需求等另一方面是软件开发人员自身,如他们在工作中发现前期工作中的错误而修改
源码甚至设计。
对于以上两种情况软件企业可以从以下几方面加以解决: 明确实施变更的双方人员 事先应该明确用户有权提出需求变更申请的人员和软件企业项目开发组有权受理变更的人员,并且对双方人数要加以控制。
这样做的好处是可以约束需求方,使需求方每提一个需求都要经过仔细讨论。
而项目开发组收到用户的需求变更时,通过有权实施变更人员讨论后,可以兼顾全局,对涉及到的相关文档、程序、计划都随之变更。
对变更进行严格的审核 并不是所有的变更都要修改,也不是所有变更都要立刻修改,审核的目的就是为了决定是否需要修改和什么时候修改。
比如涉及到界面风格问题,就可以先不修改,或者规划一下修改的时间待到以后进行优化。
另外,对于核心模块的修改要严格审核把关,否则会引起全局问题。
对变更的影响进行评估 变更都是有代价的,应该评估一下变更的代价和对项目的影响,要让用户了解变更的后果,并与用户一起做判断。
让客户确认是否接受变更的代价。
在评估代价并且与客户讨论的过程中,可以请用户一起做判断:“我可以修改,但您能接受后果吗”,并且对用户一一列出修改的后果。
4、对软件版本进行有效的管理 软件企业开发的软件产品为了适应不同的运行环境、不同的平台、不同用户的使用要求,导致同一软件产生或演化出不同的版本。
软件企业可以通过以下两种常用的方法进行软件版本控制。
号码版本标识 以数字表示,如第一版,表示为 V1.0。
第二版表示为 V2.0。
一般认为 V1.0,V2.0 是基础版本号,V1.1、V1.2 是对基础版 V1.0 的第一次修订和第二次修订。
显然这些修订都是少量的修改。
若有重大变动或因多次修订导致的全局性的重要变动,则应提高版本号,如 V2.0。
号码版本标识可以如图 2 所示: 图 2 号码版本标识 符号版本标示 这种版本表示法是把版本的重要信息提炼出来。
如 V1/VMS/DB SERVER,表示一个在 VMS 操作系统上运行的数据库服务器版本。
对于软件企业可以用“人事管理系统单机版”、“人事管理系统网络版”等来表示。
实施有效的配置审核 软件企业在实施配置审核时可以从以下两方面进行: “配置管理活动审核” “配置管理活动审核”用于确保项目组成员的所有配置管理活动,遵循已批准的软件配置管理方针和规程,如检入Check in/检出Check Out的频度、工作产品成熟度提升原则等。
“基线审核” 要保证基线化软件工作产品的完整性和一致性,并且满足其功能要求。
基线的完整性可从以下几个方面考虑:基线库是否包括所有计划纳入的配置项基线库中配置项自身的内容是否完整如,文档中所提到的参考或引用是否存在此外,对于代码,要根据代码清单检查是否所有源文件都已存在于基线库。
同时,还要编译所有的源文件,检查是否可产生最终产品。
一致性主要考察需求与设计以及设计与代码的一致关系,尤其在有变更发生时,要检查所有受影响的部分是否都做了相应的变更。
审核发现的不符合项要进行记录,并跟踪直到解决。
在实际操作过程中,一般认为审核是一种事后活动,很容易被忽视。
但是“事后”也是有相对性的,在项目初期审核发现的问题,对项目后期工作总是有指导和参考价值的。
为了提高审核的效果,应该充分准备好检查单,如表 4 所示。
表 4 检查表 检查表 YesNO 说明 是否及时 Check in 与 Check out 是否对配置库进行定期备份 是否给配置系统定期病毒检查 上次审核中的不符合项是否已解决 是否进行定期审核工作 是否成立配置审核小组 6、进行配置工具选择 软件企业选择商业配置管理工具,可以考虑下面几个因素。
工具的市场占有率 大家都选择的东西通常会是比较好的东西。
而且市场占有率高也通常表明该企业经营状况会好一些,被人收购或者倒闭的可能性小一点。
工具本身的特性 工具本身有稳定性、易用性、安全性、扩展能力等。
您应当在投资以前仔细地对工具进行试用和评估。
这儿比较容易忽略的是工具的扩展能力Scalability,您现在可能只是在几个人、十几个人的团队中部署这个工具,但是以后可能会有几十个、几百个人要在依赖这个工具建立的平台上工作,到时候这个工具能不能提供这样的支持能力如果到时候要换一个工具的话,您一定会后悔今天的选择。
5 抽象对象模型 抽象对象模型为企业级应用系统提供业务公共平台,把政企应用共有的业务提炼出来,形成通用的业务信息系统,在此层面基础之上,用来构建、集成和运行政府、企业的信息系统,以减少企业级应用开发过程中重复的开发。
基于可重构的抽象对象模型,这些类既包含由应用程序开发人员继承和使用完整方法,也包含可能由应用程序业务对象的开发人员实现的方法的抽象定。
应用程序开发人员可使用此对象模型来构建面向对象的应用程序和框架。
抽象对象模型提供下列特性: 自定义业务对象属性 可变的业务逻辑 统一的对象唯一标识符 面向对象的设计模式 按照对象属性的查询/筛选方案 6 模型驱动 MDAModel Driven Architecture是模型驱动架构,它是由 OMG 定义的一个软件开发框架。
它是一种基于 UML 以及其他工业标准的框架,支持软件设计和模型的可视化、存储和交换。
和 UML 相比,MDA 能够创建出机器可读和高度抽象的模型,这些模型独立于实现技术,以标准化的方式储存。
MDA 把建模语言用作一种编程语言而不仅仅是设计语言。
MDA 的关键之处是模型在软件开发中扮演了非常重要的角色。
MDA 源自于众所周知的把系统操作的规范从系统利用底层平台能力的方式细节中分离出来的思想,MDA 提供了一种途径通过相关的工具来规范化一个平台独立的系统、规范化平台、为系统选择一个特定的实现平台,并且把系统规范转换到特定的实现平台。
MDA 的三个主要目标是:通过架构性的分离来实现轻便性、互操作性和可重用性。
模型驱动架构MDA是 OMG 组织近年来一直热炒的一个新的技术体系,同时也是众多搞软件模型研究人员的一个新热点。
MDA模型驱动核心的思路是希望通过对商业模型比如企业信息化或建筑领域的解决方案的领域研究。
进而提炼出一个相对核心的领域模型,同时抽象出一个 PIM平台无关模型。
之后根据不同的开发平台例如.net 或 J2EE,应用平台windows 或 unix形成相应的 PSM平台相关模型。
依照相应的工具,例如 ArcStyler 可以完整地生成相应的代码和软件系统。
当然这里只是罗列出一个大致的思路和方法。
1. MDA 理论还处在一个探索期,很多理论和方法并不成熟,当然无从谈起有成熟的工具,从目前的趋势而言,从理论到实际的工具都离 OMG 组织所提出的预想有较大距离,至少还需要数年的努力才能成型。
2. 目前无论是国外的开源组织还是国内的一些组织对 MDA 都只是处在一个草创阶段,很多人所谓的应用 MDA 其实都只是在 MDA 的体系中作一个最初的探索和尝试。
例如 ORM 就是在一定层次上实现 MDA 在数据库应用方面的探索,但也只是解决了一个实体模型映射的问题。
前几天一个面试人员用 ArcStyler4.X 做了一个银行 POS 系统的应用模型,生成了一点还需要修改的框架代码。
就告诉我说他已经掌握了 MDA,斯等水准真是让我汗颜佩服 3. MDA 的第一个热点可能是桥接器,而在 MDA 领域中,映射是个很重要的点,而转换和交互都只是在这个点上的延伸。
4. 目前而言,最有可能在 MDA 体系中得以实现的语言是 JAVA,尽管我很讨厌 JAVA 的一些愚蠢方法。
5. MDA 的核心是 PIM,因为他是最抽象和协同性最高的。
同时就当前形势而言,PIM 也是一个瓶颈同时就目前的 UML2.0从 OMG 那里得到最新的而言,还不足以作为建立整个 MDA 体系的语言。
同时对于 MOF 中的一些定义似乎还有提升的必要。
因为对于整个体系而言,MOF 应该更多的作为一个标准,只有在标准成熟的前提下,才有可能产生正确的映射规则。
6. 等到 MDA 风光无限的那天,会使一部分程序员失业,但不会是全部,起码MDA 工具要有人做,因为一个 MDA 工具不足以应付所有的领域。
这就好比没有一个财务系统能适应所有的企业一样。
因为各个领域的标准化不同。
l MDA 的流程 MDA 的实现主要集中在以下 3 个步骤: 1. 首先,您用 UML 对您的应用领域进行高度抽象的建模,这个模型和实现它的技术或者底层技术完全没有关系。
这个模型我们称之为平台无关模型PIM。
2. 然后,PIM 将被转换为一个或多个平台相关模型PSM。
这个翻译的过程一般是自动实现的。
PSM 将用一个特定的实现技术来描述您的系统。
它将用到这种技术所提供的种种架构,比如 EJB,数据库模型,COM 组件等等。
3. 最后,PSM 将被翻译成源代码。
因为每个 PSM 已经完全依靠某种特定的技术,这个步骤一般是比较简单的。
MDA 流程中最难的一步,是从 PIM 生成一个 PSM。
它要求您对您要应用的基础技术具有丰富且巩固的知识,另一方面,源模型PIM必须具备自动生成 PSM 所要求的足够信息量。
l 通过模板生成:MDA-light 在 MDA 的 实 际 应 用 当 中 , 一 个 较 容 易 的 实 现 是 通 过 模 板 我 们 称 之 为MDA-light。
这样,平台相关模型这一步可以说是被跳过了,您可以直接从高度抽象的 PIM 生成源代码。
您将继续在 MDA-light 的基础上进行真正意义的编程:您必须在源代码,而不是 UML,编写细致的应用逻辑。
l 使用 MDA 的前提 业界甚至是整个世界一个被广泛接受的事实是:只有变化是永恒的。
技术永远在革新。
这在中间件领域尤其明显,当然还有数据库技术,操作系统,甚至是编程语言都经常变化。
这些技术明显比应用领域的基本概念要变化的快。
如果您在某一特定的应用领域工作,在这个领域中的项目都具有一定的相似性。
整个应用程序族或者不同的项目都属于同一个应用领域,那么,MDA 或者生成流程将特别适合于您。
l MDA 的优点 您对建模的投资将更加持久的有效--远长于您目前实现它所应用的技术。
这将更有利于保护您的投资。
您具有了技术上的灵活性。
您将不再受技术或应用所具有的不同变化周期的影响--在 MDA 的帮助下,您可以中立的保持两方面的多样性。
l MDA 的缺点 MDA 意味着更多的quot组装quot而不是quot开发quot--在为一个应用建立 PIM 的时候,您基本上没有技术上的周旋空间。
这对于今天的很多开发人员来说,还是难以想象的。
软件开发的创造性在一定程度上减弱了。
开发人员常常觉得,就一种新技术展开争论,在技术的前沿工作,是十分吸引人的。
可是在 MDA 流程下,大量的工作是建立模型,这和具体的技术相距甚远,但符合 OMG 的建议。
潜在的不成熟性。
UML2.0 还在幼年时代。
MDA 工具出现的时间也相对很短。
这里还隐藏了很多风险。
l MDA 流程和生成开发中有待解决的问题 数据和应用程序的移植:目前在商业领域经常需要面对的问题是,大量的数据和应用程序如何向新的,MDA 为基础的系统中移植。
纯粹的 MDA 流程将把数据模型和数据库表结构看成是技术细节。
它们不应该对平台无关模型PIM层产生任何影响--那么,您的 MDA 工具或生成器也负责生成数据库脚本吗 软件维护:编制不同的发行版本,补丁或者升级,是对目前正在运行的程序进行维护的重要组成部分。
MDA 怎么处理这些问题呢每次进行一次全新的安装 投资报酬率Return-on-Investment:从什么样的环境和系统开始计算从应用 MDA 的第二个项目还是从第五个开始 生成器和相关工具造成了对其生产商的依赖--这种对生产商的依赖是我们以往一直极力避免的。
企业应用整合EAI:高度的抽象,听起来不错--但是对于已经在运转的应用系统,怎么得到这种抽象呢 您可以看到--潜在很多实际问题其回答都具有重要的意义。
这些问题正是我们创立 openMDA 的原因:在很多项目当中,某些以上的问题已经得到了实验性的回答,您和我们都将从中获益 l MDA 的软件开发周期 在 MDA 中软件开发过程是由软件系统的建模行为驱动的。
下面是 MDA 的软件开发周期: MDA 生命周期和传统生命周期没有大的不同,主要的区别在于开发过程创建的 工 件 , 包 括 PIMPlatform Independent Model , 平 台 无 关 模 型 、PSMPlatform specific Model,平台相关模型和代码。
PIM 是具有高抽象层次、独立任何实现技术的模型。
PIM 被转换为一个或多个 PSM。
PSM 是为某种特定实现技术量身定做。
例如,EJB PSM 是用 EJB 结构表达的系统模型。
开发的最后一步是把每个 PSM 变化为代码,PSM 同应用技术密切相关。
传统的开发过程从模型到模型的变换,或者从模型到代码的变换是手工完成的。
但是 MDA 的变换都是由工具自动完成的。
PIM 到 PSM, 从 PSM 到代码都可以由工具实现。
从 再 PIM,PSM,和 Code 模型被作为软件开发生命周期中的设计工件,在传统的开发方式中是文档和图表。
重要的是,它们代表了对系统不同层次的抽象,从不同的视角来看待我们的系统,将高层次的 PIM 转换.