第11章包模型与系统结构学案.ppt

11.1 包 的 概 念 　　在UML中，包(package)是一种分组机制或命名空间，也可以认为是一种集合元素或者容器元素，其中可以包含不同类型的产品。类似于文件管理中的文件夹，包中还可以包含包，以形成包的层次结构。包可以做为对包内多个相关元素整体的抽象，从而形成系统的高层抽象结构。　　在程序设计语言中，包也被看作命名空间，在同一个包中不允许同名的元素存在，但在不同的包中允许同名元素存在。这就为命名的分配和灵活性提供了便利条件。 　　在划分包时，一般将语义有联系的或者松散耦合的元素放在同一个包内，包的层次不要太深，三层以上的包结构会使系统变得相当难理解。包的UML表示如图11.1所示，类似于文件夹的符号。 11.2 包之间的依赖关系　　包与包之间可以存在依赖关系。如果某个包中的元素和另外一个包中的元素存在着依赖关系，则这两个包之间存在着依赖关系。图11.2所示是一个系统的三层结构，GUI包中包含了所有的界面元素，使用到Business Service包中提供的业务服务类，如订单管理类；同时也使用了Business Object包中的业务对象，如订单；业务服务类中，订单管理类也使用到业务对象订单类，此时这三个包就存在着依赖关系。 　　元素和包之间也可以有依赖关系，如果某个元素(用例、类、组件等)和某个包内的元素存在着关系(泛化、关联、依赖等)，则该元素和该包存在着依赖关系。如图11.3所示，业务服务包中的类使用到了数据库访问对象DAO，DAO的实现又使用到了Business Object。 图11.2 包依赖关系举例 图11.3 包依赖性举例 　　在包和接口之间也可以存在实现关系，如图11.4所示。如果包中的类实现了该接口，在这种情况下也可以画依赖关系，但语义更弱，实现关系则特指类实现接口。　　包机制也是一种封装或者隐藏机制，使用包名字来描述其中包含的所有元素的特性，这可以起到信息隐藏的作用，但也可以选择包内的元素(非子包元素)，使其暴露出来，如图11.5所示。 图11.4 包和接口之间的实现关系 图11.5 包中元素的隐藏与暴露 11.3 包 的 版 型　　包是对多个元素的封装，利用UML的扩充机制之一，即版型可以对该概念进行扩充，Rose中常用的包版型见表11.1。 表11.1 ROSE 部分常用包的版型符号 11.4 用包表示的系统高层结构　　用包及其关系可以表示业务系统或者信息系统的高层模型，例如系统体系结构。例如，图11.6表示了业务子系统之间的依赖关系，图11.7则表示了系统的多层结构。其中，Presentation是表示层，包中放置界面元素，如页面或者界面类；Application是应用层，其间放置应用逻辑，如订单管理；Domain是领域包，其中主要存放业务对象，如订单等；Persistence是持久层，其间存放操作实体对象的数据库操作实用类，如OrderDAO；Services是服务层，存放一些公共服务类，如单位转换类等。 图11.7 系统体系结构 11.5 设计包的原则 11.5.1 重用等价原则(REP)　　重用等价原则指的是当把类放入某个包时，应当考虑把整个包作为可重用的单元，即重用的粒度是包，包也是发布的粒度。为了方便使用者重用，要提高抽象级别，尽量将接口和实现类分离，使用依赖倒置和里氏替换原则来设计系统。这样当实现包内容修改时，用户能够尽量不修改代码或者少修改代码，也无需重新参考、引用或者依赖新的包。例如有些系统开发者喜欢把所有的公用类放在一个包中，该包中的类被使用的频度高、范围广，版本更新的频度也会比较高，一般都会统一地进行发布。 11.5.2 共同闭包原则(CCP)　　共同闭包原则指的是把那些需要同时改变的类放在一个包中。若一个类的修改会引起另外的类的修改，则尽量将这两个类放在一个包中。该原则实际上是说，如果两个类耦合比较强时，应该将其放在同一个包下，也就是提高包的内聚性，降低包与包之间的耦合性。这样，一个包内的元素修改之后就不会影响到另一个包。划分包的另一个主要原则是概念或者语义的相近性，而非单纯考虑耦合性。例如习惯上将所有的界面类放在一个包内，而将实体类放在另一个包内，界面类依赖于实体类，因此界面包依赖于实体包。当实体包修改时，肯定会影响到界面包，但是一般并不把界面类和实体类放在同一个包中，而是建立其间的依赖关系。　　包中的所有类对于同一类性质的变化应该是共同封闭的。即系统的某些变化若对一个包有影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响。例如系统界面风格需要变化，则会对界面包中的所有类进行变化。 11.5.3 共同重用原则(CRP)