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

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