第六章 - 代码生成

  • 个人认为全章都是重点

正向工程/逆向工程

代码生成

  • 考虑设计方案向实际运行方式的转变过程,即由概要设计产生出对应的程序代码框架的过程。
  • 工程化的设计方法将导致程序代码具有更好的可实现性、更好的可维护性和可修改性以及更好的可扩展性。
  • 先对类图到可运行程序的基本转换过程进行概要的说明,然后考虑对其优化和细化的过程。

逆向工程

  • 逆向工程的作用是将代码的修改反向映射回类图的设计中,从而在设计与代码实现之间保证一致性。
  • 逆向工程的一种特殊的情况是设计图纸完全由代码生成。
  • 逆向工程使得所有的开发都可以在CASE工具中同时展开,并使得设计类图与实现之间的相互对应。
  • 逆向工程需要设计和编码工具紧密集成和配合。

类的信息与基本实现(!)

  • 一个类图如果要成功翻译成为代码的蓝图,类模型中的内容必须要完整。需要包含的信息:
    • 每个实例变量,需要指定其类型;
    • 每个方法中的参数和返回值,需要指定其类型;
    • 每个关联关系,其关联类型、使用或导航方向必须说明。
      在这里插入图片描述
  • 带有下划线的方法和属性表示静态方法和静态变量。
  • 静态变量的使用需要仔细斟酌,因为破坏了面向对象的本地性(封装性)原则。
  • 静态变量和静态方法通常用在一般性的常规工作,如记录文件的存储路径,常规的数值计算等(工具)功能。

关联关系(!)

  • 通过关联的定义明确了类与类之间的静态关系,关联关系的实现最终体现为对应类中增加的实例变量(成员变量)。
  • 变量存在的具体形式依赖于关联的具体类型。

1.导航至“可选”方向

在这里插入图片描述

  • 多重性“0…1”明确了项目任务可以不分配工作人员,即在代码中对应类的实例变量可以不赋任何值,在类构造时也可不必对该变量初始化,在具体编程语言中通常通过一个对空值(NULL)的引用,不分配任何存储空间。
  • 实例变量并不需要在声明时赋值,可以通过set方法在后期需要的时候赋值。
  • 实例变量director声明后可以一直为NULL值,但却不能通过任何的方法显式的对其赋予NULL值,这是隐含的业务规则。

2. 导航至“唯一”方向

在这里插入图片描述

  • 描述一个项目任务对象必须要有一位工作人员对应,也就不存在是否可以对该变量进行空值引用的问题。
  • 为确保以上约定,可以在该实例变量声明时同时赋予初始值,可以按照如下的方式进行实现:private Employee director = new Employee();
  • 该类的每个构造函数中对实例变量director都需要指定一个有意义的值。这时可以将实例变量声明时的初始化去掉。

3.导航至“任意”方向

在这里插入图片描述

  • 描述一个项目任务可以安排任意多个工作人员与之对应。
  • 这些工作人员也是通过实例变量director进行管理的,只是这时该变量的类型应为某种集合类型(集合类型在C++中也叫Container)。
  • 基本集合类型如下:
    在这里插入图片描述
  • 使用List模板类的模型:
    在这里插入图片描述
  • 在Java语言中,可以使用集合List接口类型对应允许元素重复的集合类型,并使用ArrayList进行实现。
  • 在选用具体的集合类型时要仔细考虑,是否在运行时间和存储空间上能够真正满足要求并进行了最佳的实现。
  • 比如List允许元素重复出现,如果这不是希望的,则应该在元素加入前进行目标元素是否已经存在的检查。

对象间归属关系(*)

1.聚合 Aggregation

在这里插入图片描述

  • 描述一个员工对象不是仅仅与一个项目任务对应,而是可以同时参与到多个项目任务,即在这些项目间共享。
  • 使用接口的设计:
    • 接口中只含有ProjectTask需要的方法,屏蔽Employee中其它方法。
    • 但通过强制类型转换(Cast)也可以从该接口转化为类型为Employee的对象。
      在这里插入图片描述
  • 另一种设计:
    • 另外一种不破坏封装性的设计想法是类ProjectTask的方法不返回任何Employee类型的对象,这也意味着只有类ProjectTask允许对Employee的对象进行操作。
    • 如需要对外提供修改员工对象的服务,则在类ProjectTask对应提供一具有修改能力的公共函数:public void updateLastNameDirector(in lastname: String)
    • 其实现是通过调用Employee类中的setLastname()函数并通过参数的传递完成实际的修改。这种方式的使用在聚合(Aggregation)关系中是很常用的。

关联关系的问题

  • 关联关系(包括聚合)的代码在一定程度上破坏了实例变量的封装性。
  • 比如某个获得Employee对象引用的类就可以直接调用Employee的所有公共方法,从而可以直接对ProjectTask的实例变量进行修改。

2.组合 Composition

在这里插入图片描述

  • 描述两个类之间的一种“存在依赖性”,即如果类ProjectTask的对象被删除,其所属的所有工作人员会被同时删除。
  • 这种情况可能的一种解释为:员工指代一种工作合同,通过该工作合同被雇佣,当任务合同结束后工作关系自动解除,合同也没有存在的必要了,会被同时删除。

3.依赖

在这里插入图片描述

  • 与静态的关联关系不同,依赖关系主要用来描述对象间访问的瞬时性,比如将某些类向其它类进行传递,这种瞬时关系并不在对象间保持
  • 可以使用<>代替<>
  • 如果不影响类图的清晰性和阅读性,关联关系和依赖关系都可以在设计类图中说明

举例

  • 关联
    在这里插入图片描述
  • 依赖
    在这里插入图片描述
  • 总的来说,关系强弱排序:组合>聚合>关联>依赖

UML构件图、 部署图

1.UML视图

在这里插入图片描述

  • 进程视图:
    • 可能的独立运行的进程或者线程以及关联的活动对象。
    • Java是从Thread类继承或Runnable接口实现的类,具有方法run()。
    • UML中另外的描述使用构造型<<thread>><<process>>对活动类进行表示。
      在这里插入图片描述
  • 开发视图:
    • 构件图能够描述多个构件的构成及它们之间的联系。
    • 除了接口说明外,可以通过<<realization>>说明该构件中包含的类、其它工件<<artifact>>、相关文件和资源等。
      在这里插入图片描述
  • 物理视图
    • 部署图描述哪些软件构件最终在哪些机器上运行的情况
    • 硬件节点、可运行程序<<executable>>和相关工件<<artifact>>
    • 网络连接数目
      在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/qq_42739587/article/details/114647817