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

1、应用建模实践过程概述和案例需求,阚忠良 ,报账系统需求及用例模型,啟元公司的总部设在北京，在上海、广州、成都和西安有分支机构，全公司接近700名员工。鉴于业务和员工团队的快速发展，为了提升整体工作效率，啟元公司准备开发一套员工报帐系统，取代原来的人工处理方式。 报帐系统将支持员工记录（或预见）日常业务活动的开销，并自动结算每个月应该返还员工的补偿金额，补偿额会直接存入员工的工资户中。 报帐系统应具有基干先进技术的图形化界面，员工可以输入业务活动的种类和简短描述，活动开销的类别，选择不同的支付方式，并可以生成灵活的报表。,报账系统需求,报帐系统应该有能力根据员工提供的信息和要求返还补偿额，同时保

2、存全部员工的报帐信息。员工可以通过他们自己的电脑来使用报帐系统。由于牵涉到财务信息，报帐系统必须提供可信的安全机制。 啟元公司现有一套基于微软SQL Server的人事管理数据库系统，记录员工的基本信息和团队的组织结构。报帐系统将和现有人事管理数据库系统协同工作，需要引用人事管理数据库系统中的部分信息，但不会更新其内容。,报账系统需求,通过报帐系统，员工能够在出差前（提前两天）按照规定的额度向公司申请借款，相关的经理人员能够通过报帐系统批复或拒绝报帐系统应在相关负责人批复之后通知该员工提取现金或确认相应款项已经划入指定信用卡（根据员工的要求）；员工可以通过报帐系统报销合理的业务活动费用 财务部

3、门将指定一位报账系统管理员监管拟建系统中的信息，负责初始设置和维护特定的分类额度准则，并能够定期或随机地向各部门负责人提交报帐情况的统计报告。Use Case图如图所示。 报帐系统在每月的25日对通过审批的报帐申请自动作一次结算，并以电子邮件的方式通知应该得到补偿的员工，同时生成一份统计报告传送给财务部门的系统监管人员。,用例图层次,提交报销申请用例,词汇表,员工：啟元公司的正式雇员。 经理：负责审批某员工当月开销的管理者，是较高级别的员工。 报销记录：与业务有关的某一项具体的花费，包括业务活动发生的时间、地点、客户名称（可选）、原因以及费用金额和种类（交通、餐饮、会议、通信和杂项）。 报销单

4、：员工在一个（自然）月内的所有报销记录的集合,词汇表,工资户头：公司将员工用于日常业务活动开销的补偿金额返还至员工的银行帐户，该帐户的基本功能是供员工接收工资。 人事管理数据库：该数据库中记录了有关人事管理的相关信息，与报帐系统有关的是公司的组织机构（“员工”和“经理”的关系） 内部邮件系统：该邮件系统负责收发与公司业务有关的电子邮件信息。,建模过程概述,迭代策略,RUP统一过程的核心思想： Use case 驱动、体系结构为核心、迭代式开发。,全局分析,局部分析,全局设计,局部设计,细节设计,初次迭代,建模实践活动框架,选用 架构模式,识别 关键抽象,标识 分析机制,选定 分析局部,全局分析

5、,提取 分析类,转述 需求场景,整理 分析类,局部分析,确定 核心元素,引入 外围元素,优化 组织结构,全局设计,实现 需求场景,实现 子系统接口,局部设计,精化属性 和操作,明确类 之间关系,细节设计,角色与分工,系统架构师：负责领导和协调整个项目的技术活动。 要求：具有领导才能，能够在压力下作出关键的决策并善始善终，能够赢得项目经理、客户、用户群体及管理团队的认同和尊敬；专业技能方面：具有全方位的技能，其见解重在广度，不再深度。需要具备设计师的各项技能，并具备问题领域和软件工程领域的实践经验。 导演,角色与分工,项目经理：负责行政管理问题 制片人 设计师：负责系统的局部和细节，本书要求：理

6、解以Use Case建模技术捕获和描述软件需求；在系统架构师的统一协调下，应用UML进行局部的面向对象分析和设计。,设计模型的内容的演进,广义的设计模型包括分析和设计活动中得到的所有结果。本书将讨论的实践过程，设计模型包括3个部分： “Use Case 实现”。反应软件需求对设计内容的驱动。 层次（layer）架构：它将分析和设计的结果按照特殊到一般的等级分组，层次架构中的内容是后续开发活动的直接的依据。 架构机制(Mechanism)。描述可复用的设计经验。,设计模型的组成,设计模型,Use Case 实现,Use Case,seCase 报告说明,词汇表,补充规约,特定应用层,一般应用层,

7、通用服务层,系统服务层,层次架构,架构机制,整个设计模型对软件需求的依赖关系体现两个方面： “Use Case 实现”通过一组协作实现“Use Case”的功能需求，“Use Case 实现”是软件功能需求过渡到层次架构中内容的桥梁 “架构机制”主要实现作为非功能需求载体的“补充规约”，是软件非功能需求得以体现的主要形式,构架（Architecture),本书中，构架主要是指拟建系统中重要设计内容的逻辑组织及结构。 层次架构适用于大中型软件的分析和设计。 MVC架构,层次架构,分层的基本原则是越靠下的层次中所包含的内容越具有一般普遍）性，或者说与软件需求中特定应用逻辑的关系越松散。这种特征带来

