接口定义由某个分类器实现的一组操作。在设计模型中,接口主要用于定义子系统的接口。这不是说接口也不能用于类,而是对于单个类,在该类上定义公共操作(实际上是定义它的“接口”)通常就足够了。接口对于子系统是很重要的,因为它们允许行为声明(接口)与行为实现(子系统内实现接口的特定类)相分离。这种分离为我们提供了增强在系统不同部分上工作的开发团队的独立性的方法,同时保留这些不同部分之间的精确“合同”定义。
为每个子系统确定一组候选接口。使用在前一步中确定的已分组的协作,确定当启动协作时要“激活”的职责。然后,通过确定“客户端”必须提供的信息和协作完成时返回的信息来优化该职责;各组信息成为原型输入和输出参数并返回子系统将实现的操作的值。使用工作产品:特定于项目的指南中定义的命名约定为此操作定义名称。重复此操作,直到子系统将实现的所有操作都已定义。
接下来,按照操作相关的职责,将操作分组在一起。较小的组比较大的组更好,因为组中的操作越少,就越有可能存在一组内聚的公共职责。同样也要关注重用 -
查看相似性,这会使确定相关的可重用功能更容易。但同时,不应花大量时间尝试查找理想的职责分组;请记住,这只是首次划分的分组,优化将在整个精化阶段以迭代方式继续。
查看接口之间的相似性。
从一组候选接口中,查找相似的名称、职责和操作。若相同的操作存在于几个接口中,则重构这几个接口,将共同的操作抽取到一个新的接口中。请确保也查看了现有接口,可能的话重用这些接口。目标是维护接口的内聚性,同时除去接口之间的冗余操作。这将使接口更易理解并更易随着时间发展下去。
定义接口依赖关系。
每个接口操作的参数和返回值都具有特定类型:它们必须实现特定接口或必须是简单数据类型的实例。在参数是实现特定接口的对象的情况下,定义接口及其所依赖的接口之间的依赖关系。定义接口之间的依赖关系为软件设计人员提供了有用的耦合信息,因为接口依赖关系定义了设计模型中的元素之间的主要依赖关系。
将接口映射到子系统。
一旦确定了接口,就创建子系统和它实现的接口之间的实现关联。从子系统到接口的实现表明子系统中存在实现接口操作的一个或多个元素。当以后设计子系统时,将优化这些子系统-接口实现,通过子系统设计人员指定子系统内实现接口操作的特定元素。这些优化的实现只对子系统设计人员可见;从子系统客户端的角度来看,只能看到子系统-接口实现。
定义接口指定的行为。
接口通常为实现接口的元素定义隐式状态机。如果接口上的操作必须按特定顺序调用(如数据库连接必须先打开再使用),应该定义状态机,该状态机阐明公开可视的(或推测的)状态(这些状态是实现接口的任何设计元素必须支持的)。
此状态机将帮助接口用户更好了解接口,并将帮助元素(用于实现该接口)的设计人员提供元素的正确行为。
封装接口。
接口由软件设计人员所有;对接口的更改在体系结构上始终是很重要的。要管理对接口的更改,应将接口分组到由软件设计人员所有的一个或多个包中。如果所有接口是由一个子系统实现的,则可将接口与子系统放在同一个包中。如果接口是由多个子系统实现的,则应放在由软件设计人员所有的单独的包中。这样可在独立于各自的子系统的情况下管理和控制接口。
目的
|
确定使系统中的缝隙正式化的设计元素(仅 RT 设计)。
|
在事件驱动的系统中协议类似于接口:它们通过定义用于独立控制线程之间通信的一组匹配的信号来确定封装体之间的“合同”。接口主要用于使用函数调用模型来定义同步消息传递,而协议主要用于使用基于信号的消息传递来定义异步通信。协议允许行为声明(一组信号)与行为实现(子系统内实现接口的元素)相分离。这种分离为我们提供了增强在系统不同部分上工作的开发团队的独立性的方法,同时保留这些不同部分之间的精确“合同”定义。
为每个封装体确定一组进出信号。使用在前几步中确定的已分组的协作,确定当启动协作时要“激活”的职责。然后,通过确定“客户端”必须提供的信息和协作完成时返回的信息来优化该职责;各组信息成为信号的原型输入参数,该信号将由封装体通过它的一个端口实现。使用工作产品:特定于项目的指南中定义的命名约定为此信号定义名称。重复此操作,直到封装体将实现的所有信号都已定义。
接下来,按照信号相关的职责,将信号分组在一起。较小的组比较大的组更好,因为组中的信号越少,就越有可能存在一组内聚的公共职责。同样也要关注重用 -
查看相似性,这会使确定相关的可重用功能更容易。但同时,不应花大量时间尝试查找理想的职责分组;请记住,这只是首次划分的分组,优化将在整个精化阶段以迭代方式继续。为协议指定一个有意义的描述协议在封装体协作中扮演的角色的名称。
查看协议之间的相似性。
从一组候选协议中,查找相似的名称、职责和信号。若相同的信号存在于几个协议中,则重构这几个协议,将共同的信号抽取到一个新的接口中。请确保也查看了现有协议,可能的话重用这些协议。目的是维护协议的内聚性,同时除去协议之间的冗余信号。
这将使协议更易理解并更易随着时间发展下去。
将协议映射到封装体。 一旦确定了协议,就在实现协议的封装体上创建端口。封装体的端口定义封装体的“接口”,即可由封装体请求的行为。当以后设计封装体时,由端口指定的行为将用封装体的状态机描述。
定义协议指定的行为。协议通常为实现接口的元素定义隐式状态机。如果必须按特定顺序接收接口上的输入信号(如必须先接收“系统就绪”信号再接收特定错误信号),则应该定义状态机,该状态机阐明公开可视的(或推测的)状态(这些状态是实现协议的任何设计元素必须支持的)。
此状态机将帮助封装体(用于实现协议)的用户更好了解封装体的行为,并将帮助封装体的设计人员提供元素的正确行为。
封装协议。 协议由软件设计人员所有;对协议的更改在体系结构上始终是很重要的。要管理对协议的更改,应将接口分组到由软件设计人员所有的一个或多个包中。这样可在独立于实现协议的封装体的情况下管理和控制协议。
|