软件建模与UML 第六章 逻辑模型要点课件.ppt
《软件建模与UML 第六章 逻辑模型要点课件.ppt》由会员分享,可在线阅读,更多相关《软件建模与UML 第六章 逻辑模型要点课件.ppt(110页珍藏版)》请在三一办公上搜索。
1、第六章 逻辑模型,第一节 业务对象模型 第二节 分析模型 第三节 设计模型,第一节 业务对象模型,Rose把系统逻辑视图分成三个层次:业务对象模型(Business Object Model)、分析模型(Analysis Model)、设计模型(Design Model)。 业务对象模型和分析模型完成系统概要设计任务;分析模型和设计模型完成系统逻辑设计任务;设计模型和代码框架生成、编写代码完成系统实现任务。,第一节 业务对象模型,1、业务对象模型概述 2、业务对象建模的一些观点 3、业务对象模型分析 4、业务对象模型的创建,1、业务对象模型概述,业务对象模型描述现行的业务活动对象(部门、业务实
2、体、业务参与者)之间的关系,由业务用例视图中的参与者、交互图等中的对象演化而来,利用用户熟悉的业务对象描述现行系统,通过对象的合作实现业务用例的功能。 业务对象模型(也叫领域模型)是描述业务用例实现的对象模型。业务对象模型从业务参与者内部的观点定义了业务用例。业务对象模型是从面向对象的视角看待现实世界的结果,也就是通过类图来描述现实世界中各种事物的关系。,1、业务对象模型概述,下图所示的是航标遥测遥控系统的业务对象模型图,2、业务对象建模的一些观点,1)业务对象模型的核心元素2)如何命名业务参与者和业务实体 3)涉及业务用例的业务对象 4)业务对象模型和信息系统 5)在业务对象模型中明确建模的
3、信息系统 6)好的业务对象模型的特征,3、业务对象模型分析,业务对象模型描述各业务部门业务参与者、业务员工与业务实体类之间的关系,即业务对象一级的类图,这种类图只与业务逻辑有关。 一个企业的部门是对象,每个部门的业务又涉及自己的业务对象,每个部门的业务对象是从所在部门业务的术语、名词中获得的,对象是类的实体,由业务对象不难抽象出对应的业务实体来。,4、业务对象模型的创建,1)创建包 2)创建子系统业务对象模型类图下图是完成上述操作的销售管理业务对象模型类图。,第二节 分析模型,1、分析模型概述 2、分析建模的一些观点 3、建立分析类图 4、创建用例实现 5、用例实现的顺序图描述 6、用例实现的
4、通信图描述,1、分析模型概述,分析模型必须实现三个主要目标:描述客户需要什么;为软件设计奠定基础;定义可以被确认的一组需求。 分析阶段的目的是: 分析产出更确切的需求说明。分析模型用开发者的语言描述。分析模型使需求结构化,便于理解、制作、改变、重用。分析模型可看作为设计模型的第一次分割。,1、分析模型概述,分析建模的经验法则:分析模型总是使用业务语言。分析模型中的抽象应该是业务领域词汇的部分。关注于捕获大的场面。不要陷于系统将如何工作的细节。创建“讲故事”的模型。每幅产生的图都应该阐明系统期望行为的一些重要部分。对尽可能多的利益相关人有用。尽可能保持模型简洁。,1、分析模型概述,分析类代表了对
5、系统设计中一个或几个类或若干子系统的抽象。这种抽象由以下特征:分析类侧重于处理功能性需求 分析类很少定义或提供任何接口 分析类定义的属性是较高层次的 分析类中的关系也是比较高层次的、概念性的东西分析类只包括三种版型(构造型)中的一种:实体类(Entity Classes),控制类(Control Classes)和边界类(Boundary Classes),1、分析模型概述,分析模型中分析类的三种构造型,1、分析模型概述,航标遥测遥控系统分析模型的一个实例,1、分析模型概述,2、分析建模的一些观点,1)一个用例一般通过三种类协同实现其功能实体类、边界类和控制类。这三种类又称为分析类变体(Ana
6、lysis Class Stereotypes)。,2、分析建模的一些观点,实体类:业务实体的计算机描述(来源:词汇表,业务领域;如销售表,商品档案表等)边界类:位于系统和外界参与者的交界处,实现业务参与者、业务员工与用例的交互(来源:“参与者-用例”。如窗体类、报表类或软件接口。常用来接受参与者的交互信息)控制类:主要用来协调边界类和实体类的工作,也称管理类。用例将某项责任委托给控制类,控制类自身并不完成任何服务功能,而是由控制类发送消息,由别的类来实现需要的服务。,2、分析建模的一些观点,2)用例实现(Use-case Realizations):用例通过“用例实现”来完成相应用例的功能。
7、用例实现就是UML的协作(Cooperation),意思是通过对象(或类)的协作完成用例的实现。,3、建立分析类图,1)创建包,3、建立分析类图,2)创建类图 完成后的销售子系统分析模型类图示例,4、创建用例实现,用例实现是类图的一种。创建用例实现,进一步描述类的动态特征。 下面结合销售系统用例具体说明如何创建用例实现。具体过程参见教材P158-159.,4、创建用例实现,4、创建用例实现,4、创建用例实现,用例实现可以从不同的角度去描述 可以通过类之间的协作(类图)来描述 可以通过类对象按时间顺序的消息交互(顺序图)来描述也可以通过类对象之间协作(通信图)来描述。,4、创建用例实现,用类图描
8、述用例实现在浏览器中Analysis Model下的“销售管理”包下选择用例实现【更新销售信息】。右击,在弹出菜单中选择【New】【Class Diagram】。创建一个新的类图,命名为“更新销售”。双击【更新商品】,打开“更新销售”类图。将Analysis Model下“销售管理”包中的类:“销售管理窗体”、“商品信息控制”、“销售表”拖到这个“更新商品”类图中。得到如图6-11所示的“更新商品信息”用例实现的类图。,4、创建用例实现,用类图描述用例实现,图6-11 “更新销售信息”用例实现的类图,5、用例实现的顺序图描述,顺序图包含4个元素,分别是对象(Object)、生命线(Lifeli
9、ne)、消息(Message)和激活(Activation)。,5、用例实现的顺序图描述,使用顺序图对系统建模时,可以遵循如下策略:设置交互的语境,这些语境可以是系统、子系统、操作、类、用例和协作的一个脚本。通过识别对象在交互过程中扮演的参与者,根据对象的重要性,将其从左向右的方向放在顺序图中。设置每个对象的生命线。一般情况下,对象存在于交互的整个过程,但它也可以在交互过程中创建和撤销。,5、用例实现的顺序图描述,从引发某个交互的信息开始,在生命线之间按从上向下的顺序画出随后的消息。设置对象的激活期,这可以可视化实际计算发生时的时间点、可视化消息的嵌套。如果需要设置时间或空间的约束,可以用时间
10、标记修饰每个消息,并附上合适的时间和空间约束。如果需要形式化地说明某控制流,可以为每个消息附上前置或后置条件流。,5、用例实现的顺序图描述,一个独立的顺序图只能显示一个控制流,通常说来,一个完整的控制流肯定是复杂的,所以将一个大的控制流分为几个部分放在不同的图中是比较合适的。,5、用例实现的顺序图描述,使用Rational Rose绘制顺序图过程如下:1)创建顺序图 2)添加对象3)添加消息4)完成“更新销售信息”顺序图,5、用例实现的顺序图描述,下图所示就是完成的更新销售信息顺序图,6、用例实现的通信图描述,通信图(Communication Diagram)是顺序图之外的另一种表示交互的方
11、法,通信图的一个用途是表示类操作的实现。 通信图包含3元素:对象(Object)、链(Line)和消息(Message)。顺序图和通信图之间的语义是等价的,描述的主要元素都是两个,即消息和对象。,6、用例实现的通信图描述,使用通信图对系统建模时,可以遵循如下策略:设置交互的语境。这里所指的语境可以是系统、子系统、操作、类、用例或用例的脚本。通过识别对象在交互过程中所扮演的参与者,开始绘制通信图,把这些对象作为图的顶点放在通信图中。其中较为重要的对象放在图的中央,与它邻近的对象放在外围。为每个对象设置初始特性。如果某对象的属性值、标记值、状态或参与者在交互期发生变化,则在图中放置一个复制对象,并
12、用变化后的值更新它,然后通过构造型become或copy的消息将这两者连接。,6、用例实现的通信图描述,设置了对象的初始值后,根据对象间的关系确定对象间链接。一般先确定关联的链接;因为这是最主要的,它代表了结构的链接。然后需要确定的是其他的链接,用合适的路径构造型修饰它们,显示地说明这些对象间是如何互相联系的。从引起交互的消息开始,按消息的顺序,把随后的消息附到适当的链接上,这描述了对象间的消息传递。可以用带小数点的编号来表达嵌套。如果需要说明时间或空间的约束,可以用适当的时间或空间约束来修饰每个消息。在建模中,如果想更详细的描述这个控制流,可以为交互过程中的每个消息都附上前置条件和后置条件。
13、,6、用例实现的通信图描述,使用Rational Rose绘制通信图过程如下:1)创建通信图2) 添加对象3) 添加消息4) 添加数据流,6、用例实现的通信图描述,下图就是更新销售信息的通信图,第三节 设计模型,1、设计模型概述 2、设计建模的一些观点 3、创建设计类 4、创建系统交互模型 5、创建系统动态模型-状态图 6、创建系统动态模型-活动图,1、设计模型概述,软件设计产生合理、健壮而稳定的软件构架,创建实现模型的蓝图。设计模型(Design Model)是描述用例的物理实现的对象模型,受功能和非功能需求,以及与实现环境有关的并最终影响系统的其它约束。设计模型是系统实现的抽象,作为系统实
14、现活动的重要输入。,1、设计模型概述,设计模型和分析模型都是为系统同一个部分建模,但是设计模型在接近代码的抽象层次上描述系统。 分析模型和设计模型之间存在简单的trace关系,设计模型是建立在分析模型的基础之上,也可以看作是把实现技术加入分析模型后对分析模型的精化和细化。,1、设计模型概述,设计模型和分析模型包含相同类型的物件,但是所有的制品更加完整成型,并且必须包含实现细节。 设计模型由设计子系统、设计类、接口、用例实现(设计)和部署图组成。,1、设计模型概述,设计类是实现阶段的类,是规格说明已经完成并且达到能够被实现程度的类。 设计类有两个来源: 其一是问题域中分析类的精化(一个分析类可以
15、变成零个、一个或多个设计类); 其二是解域中的实用类库、中间件、GUI库、可复用组件等。,1、设计模型概述,形式良好的设计类展现特定特征:类的公共操作定义它和类用户之间的契约。完整性类所包含的不能少于用户所有可能的合理要求。充分性类所包含的不能多于用户所有可能的合理要求。原始性服务应该是简单的、原始的和惟一的。,1、设计模型概述,高内聚每个类应当体现一个单一的、良好定义的抽象概念;所有操作都应当支持类的目的。低耦合类应该仅与足够的其他类耦合,已完成它的职责;只有在两个类之间存在真正语义关系时才能将它们耦合;不要仅仅为复用代码而耦合。应当从类用户的角度去评估设计类。,1、设计模型概述,设计模型与
16、选择的应用系统框架有密切的关系,直接影响到以后的代码生成。所以具有非常重要的地位。,1、设计模型概述,设计建模的原则:1)设计可追溯到分析模型2)经常关注待建系统的架构3)数据设计与功能设计同等重要4)必须设计接口(包括内部和外部接口)5)用户界面设计必须符合最终用户要求,1、设计模型概述,6)功能独立的构件级设计7)构件之间以及构件与外部环境之间松散耦合8)设计表述(模型)应该做到尽可能易于理解9)设计应该迭代式进行。每一次迭代,设计者都应该尽力简化,1、设计模型概述,恰当地应用以上设计原则,就能创造出兼顾内部高质量和外部高质量的设计。,2、设计建模的一些观点,由分析进入设计时,软件结构被完
17、成。每一个结构元素被加入到逻辑视图中作为包,需要时加入关系。例如:数据库、通信、错误处理等。,2、设计建模的一些观点,在设计期间,用户界面设计被完成。窗口设计窗口数量处理用户时间,2、设计建模的一些观点,1)加入设计级类在设计期间,类被加入以简化系统实现Utility类的加入提供了可以在多种背景下使用的公共服务包(如:数学运算)类的加入可以包装非面向对象的库和应用类的加入帮助执行一些需要的功能模型的合并可以解决设计问题Stereotypes可以用于表达类的目的,2、设计建模的一些观点,2)更新逻辑视图图形交互图被更新在domain类和被加入的实现类之间展现交互操作由于附加的设计类而修改交互操作
18、 类图被更新加入新包类间的新关系由于附加的设计类,关系可以被删除由于附加的设计类,包中的关系可以被修改,2、设计建模的一些观点,3)更新组件视图图形加入包组件图被更新附加包附加包的关系包的关系可以被改变,2、设计建模的一些观点,4)设计关系在设计期间,关系被完善导航-每种关系都被检测以便确定是否需要双向导航可视化链接-可视化链接加入到协同图中,以便帮助在关系中精练决定Containment-by value or by reference containment is decidedMultiplicity-re-visit multiplicity for each end of a rel
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件建模与UML 第六章 逻辑模型要点课件 软件 建模 UML 第六 逻辑 模型 要点 课件
链接地址:https://www.31ppt.com/p-1786858.html