新软件建模的技术3.ppt

7设计类图 设计类图（design class diagram）说明了软件类的规格说明和应用程序接口 设计类图的定义是在一个开发周期内的设计阶段中进行的。 7.1建立设计类图要依赖于 交互图—根据它，设计者能够识别出参与解决方案的软件类和类中的方法。 概念模型--根据它，设计者能够在类中添加细节。 与概念模型不同，一个设计类图显示了软件实体的定义而不是真实世界中的概念。 7.2表达的典型信息 类、关联和属性 接口及操作和常量 方法 属性类型信息 导航 类（接口）等元素之间的依赖关系 7.3何时创建设计类图 尽管设计类图的建立应该在建立交互图的下一步进行，但在实践中，通常两者是并行进行的。 在交互图建立之前，就可以运用职责分配的原则和设计模式在设计阶段的早期，大致描绘出类和方法名。 7.4如何建立设计类图 通过分析交互图，识别出所有参与软件解决方案的类 将他们在一个类图中绘出 复制概念模型中的相关概念的属性到类图的类中 通过分析交互图来为类图中的类添加方法 为属性和类型添加类型信息 在类图中添加关联，以支持必要的类之间的可见性 在关联上添加导航箭头，来指明属性可见性的方向 添加依赖关系的连线，来指明非属性的可见性。 7.5建立销售点系统的设计类图 --识别出软件类并画出它们 建立设计类图的第一步是识别出参与软件解决方案的类。为找出这些类，可以将交互图全部浏览一遍，然后列出交互图中所有的类。 7.5.1添加方法 每个类的方法可以通过协作图的分析得到。 通常，在所有协作图中发送给类X的消息集合能够说明类X必须定义的大多数方法。 7.5.2添加关联和导航 关联的每个端点被称为一个角色，在面向对象的设计类图中，角色可能带有一个导航箭头作为修饰。导航是角色的一个特性，它说明从源对象到目的对象沿着关联有一个单向连接。导航意味着可见性的存在，通常是属性可见性。 在面向对象的程序设计语言进行实现时导航箭头通常用源类中所定义的一个属性来实现，这个属性引用了目标类的一个实例。 在设计类图中，关联的选择要依据面向对象软件的“需要知道”原则—满足交互图中的可见性和存储特性。这与概念模型中的关联形成了对比。? 概念模型中的关联是以增进对问题域的理解为目的 7.5.3在下面的情况下，需要定义从A到B的带有导航标记的关联 A向B发送一个消息 A创建了B的一个实例 A需要维持到B之间的一个连接 7.5.4添加依赖关系 UML中包括了一组依赖关系（dependency relation）的表示法，用来表明一个元素（某种类型的元素，包括类、用例等）了解另一个元素。依赖关系用带箭头的虚线来表示。 在类图中，依赖关系在描绘类之间的非属性可见性时非常有用，即描述参数、全局或局部可见性时很有用。 8系统设计要点 8.1经典的三层体系结构 表示（Presentation）层—窗口、报表等 应用逻辑（Application Logic）层—管理业务过程的任务和规则 存储（Storage）层—持久化存储机构 三层体系结构的主要特征是将应用逻辑从软件系统中分离出来形成一个单独的逻辑中间层。表示层相对来说基本不处理应用业务过程，窗口将任务发给中间层。中间层与后端的存储层之间还要进行通信。 与2层比较：限制了软件重用 8.2面向对象的多层体系结构 一个推荐采用的面向对象信息系统的多层体系结构包括职责的分离，这种分离和经典的三层体系结构的功能分离类似。 在一个面向对象的设计中，应用逻辑可以进一步分解成一些更细的层。 8.3按软件类为基本组织结构 领域对象（Domain Object）层—代表领域概念的类 服务（Service）层—提供数据库交互、打印报表，安全性等功能服务对象 8.4部署 表示层和应用逻辑层位于客户机器上，存储层位于服务器上； 表示层位于客户机器上，应用逻辑层在应用逻辑服务器并且存储层在另一个数据服务器上。 8.5多层体系结构的动机 将应用逻辑作为单独的构件从系统中分离出来，以便这些构件在其他系统中能得到重用。 将各个层次分配到各个不同的物理计算节点，或者分配给不同的进程。这样可以改善系统性能、更好地支持客户和服务器系统中的信息共享和协调。 将不同的开发任务在开发者之间适当分配。（有效利用开发人员的专长和开发技巧，并且能提高并行开发能力） 8.6用UML包描述体系结构 UML提供了包（package）机制来说明元素组或者子系统。一个包可以是任何种类的一组模型元素。 整个系统都可以被认为是包含在一个最顶层的包中—system(系统)包。 一个包定义了一个嵌套的名字空间，因此同名元素在不同包内可能需要被复制。 包的UML表示法 体系结构包图 包的识别 将提供通用服务（或者一组相关服务集）