实验四-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为无状态会话bean
2. 对User实体bean,决定使用容器管理
生成顺序图并分析参与类

Login 正常事件流 （无JNDI)

Login 密码错误事件流

Login 未知用户事件流

参与用例的设计类 VOPC

Record Time用例的设计
考虑关键设计决定
RecordTimeWorkflow的Bean有无状态? 保存Timecard 的bean引用,所以选择有状态.
会话Bean如何将数据返回给UI?远程引用还是简单数据？ 简单数据对于EJB比较合适。
需要持久存储的数据如何存储？如何映射到实体bean中？
• 细粒度的TimeEntry实体Bean
• 规范化数据库并使用BMP将所有数据保存到Timecard实体bean中
• 将考勤卡数据保存到Timecard实体bean中。将所有的工时存储到一个字段中，所有的收费项目代码存储到一个字段中。违反数据库第一范式，但可以使用CMP
生成顺序图和类图

Record Time 正常事件流

参与用例的设计类 VOPC

Export 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