实验四考勤卡应用程序用例研究设计.docVIP

考勤卡应用程序用例设计 实践 实践目的 通过例子过一遍设计的全过程 背景 目前已经为考勤卡系统建立了分析模型。接下来就是根据设计策略映射这些系统职责到具体的设计类，将系统需求转化为更为详细的设计模型。 总体操作步骤 从精化系统构架出发，利用包、子系统等组织类关系，分析实现构架机制，映射分析类到具体的设计类，确定设计策略，更新设计类的交互与协作，更新设计类图，最后详细描述设计类，确定设计类特征。 进度安排和工作分配 可靠、合理的设计方案是正确估算工时，安排进度，分配工作的基础。 有了详细的设计方案，开发人员对每一个类估算出所需的工作量。进而能估算整个项目的大致工作量，这样比单纯根据需求的估算要精确的多，使得项目经理对系统的总工作量做到心中有数。 设计模式 设计模式是对软件设计中普遍出现的一类问题的解决方案，这种解决方案定义明确、文档充分，并历经时间考验。 学习设计模式将彻底改变你设计软件的方式，并能更深入的理解面向对象理论。 规划设计工作 为整个设计建立目标 清晰度和可理解性 类的强内聚 包的低耦合 性能和可靠性 技术的选择，深入理解技术 可扩展性 必须考虑变化，封装变化 重用潜力 通用的抽象层次和封装 建立设计准则 用例的图 用多少个、几种图来描述 细节层次 方法返回值、参数，对象定位、生成 命名约定 类、接口、参数、变量 内聚性 划分共同的目标和职责 找出独立的设计任务 分派松耦合的包 涉及的一些概念 软件构架 软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。RUP中软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突出重要的特征。构架框架或构架基础设施（中间件）是可以在其上构建某种构架的构件集。类别 模式 结构 层 管道和过滤器 黑板 分布式系统 代理 交互系统 模型-视图-控制器 表示-抽象-控制 自适应系统 反射 微核 分析机制代表常见问题的常用解决模式主要用于在构架的中层或更低层代表复杂技术的“占位符”。通过在构架中将分析机制用作“占位符”，可以尽量避免机制行为的细节分散构架工作的重点。是一种特别复杂的机制。在分析过程中，我们不希望因细究如何达到而分散工作的重点。这就导致了“”分析机制的出现，它使我们在谈及对象和分析对机制的需求时不必考虑机制的确切功能或工作方式分析机制通常与问题领域无关（但并不一定总是无关），而属于“计算机科学”的概念。它们可能会以框架的形式来实施，例如、进程间通信、错误或故障处理、通知和消息传递等的处理机制 考勤卡系统的设计详细操作说明 考勤卡系统架构 确定目标： 可扩展性 卡勤卡系统定义相对集中，优先级不高。 可维护性 必须易于理解和易于维护。 可靠性 必须高度可靠。但没有达到信用卡或生命支持系统的级别，因此限制范围内停机是可接受的，不可预测的停机不应该出现。 可伸缩性 必须能够扩大以适应更多的数据和用户。 将类分组： 五组分析类：实体类 用户界面类 控制类 系统接口类 定位器类 将这些组作为候选包，对强内聚进行评估。 实体类 这些类大部分描述了一组紧密相关的业务概念(business concept)，唯一个不恰当的类就是ExportRequest，与考勤卡本身毫无关系。 对此包重新命名：TimecardDomain 用户界面类 这些类封装了数据显示和系统与用户就时间条目(time entry)进行交互的逻辑。由于决定使用Servlet技术，因此没有必要区分AdministrativeLoginUI和RecordTimeAdministrativeUI为单独的类。 此包反映程序的功能和使用的技术，因此重新命名为：TimecardUI 控制类 这些类封装了考勤卡条目或者考勤卡处理工作流，命名为TimecardWorkflow 支付系统接口 这个包也应是ExportRequest类的所在，就是刚被从TimecardDomain包中移出的。此包封装了生成数据的逻辑，包含了输出请求。 此包包含了支付系统的一个系统接口，因此命名为：BillingSystemInterface 定位器类 因为使用EJB技术实现实体类，因此不需要任何单独的定位器类。Home接口已经提供了此功能。 描述包之间的耦合程度 参考前面所做的类图，得到包中各个类之间的关系，进而得到包的依赖关系。 整理得到包依赖图为： 根据技术选择添加中间件组件及其依赖关系 每个部分经过技术选择的考虑，添加各自的中间件组件，并将包依赖