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