8、的直接价值是提高日后重复利用设计结果的可能性和可操作性。 本书中的分四个层次： 特定应用层。包括那些仅仅与当前应用逻辑相关的设计要素及组合。 一般应用层。包括那些不仅在当前应用中有价值，在其他相关应用中可能具有重复利用价值、并且不属于纯粹软件技术范畴的“设计元素”及组合。,四个层次： 通用服务层。包括那些和应用领域无必然关系、属于软件技术范畴（不涉及针对操作系统软件问题）的“设计元素”及相关组合。例如解决跨平台操作问题的“设计元素”及其组合。 系统服务层。包括那些用于提供（针对操作系统软件问题的）基础性服务的“设计儿素”及相关组合。例如解决设备驱动的设计元素及其组合。通常的软件系统不会涉及这一

9、层次内容的设计和开发，鉴于这个层次的内容具有很高的复用能力，通常可以获得成熟的产品。,Use Case 实现,“Use Case实现”作为设计模型的一部分，描述了一组对象的协作关系，用于实现特定Use Case表述的软件需求。对象协作关系的动态表述（序列图和协作图）与Use Case中的应用场景（Scenario）有直接的对应关系：多个场景将丰富的状态和行为特征赋予参加协作的对象；这些特征的静态描述被综合为“参与类图”；“参与类图”中记述的关系是层次构架中“设计元素”关系的基本依据。下图给出“Use Case实现”所包含内容的示意。,场景描述图,参与类图,用分析元素描述的 Use Case实现

10、,动态,静态,场景描述图,参与类图,用设计元素描述的 Use Case实现,局部分析,局部设计,Use Case 实现,“Use Case实现”是功能需求向设计方案（层次构架中的内容）过渡的核心纽带，这一概念贯穿整个实践过程。充实“Use Case实现”内容的主要任务集中于“局部分析”和“局部设计”。在不同阶段，用于描述“Use Case实现”的元素粒度和性质有所不同；在“局部分析”任务中应用分析元素（“分析类”），侧重于对需求作面向对象的转述，而在“局部设计”任务中应用“设计元素”（“设计类”和“子系统接口”），侧重于对实施环境的适应和折衷。,构架机制（Architectural Mecha

11、nism）,是解决常见软件技术问题的设计经验描述，包括模式化的结构特征和行为特征。基于面向对象设计的视角，“构架机制”是应用于一组类上的、能够解决特定类型问题的模式。,举一个通俗的例子，假设你准备编写一个新的应用程序B，其中的“数据存取”问题在以往的应用程序A中曾经被很好地解决；于是你会将应用程序A中的那部分代码X复制过来，简单地改头换面（变成X）之后，就能够解决应用程序B中的相似问题。类似地，你还可以在应用程序C中将X改换成X解决相似的问题那么，X、X和X中相同的部分以及X被改换成X或X过程中的经验和规律就构成了一个解决“数据存取”问题的“构架机制”。“构架机制”描述了可复用的设计经验，大大

12、地简化了应用程序B和C的分析和设计过程。当然，机制不仅可以来源于自己的成功经验，更多地是来自于别人的或通行的成功经。,“分析机制”基本上停留在概念层面（Conceptual），是某种复杂行为的快捷表述方式，具有更多的符号含义；“设计机制”拥有比较具体的内容（Concrete），通常涵盖一部分实施环境的细节，能够说明可行性：“实施机制”对应真实的实施环境（Actual），针对特定的技术和厂商，能够明确地指导实施。简单讲，“分析机制”是“构架机制”在分析任务中的表现形式，“设计机制”是“构架机制”在设计任务中的表现形式，“实施机制”是“构架机制”在实施任务中的表现形式。例如“留存”（Persist

13、ency）是一种非常典型的“分析机制”，“RDBMS”是能够实现“留存”“分析机制”的一种“设计机制”，而“JDBC”是能够实现“RDBMS”“设计机制”的一种“实施机制”。,设计模型的组成,设计模型,Use Case 实现,Use Case,seCase 报告说明,词汇表,补充规约,MVC架构,架构机制,odel,Control,经典的三层体系结构(Larman),常见的信息系统的体系结构包括一个用户界面和持久化数据存储机构，这样的体系结构叫三层体系结构（three-tier architecture）。 1）表示层（Presentation）窗口、报表 2）应用逻辑层（Applicatio

14、n Logic）管理业务过程的任务和规则。 3）存储层（Storage）持久化存储机构。,三层体系结构的主要特征是将应用逻辑从软件系统中分离出来形成一个单独的逻辑中间层。表示层相对来说基本不处理应用业务过程，窗口将任务请求转发给中间层，中间层与后端的存储层之间进行通信。 两层体系结构的应用逻辑是在窗口定义中安置的，应用逻辑直接读写数据库，应用逻辑没有被作为中间层分离出来。两层结构的一个缺点是用分离的构件来表达应用逻辑的能力不足，从而限制了软件重用。,表示层,应用逻辑层,记录销售信息,存储层,database,支付授权,面向对象的多层体系结构,1、应用逻辑层的分解： 领域对象（Domain Ob

