- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
第6讲. 从需求到设计 Cao Jian CIT Lab, Shanghai Jiaotong University 内容提要 从分析到设计 逻辑体系结构与包图 迈向对象设计 交互图 类图 1. 从分析到设计 2. 逻辑体系架构与UML包图 2.1 逻辑架构与层 逻辑架构是软件类的宏观组织结构,它将软件类组织成包,子系统和层等 层:对类、包或子系统的粗粒度的分组,具有对系统主要方面加以内聚的职责。较高的层可以调用较低的层。常见的层: 用户界面 应用逻辑和领域对象 技术服务 2.2 软件架构 架构是一组重要决策,其中涉及软件系统的组织,对结构元素及其组成系统的接口的选择,这些元素特定于其相互协作的行为,这些结构和行为元素到规模更大的子系统的组成,以及指导该组织结构(这些元素及其接口,协作和组成)的架构风格 2.3.1 包的引入 大型的软件系统中往往包含大量的建模元素 需要将它们有序的组织起来 包就是一种概念性的模型管理的图形工具 2.3.2包的语义 包是一种对模型元素进行成组组织的通用机制。包用于定义一个名字空间或容器(Container)。 运用包可以把语义上相近的可能一起变更的模型元素组织在同一个包中,对包中的元素作为一个整体对待,并且控制它们的可视性和存取。 包纯粹是一种概念性的模型元素,只存在于软件的开发过程中,因而与组件的概念是不一样的。 2.3.3 包的表示 包拥有内容,包括类、接口、组件、节点、协同。Use Case、图,甚至其它包 包与它所含的模型元素之间的关系是一种组合联系,即一个包由一个或多个模型元素组成,每一个模型元素都在该包中申明,一个模型元素只能为一个包唯一地拥有,一个包消失了,该包中所有元素都消失 不同包中的元素可以同名,但是同一包中的模型元素不能同名 包的模型元素名前可以有可视性标志,其表示方法与类中的属性和操作的可视性表示一样。 +,对于输入该包的任何包的模型元素都可见 -,对于外包不可见 #,只对其子包可见 2.3.4包的嵌套 包可以拥有其它包作为包内的元素,子包又可以拥有子包,这样就构成一个嵌套结构 包的嵌套层次不能太多,一般最多不超过2~3层 2.3.5 标准构造型 构造型和标记值说明其特定的性质,如包的作者,提供的服务等 《facade》:一个包仅仅是其它一些包的视图 《framework》:代表模型架构 《stub》:一个包是另一个包的公共内容的服务代理 《subsystem》:子系统 《system》:代表一个系统模型 2.4.1 包的联系种类 主要有两种: 依赖 泛化 2.4.2 依赖与输入依赖 依赖:一个元素的定义的改变会引起另一个元素发生相应改变 如对于类而言,一个类作为另一个类的数据的一部分,一个类用另一个类作为操作的参数等 两个包之间存在依赖是指两个包所含的模型元素之间存在着一个或多个依赖。 依赖关系的表示:用虚箭线从依赖包指向独立包 包的依赖关系没有传递性 包的依赖关系可以加上许多构造型规定它的语义,其中最常见的是输入依赖 输入依赖(Import Dependency)是包与包之间的一种存取(Access)依赖关系。输入(importing)允许一个包中的元素存取另一个包中的元素 输入依赖是单向的。 包的公共部分,即可视性为公共的模型元素,称为包的输出,包的输出只对另一个与它有输入依赖的包才是可视的,可存取的 输入依赖的表示,是在虚箭线上标有构造型《import》,箭头的方向从输入方的包指向输出方的包 表达存取依赖的另一构造型是《Access》, 《import》把目标包的内容加到源包的名字空间,因而无需限定(指出)它们的名称 《Access》不把目标包的内容加到源包的名字空间,因而需要指出它们的名称 2.4.3 泛化 与类的泛化关系一样:表示一般与特殊的关系 两个包之间存在泛化关系,指其中的特殊性包必须遵循一般性包的接口。 与类的继承相同,特殊包一般继承其所包含的公共类,并且可以重载和添加自己的类。 2.5使用层进行设计 系统的大型逻辑结构组织为独立的,职责相关的离散层,具有清晰内聚的关注分离。较低的层是低级别和一般性服务,较高的层则是与应用相关。 协作与耦合从较高层到较低层进行,避免从较低层到较高层的耦合 代码:将代码组织映射为层和UML包 UML工具:对代码逆向工程产生包图 领域层与应用逻辑层 典型的软件系统都有UI逻辑和应用逻辑,我们如何使用对象设计应用逻辑 “全能类”? 从真实世界出发设计对象,分配应用逻辑职责,称为领域对象,因此应用逻辑层被称为领域层 领域层和领域模型的关系:领域模型可以给我们领域层命名的灵感 不要把外部资源表示为最低层 大部分系统依赖于外部资源或服务,例如MySQL库存数据库。这些是物理实现构件,而不是逻辑结构中的层 就逻辑架构
文档评论(0)