实验四-1-考勤卡应用程序用例设计.doc

实验四 1 考勤卡应用程序用例设计 作者： 日期：2 个人收集整理 勿做商业用途考勤卡应用程序用例设计 实践实践目的通过例子过一遍设计的全过程背景目前已经为考勤卡系统建立了分析模型。接下来就是根据设计策略映射这些系统职责到具体的设计类,将系统需求转化为更为详细的设计模型。总体操作步骤从精化系统构架出发，利用包、子系统等组织类关系，分析实现构架机制,映射分析类到具体的设计类,确定设计策略,更新设计类的交互与协作，更新设计类图，最后详细描述设计类，确定设计类特征。进度安排和工作分配可靠、合理的设计方案是正确估算工时，安排进度,分配工作的基础。有了详细的设计方案，开发人员对每一个类估算出所需的工作量.进而能估算整个项目的大致工作量，这样比单纯根据需求的估算要精确的多，使得项目经理对系统的总工作量做到心中有数。设计模式设计模式是对软件设计中普遍出现的一类问题的解决方案，这种解决方案定义明确、文档充分，并历经时间考验。学习设计模式将彻底改变你设计软件的方式，并能更深入的理解面向对象理论。规划设计工作为整个设计建立目标清晰度和可理解性 类的强内聚 包的低耦合性能和可靠性 技术的选择,深入理解技术可扩展性 必须考虑变化，封装变化重用潜力 通用的抽象层次和封装建立设计准则用例的图 用多少个、几种图来描述细节层次 方法返回值、参数,对象定位、生成命名约定 类、接口、参数、变量内聚性 划分共同的目标和职责找出独立的设计任务 分派松耦合的包涉及的一些概念软件构架软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架:构架属于设计的一方面，它集中于某些具体的特征。RUP中软件系统的构架(在某一给定点）是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突出重要的特征。构架框架或构架基础设施（中间件）是可以在其上构建某种构架的构件集。常见的构架模式：类别模式结构层管道和过滤器黑板分布式系统代理交互系统模型-视图-控制器表示抽象控制自适应系统反射微核分析机制 -设计机制 实现机制分析机制代表常见问题的常用解决模式，主要用于在构架的中层或更低层代表复杂技术的“占位符”。通过在构架中将分析机制用作“占位符,可以尽量避免机制行为的细节分散构架工作的重点。（如持久性是一种特别复杂的机制。在分析过程中,我们不希望因细究如何达到持久性而分散工作的重点。这就导致了“持久性”分析机制的出现，它使我们在谈及持久性对象和分析对持久性机制的需求时不必考虑持久性机制的确切功能或工作方式。）分析机制通常与问题领域无关（但并不一定总是无关），而属于“计算机科学”的概念。它们可能会以框架的形式来实施,例如持久性、进程间通信、错误或故障处理、通知和消息传递、分布机制、遗留系统等的处理机制。设计机制是对相应分析机制的改进.设计机制为概念上的分析机制添加具体的细节，但它并不具体到需要特定的技术(例如，特定厂商对面向对象的数据库管理系统的实施）.与分析机制相同，设计机制可以实例化一种或多种模式，在这种情况下为构架模式或设计模式。与此类似,实施机制是使用特定的编程语言及其他实施技术（如特定厂商的中间件产品）对相应设计机制的改进。一个实施机制可以实例化一个或多个代码模式或实施模式。需要记录系统中各类机制：（如下例，不同系统可能会不同）考勤卡系统的设计详细操作说明考勤卡系统架构确定目标:可扩展性卡勤卡系统定义相对集中，优先级不高。可维护性必须易于理解和易于维护.可靠性必须高度可靠。但没有达到信用卡或生命支持系统的级别,因此限制范围内停机是可接受的，不可预测的停机不应该出现。可伸缩性必须能够扩大以适应更多的数据和用户。将类分组：五组分析类:实体类 用户界面类 控制类 系统接口类 定位器类将这些组作为候选包，对强内聚进行评估。实体类这些类大部分描述了一组紧密相关的业务概念(business concept)，唯一个不恰当的类就是ExportRequest，与考勤卡本身毫无关系。对此包重新命名：TimecardDomain用户界面类这些类封装了数据显示和系统与用户就时间条目(time entry)进行交互的逻辑.由于决定使用Servlet技术，因此没有必要区分AdministrativeLoginUI和RecordTimeAdministrativeUI为单独的类。此包反映程序的功能和使用的技术，因此重新命名为：TimecardUI控制类这些类封装了考勤卡条目或者考勤卡处理工作流,命名为TimecardWorkflow支付系统接口这个包也应是ExportRequest类的所在，就是刚被从TimecardDomain包中移出的。此包封装了生成数据的逻辑,包含了输出请求。此包包含了支付系统的一个系统接口，因此命名为：BillingSystemInterface定位器类因为使用EJB技术实现实体类，因此不需要任何单独的定位器类.Home接口已经提供了此功能。描述包之间的耦合程度参考前面所做的类图，得到包中各个类之间的关系,进而得到包的依赖关系.整理得到包依赖图为：根据技术选择添加中间件组件及其依赖关系每个部分经过技术选择的考虑，添加各自的中间件组件，并将包依赖关联上去。抽取子系统下一步是识别子系统。目标在那些具有清晰接口，同时与系统其他部分松散耦合的包.有了候选子系统后，进一步在其中寻找那些能够独立开发或封装易于变化需求的包。候选的是BillingSystemInterface,先增加一个联系的接口。考勤卡系统详细设计设计工作分为四个部分：1。 TimecardDomain包和TimecardWorkflow包2. HtmlProduction包3. TimecardUI包4. BillingSystemInterface子系统TimecardDomain包和TimecardWorkflow包的设计这两个包最重要的目标就是性能、可靠性和重用潜力。性能和可靠性TimecardDomain包中的类对系统性能和可靠性有极大影响，负责考勤卡数据本身的可用性和完整性。设计中的考虑将影响数据访问和数据更新时间。TimecardWorkflow包用来访问TimecardDomain对象的数据和服务,它驻留于不同的客户端主机的虚拟机中，对数据流效率要求较高。重用其中的每个实体Bean在多个工作流中发挥作用,TimecardWorkflow中的会话Bean应能支持更多的新的用户界面对象.可扩展性优先级不高，通过封装潜在的变化点，以及保持类体积小巧而功能集中，来提高可扩展性。将设计应用于用例为每一个用例设计基于EJB解决方案时，遵循下面的步骤:1. 仔细考虑EJB开发中的每一个关键决定，以及包的目标2。 为在用例模型中识别的所有事件流建立好顺序图3. 为参与用例的所有类建立类图Login用例的设计关键技术决定1。 决定LoginWorkflow为无状态会话bean2. 对User实体bean,决定使用容器管理生成顺序图并分析参与类Login 正常事件流 （无JNDI)Login 密码错误事件流Login 未知用户事件流参与用例的设计类 VOPCRecord Time用例的设计考虑关键设计决定RecordTimeWorkflow的Bean有无状态? 保存Timecard 的bean引用,所以选择有状态.会话Bean如何将数据返回给UI?远程引用还是简单数据？ 简单数据对于EJB比较合适。需要持久存储的数据如何存储？如何映射到实体bean中？ 细粒度的TimeEntry实体Bean 规范化数据库并使用BMP将所有数据保存到Timecard实体bean中 将考勤卡数据保存到Timecard实体bean中。将所有的工时存储到一个字段中，所有的收费项目代码存储到一个字段中。违反数据库第一范式，但可以使用CMP生成顺序图和类图Record Time 正常事件流参与用例的设计类 VOPCExport Time Entries用例设计设计的关键决定ExportTimeEntriesWorkflow使用有状态的bean还是无状态的?没有保存先前访问的状态信息，因此选择无状态bean生成序列图和类图Export Time Entries正常事件流参与用例的设计类 VOPC修订包依赖关系HtmlProduction包的设计系统的很多功能通过Web浏览器来提供的，因此需要生成大量复杂的HTML页面.大多数基于Web的大型系统都由数百个不同的界面组成，共享一些通用的元素并具有不同的外观。一个有效的解决途径就是开发一个专门负责生成HTML的类库。理想情况下,Servlet开发人员根本不需要直接生成任何HTML页面，所有的工作交给HTML生成类负责.目标1:支持视图的模块结构在一个HTML组件中嵌入另一个HTML组件，可以轻松的得到一个复杂的页面。一个页面中可能包含表格、表单及文字。表格中的单元可能包含一个图像,而另一个单元格可能包含一个完整的表格。希望的操作的伪代码：从框架中得到一个表格从框架中得到一个图片，设置其源地址将图像添加到表格中将文字添加到表格中从框架中得到一个新的页面将表格添加到这个页面中最终的页面是基于系统的代码生成逻辑产生,不是界面设计产生的。目标2:简单化HTML的生成将大多数使用框架的开发人员的精力集中在业务逻辑的设计上，而不是花费在考虑如何生成实际的HTML页面的细节.表示层开发人员可以很轻松的数据添加到视图上，而不用知道对应于不同浏览器的显示有哪些不同之处，也不用了解某一个HTML标签具体表示什么意思。希望保持HTML生成的简单.遵循原则把实际的标记和选项隐藏起来 除框架设计者，其他人不需要了解隐藏所有浏览器相关的行为 不因浏览器不同而不同支持用户界面的自然开发 目标3:支持偏好偏好让用户可以按照自己的喜好对系统的显示风格进行修改。如：配色方案,或表格行数等。可以通过改变系统的配置文件来进行，不应要求用户更改系统的源代码来实现。为了实现系统的简单性和可重用性，底层的HTML生成框架不应该关注偏好的创建、编辑和选择的细节.仅负责应用偏好，不负责根据环境正确设置偏好允许在任何级别上设置偏好要使扩展偏好以支持新的偏好变得容易框架在不失去独立性和重用潜力的情况下支持偏好目标4:可扩展性和封装类库开发者应能够轻松扩展框架而不影响已有的视图。表示逻辑不因为IE或Netscape的不同版本而不同.框架开发人员必须能自由改变框架以适应新版本浏览器的功能，并且不影响已有的客户代码新的浏览器改变某个元素的HTML规范改变某个HTML元素默认显示表示层应和HTML生成类的变化分离。即将HTML生成类保护起来，不受应用层和表示层的影响.因此框架应该与考勤系统相独立。目标1设计:支持视图的模块设计组合设计模式将对象组合成树形结构来表示部分-整体的层次结构.组合使得用户可以以一种统一的方式来对待单个对象和对象组合Gamma。如绘制图形:线、矩形、图页表图像文字将所有的元素都具备的接口声明为IHtmlProducer,元素类型后添加Producer以统一命名。内部交互结构界面使用方式类关系目标2设计：简单化HTML生成浏览器特有的HTML前面的设计使得开发人员不受HTML细节和浏览器特有行为的困扰。但没有提供任何浏览器特有的HTML生成功能.为每种浏览器单独生成一个表格类,一般的表格类完成绝大部分工作,特有的浏览器行为可以在子类中覆盖.但是每个视图仍然需要知道有哪些实现可用，并在一定条件下，选择最合适的。这样添加一点新型浏览器的支持必须在每个视图中改动，这是不希望发生的。浏览器特有的Html运用设计模式：抽象工厂并改进结构类间的结构关系增加ProducerFactory并改进交互图ProducerFactory后台的交互,委托给最匹配的生成器目标3设计：支持偏好实现途径：为一种偏好设计一个类 ( TablePreference )使用编译器来避免键入错误。但是可能会引入数百个偏好的访问方法，载入和编辑偏好将变得困难String colorName = pageProperties.getBackgroundColor()；设计一个以java.util.Properties对象为元素的简单列表使用系统标准的Properties类，在文件中键入偏好的值String colorName = property。getProperty（“page。backgroundColor”）;目标4设计：可扩展性和封装封装除公共接口外，框架内的任何修改不允许传播到框架的表示层。视图依赖于通用的HtmlProduction包中的HTML生成器，但不依赖于具体的实现.ProducerFactory挑选正确的具体实现。是不是HtmlProduction包依赖于具体实现？ 因为每个具体实现都实现了IConcreteProducer接口，因此ProducerFactory通过此接口访问具体类中的方法。TimecardUI包的设计确定设计目标可扩展性用户界面可能变化，因此系统中的servlet不能各自生成HTML页面，而是由HtmlProduction框架来完成繁琐的工作。可测试性Servlet捆绑了系统的功能，也是系统开始的地方，因此也是集成测试的地方。Login用例的设计登录界面的设计显示登录入口用户验证过程 正常用户验证过程 异常BillingSystemInterface子系统的设计确定设计目标清晰度性能和可靠性可扩展性比较重要，支付系统可能变化。重用潜力修订构架输出用户时间条目 设计改进类关系综合以上的设计结果,下一步需要对每个部分做详细的评审，检查没有问题之后，可以进入编码实现的阶段。最终软件总体上框架如下图：(具体元素的安置可以根据自己需要进行调整设定）关于架构机制创建，参考IBM的例子21