15、ject）层代表领域概念的类，如Sale。 服务层（service)提供数据库交互、打印报表、安全性等的功能服务对象。 、超过三层多层体系结构。例如：服务层被分为高层服务层和低层服务层。,表示层,应用逻辑层,Sale,Payment,问题域对象,Database Broker,SecurityManager,服务对象,存储层,database,部署,）表示层和应用逻辑层位于客户端机器上，存储层位于服务器端机器上。 ）表示层在客户端机器上，应用逻辑层在应用服务器上并且存储层在另一个单独的数据服务器上。,多层体系结构的动机,将应用逻辑作为单独的构件从系统中分离出来，以便这些构件在其他系统中得到重用

16、。 将各个层次分配到各个不同的物理计算节点，或者分配给不同的进程。这样可以改善系统性能、更好地支持客户和服务器系统中的信息共享和协调。 将 不同层的开发任务在开发者之间适当分配，可以有效地利用开发人员的专长和开发技巧，并提高并行开发能力。,体系结构描述UML包,UML提供了包(package)的机制来说明元素组或者子系统。一个包可以是任何种类的一组模型元素。 一个包定义了一个嵌套的名字空间。,领域概念,核心元素,Sale,包的UML表示法,表示层,领域层,服务层,数据库,用UML包表达的体系结构单元,表示层,领域层,关系数据库接口,数据库,通信,对象数据库 接口,报告生成,对象 数据库,应用程

17、序框架&支持库,体系结构细节,关系和对象数据库接口包提供与数据库通信的机制。 高层面向对象服务包中的元素是使用对象技术开发的各种服务，例如报表生成、数据库接口、安全防护和进程间通信服务等。由应用程序员编写。 低层服务提供了例如窗口操纵和文件操纵等基本功能，通常以标准程序库或者第三方软件包等形式提供给开发人员的。 典型的应用程序框架和支持库支持窗口的创建、数据库和文件的访问、进程间通信等功能。,包间的依赖关系,依赖关系说明了一个包是否知道另一个包的存在。若从A到B之间没有依赖关系，意味着包A的构件没有引用包B的任何类、构件、接口方法或者服务。 从领域包到表示层没有依赖关系。符合模型视图分离原则。

18、,包的识别,将提供通用服务或者相关服务的元素组织成一个包，这些元素之间具有高耦合度和密切的协作关系。,层layer和划分partition,领域,核心元素,Sales,Products,服务,关系数据库接口,通信,报告生成,对象数据接口,垂直为层,水平方向为划分,划分代表了一层中的并行子系统在水平上的分割单位。,包中类之间可见性原则,访问领域包的可见性其他的包，如表示包，可以看到领域包内多个代表领域概念的类。 访问服务包的可见性其他的包，如领域包和表示包，只能看见每个服务包中的一个或几个类。 访问表示包的可见性没有其他包可以访问表示层。,服务包接口虚包模式,定义一个类，它为一组不同的软件构件或

19、者一组不同的接口提供一个通用的接口时，我们称这个类为虚包类。（Facade）. 虚包模式通常用于为一个服务包提供一个公共接口。,模型视图分离模式,Model-View Separation 应该将领域（模型）对象同窗口（视图）对象分开，来支持领域对象的重用，并且使领域对象的接口变更所带来的影响最小化。 解决方案：定义领域（模型）类的时候，不要使这些类可以直接看见窗口类，并在领域类中维护应用性数据和功能，而不在窗口类中维护他们。,模型视图分离的意义,支持聚合度更高的模型定义，使模型的定义可以集中在对领域过程的定义，而不是图形界面上。 允许将模型和用户界面的开发分别进行。 使用户对界面的需求变化对

20、领域层所造成的影响最小化。 允许建立一个与现存的领域层对象相连接的新视图，同时不影响领域层。 允许一个模型同时对应多个视图，例如使用报表和图形同时来描述销售信息。 允许模型层独立于用户界面执行，例如在一个消息处理或者批处理系统中。 可以方便地定义模型层到其他用户界面框架的接口。,全局分析,侧重于定义拟建系统所采用的架构以及影响架构的要素。 要充分利用相似系统或问题中的经验，避免在构架上浪费人力物力。,责任人依据活动结果,选用 架构模式,识别关键 抽象,标识分析 机制,全局分析,词汇表,设计模型t1,层次构架（高层）,分析机制,用例实现（框架）,选定分析 局部,软件需求 规约,既往经验,关键抽象,选用架构模式,采用层次架构,主要目的是有步骤地演进稳定的系统构架,识别关键抽象,词汇表,软件需求 规约,既往经验,识别关键 抽象,寻找那些无论在问题领域和方案领域都具有普遍意义的概念点。主要目的是从“点”入手将需求内容逐渐转变为设计方案的内容。,关键抽象,业务需求和软件需求中通常会揭示拟建系统必须处理的核心概念，同样将成为设计模型中的核心要素。 始终贯穿分析和设计的类及相应对象。 通常对应实体信息。