尤克滨书UP方法2—建模过程概述—全局分析.ppt

应用建模实践过程概述和案例需求 阚忠良 kanzl@ 报账系统需求及用例模型 啟元公司的总部设在北京，在上海、广州、成都和西安有分支机构，全公司接近700名员工。鉴于业务和员工团队的快速发展，为了提升整体工作效率，啟元公司准备开发一套员工报帐系统，取代原来的人工处理方式。 报帐系统将支持员工记录（或预见）日常业务活动的开销，并自动结算每个月应该返还员工的补偿金额，补偿额会直接存入员工的工资户中。 报帐系统应具有基干先进技术的图形化界面，员工可以输入业务活动的种类和简短描述，活动开销的类别，选择不同的支付方式，并可以生成灵活的报表。 报账系统需求 报帐系统应该有能力根据员工＿提供的信息和要求返还补偿额，同时保存全部员工的报帐信息。员工可以通过他们自己的电脑来使用报帐系统。由于牵涉到财务信息，报帐系统必须提供可信的安全机制。 啟元公司现有一套基于微软SQL Server的人事管理数据库系统，记录员工的基本信息和团队的组织结构。报帐系统将和现有人事管理数据库系统协同工作，需要引用人事管理数据库系统中的部分信息，但不会更新其内容。 报账系统需求 通过报帐系统，员工能够在出差前（提前两天）按照规定的额度向公司申请借款，相关的经理人员能够通过报帐系统批复或拒绝报帐系统应在相关负责人批复之后通知该员工提取现金或确认相应款项已经划入指定信用卡（根据员工的要求）；员工可以通过报帐系统报销合理的业务活动费用 财务部门将指定一位报账系统管理员监管拟建系统中的信息，负责初始设置和维护特定的分类额度准则，并能够定期或随机地向各部门负责人提交报帐情况的统计报告。Use Case图如图所示。 报帐系统在每月的25日对通过审批的报帐申请自动作一次结算，并以电子邮件的方式通知应该得到补偿的员工，同时生成一份统计报告传送给财务部门的系统监管人员。 用例图层次 提交报销申请用例 词汇表 员工：啟元公司的正式雇员。 经理：负责审批某员工当月开销的管理者，是较高级别的员工。 报销记录：与业务有关的某一项具体的花费，包括业务活动发生的时间、地点、客户名称（可选）、原因以及费用金额和种类（交通、餐饮、会议、通信和杂项）。 报销单：员工在一个（自然）月内的所有报销记录的集合 词汇表 工资户头：公司将员工用于日常业务活动开销的补偿金额返还至员工的银行帐户，该帐户的基本功能是供员工接收工资。 人事管理数据库：该数据库中记录了有关人事管理的相关信息，与报帐系统有关的是公司的组织机构（“员工”和“经理”的关系） 内部邮件系统：该邮件系统负责收发与公司业务有关的电子邮件信息。 建模过程概述 迭代策略 RUP统一过程的核心思想： Use case 驱动、体系结构为核心、迭代式开发。 建模实践活动框架 角色与分工 系统架构师：负责领导和协调整个项目的技术活动。 要求：具有领导才能，能够在压力下作出关键的决策并善始善终，能够赢得项目经理、客户、用户群体及管理团队的认同和尊敬；专业技能方面：具有全方位的技能，其见解重在广度，不再深度。需要具备设计师的各项技能，并具备问题领域和软件工程领域的实践经验。 导演 角色与分工 项目经理：负责行政管理问题 制片人 设计师：负责系统的局部和细节，本书要求：理解以Use Case建模技术捕获和描述软件需求；在系统架构师的统一协调下，应用UML进行局部的面向对象分析和设计。 设计模型的内容的演进 广义的设计模型包括分析和设计活动中得到的所有结果。本书将讨论的实践过程，设计模型包括3个部分： “Use Case 实现”。反应软件需求对设计内容的驱动。 层次（layer）架构：它将分析和设计的结果按照特殊到一般的等级分组，层次架构中的内容是后续开发活动的直接的依据。 架构机制(Mechanism)。描述可复用的设计经验。 设计模型的组成 整个设计模型对软件需求的依赖关系体现两个方面： “Use Case 实现”通过一组协作实现“Use Case”的功能需求，“Use Case 实现”是软件功能需求过渡到层次架构中内容的桥梁． “架构机制”主要实现作为非功能需求载体的“补充规约”，是软件非功能需求得以体现的主要形式． 构架（Architecture) 本书中，构架主要是指拟建系统中重要设计内容的逻辑组织及结构。 层次架构—适用于大中型软件的分析和设计。 MVC架构 层次架构 分层的基本原则是越靠下的层次中所包含的内容越具有一般〔普遍）性，或者说与软件需求中特定应用逻辑的关系越松散。这种特征带来的直接价值是提高日后重复利用设计结果的可能性和可操作性。 本书中的分四个层次： 特定应用层。包括那些仅仅与当前应用逻辑相关的设计要素及组合。 一般应用层。包括那些不仅在当前应用中有价值，在其他相关应用中可能具有重复利用价值、并且不属于纯粹软件技术范畴的“设计元素”及