设计

引言

再设计阶段，我们将构造系统，并获得实现所有需求的系统系统组织。

设计的目的在于：

深入理解与非功能性需求和约束向联系的相关问题。
通过对单个子系统、接口和类的需求捕获，为后续的实现活动创建适当的输入和出发点。
能够把实现工作划分成更易于管理的哥哥部分，而且尽可能并非地由不同的开发组取开发。
再软件生命周期的早期捕获子系统之间的主要接口。
通过使用通用的符号，可以可视化地客户和思考设计。
建立对系统实现的无缝抽象，把实现看成是设计的直接精化。

设计再软件生命周期中的作用

设计工作集中再细化阶段的某期到构造阶段的初期，它将产生合理而稳定的构件，并创建实现模型的蓝图。再随后的构件阶段，当系统构架以及稳定并且需求以及被很好理解后，充电将转向系统的实现。

制品

制品：设计模型

设计模型是一个用于描述用况物理实现的对象模型，终点关注功能性需求和非功能性需求，同时也关注于实现环境有关的、并最终影响系统的其他约束。

设计模型作为系统实现的抽象，因而用作系统实现中活动的基本输入。

设计模型由设计系统来表示；设计系统表示模型的高曾子系统。利用其他子系统是将设计模型划分成更易于管理的功能块的一种方法。

设计子系统和射击类是系统实现中子系统和构架的抽象，这些抽象是简明的，它表示设计和实现间的简单映射。

再设计模型中，射击类及其对象实现了用况。

制品：设计类

射击类是系统实现中的一个类或相似构造的无缝抽象。抽象的五奉行表现再如下几个方面：

使用与编程语言相同的语言来描述射击类。
经常需要知名射击类的属性和操作的可视性。
当实现一个设计类时，该类与其他类之间的关系应该有直接了当的含义。
设计类的方法直接映射到该类的实现中相应的方法。
一个设计类可以通过表上实现性续期，而把这些需求推迟到后续的是西安活动中处理。
一个射击类通常给出构造型，它可以五逢低映射到某种指定编程语言所提供的结构。
如果编程语言支持，一个射击类能够是西安接口。
一个射击类可以时主动，这意味着该类的对象维护它们自己的控制线程，并与其他主动对象并非运行。

制品：用况实现-设计

用况是西安-设计时再设计模型内的协作关系，以射击类及其对象为基础，描述了一个特定用况的是西安和执行。一个用可实现-设计通过用可实现-分析跟踪到用况模型中的某个用况。

用况实现-设计有如下内容：

文字性的事件流描述
描述参与的射击类的类图。
根据设计对象之间的交互，描述特定流的是西安或用况脚本的交互图

用况实现-设计为相应的用况实现-分析提供了物理实现，而且它还处理再用况实现-分析中所捕获的大部分非功能性需求。

类图

我们用跟一个用况实现相联系的类图来描述参与的类、仔细以及它们之间的关系

交互图

当一个参与者通过向系统发送一些消息而调用某个用况时，就开始执行这个用况中的活动序列。如果从系统内部考虑，将有一些设计对象来接受该擦浴这的消息，然后这些设计对象再调用其他的设计对象，从而通过所有参与对象的交互来实现和执行该用况。在设计过程中，因为我们关重的终点时按时间顺序排列的交互蓄力，所以倾向于蚕蛹顺序图。

事件流-设计

一个用况实现的各种图通常河南理解。因此，用来解释和补充图和他们的表现的稳定性描述的事件流-设计就非常有用。

实现性需求

实现性需求时对耨个用况实现的需求集的文字描述。这些需求时在设计中捕获的，但最好时在实现时处理。

制品：设计子系统

设计子系统提供了一种将设计模型中的制品组织称为更易于管理的功能块的方法。一个设计子系统可以包括射击类、用况实现、接口和其他子系统。而且，一个子系统能够提供代表其与外界进行交互的功能接口。

一个子系统应该时紧耦合的，子系统见应该时松耦合的。此外，所设计的子系统应该具有如下的特点：

子系统可以表示对设计问题的分解。
在设计模型中最高的两个应用层以及它们的子系统可以直接跟踪到分析包或分析类。
子系统可以表示系统实现中的粗粒度构件。
子系统可以通过包括来表示可重用的软件产品。
通过报中，子系统可以用来表示整个一六系统或部分一六系统。

服务子系统

服务子系统在设计子系统层次结构中的较低曾使用，着与分析模型中使用服务包有相同的与那样。

对服务子系统的识别是基于分析模型中的服务包，它们之间通常存在一对一的跟踪。

服务子系统比相应的服务包要处理更多的问题：

服务子系统需要通过接口和它们的操作来提供服务。
服务子系统中以射击类取代了分析类，因此可以处理许多非功能性需求和其他与实现环境相关的约束。
一个服务子系统常常对应于实现中的而某个二进制代码或可执行狗酱。

制品：接口

接口用于详细说明由射击类和子系统所提供的操作。

一个提供接口的射击类，也必须提供实现该接口的操作的方法。一个提供接口的子系统，也必须包括提供该接口的射击类或者其他子系统。

接口提供了一种方法，把基于操作的功能说明于基于方法的具体实现区分开来。

制品：构架描述（设计模型的视图）

构件描述包含设计模型的构架视图。

通常认为在设计模型中有者重要构架意义的制品如下：

将设计模型划分为子系统以及它们的接口和相互依赖关系的分解。这写分继通过对构架是非常重要的，因为子系统和它们的接口组成了系统的基础构件。
核心的设计类，如哪些可以跟踪到对构件由重要意义的分析类的射击类、主动类，以及哪些处于中心地位的、通用的、表示通用设计机制、且于其他射击类由许多联系的射击类。
实现某些需要在软件生命周期早期开发的重要而且关键的功能的用况实现那-设计。

制品：实施模型

实施模型是一个描述系统物理分布的对象模型，它是按照如何在哥哥计算节点当中分布功能来进行描述的。

如下是对实施模型的几点解释：

每个节点表示也给计算资源，通常表示一个处理器或者类似的硬件设备。
节点拥有表示相互间通信方式的关联。
实施模型能够描述集中不同的网络配置
实施到一个节点上的构件定义了这个节点的功能。
实施模型本身表示软件构件于系统偶见之间的映射。

制品：构架描述（实施模型的视图）

软件描述包含实施模型的构件们试图。

鉴于其重要性，实施视图的u松油方面都要在构件视图中得以体现。

工作人员

工作人员：构架设计师

在设计过程中，构架设计师复杂保持设计和实施模型的完整性，以确保模型整体上是正确的、一致的和一度的。

工作人员：用况工程师

用况工程师复杂一个或多个用况实现-设计的完整性，以却博爱它们实现特定的需求。

工作人员：构件工程师

构架工程师复杂定义和维护一个或多个射击类的操作、方法、属性、关系以及实现性需求，以却博爱每个射击类实现由它所参与的用况实现对他提出的需求。

构架工程师还复杂保持一个或国歌子系统的完整性。

工作流

设计模型和实施模型的创建是由构架设计师启动的，它们勾画出实施模型的节点、设计模型中的主要子系统及其接口、包括主动类在内的重要的设计类以及通用的设计机制等。然后，用况工程师通过参与的射击类或子系统及其接口来实现每个用况。用况实现的结果规定了参与用况实现的每个类和紫铜的行为需求。这些序曲由构件工程师说明，并通过创建每个的一致的操作、属性和关系，或者通过创建每个子系统所提供的接口的一致操作，把这些需求集成到每个类中。

活动：构架设计

构架设计的目的是通过对如下内容的识别来勾画设计和实施模型及其构架：

节点及其网络配置。
子系统及其接口。
对构架由重要意义的射击类，如主动类。
处理共性需求的通用设计机制。

在整个构架设计活动过程中，构架设计师要考虑各种重用的可能性。要把所设计的子系统、接口和其他设计要素都合并到设计模型中。构架设计师还要维护、惊呼和更新构架描述以及设计模型和实施模型的构架视图。

识别节点和网络配置

物理网络的配置呕逆过程对软件构架由很大影响，着包括所需要的主动类以及网络节点间的功能分布。通常的网络配置使用三层模式，即把系统分离为可成、数据库功能层和业务逻辑曾。

网络配置包括如下几个方面：

包含哪些节点计意这些节点在处理能力和存储容量方面有些什么要求？
节点间采取合中连接方式，采用什么样的通信协议？
连接方式和通信协议由哪些特征
是否需要由容错处理能力、错误恢复模型、处理一致、数据备份等要求？

在了解了节点和连接方式的局限性和可能性后，构架设计师才能综合选择各种技术。

每种网络配置，包括用于测试和模拟的特殊配置，都应该用单独的是试图来描述。通过给定的网络配置，就可以开始考虑如何在节点当中分布功能了。

识别子系统及其接口

子系统提供了一种将设计模型组织成可管理片的方法。它们既可以通过细分设计工作的方式来初步识别，也可以随着设计模型进化和增长成一个需要被分解的较大的结构时再去发现。

识别应用子系统

在这一步，我们将识别专用应用层和通用应用层中的子系统。

如果在分析中找到适当的分析包分解，我们就能够尽可能地利用这些包取识别设计模型中相应的子系统。

与分析模型中前面的分析包象彼，在下面的情况下需要对这种初步的子系统分解做进一步的精化：

当前面的分析包中某部分映射到它本身的某个子系统时。
当前面的分析包的某些同分通过可重用的软件产品来实现时。
当前面的分析包不能恰当地反映工作的分解时。
当前面的分析包不能反映于遗留系统相结合时。
当前面的分析包不能直接实施到某个节点时。

识别中间件和系统软件子系统

中间件和系统软件是一个系统的基础，因为所有的功能都是基于其上的。选择并集成所获取或构造的软件产品时初始和细化阶段所关注的两个要点。

控制依赖性的一种方法时把每个已获取的软件产品看成时一个于系统其他部分由清晰接口的独立的子系统。

定义子系统间的依赖关系

如果子系统的内容相互有关，就应该定义子系统之间的依赖关系。

识别子系统接口

由子系统提供的接口定义来自外部子系统的访问擦偶哦。这些接口由子系统内部的类提供，或由子系统内部的其他子系统提供。

识别对构架由重要意义的设计类

在软件生周期的早期识别对构架由重要意义的设计类来启动设计工作，常常时很实际的。然而绝大多数设计类要大类设计活动中设计类时才能识别出来，并在用况设计用到结构的基础上精化。

根据分析类识别设计类

根据在分析过程中发现的对构架由重要意义的分析类，可以初步地勾画出一些设计类。而且，这些分析类间的关系可以用于识别相对应的设计类间的临时的关西街。

识别主动类

构架设计师才通过考虑系统的并发性需求，识别该系统所需要的主动类

识别通用的设计机制

在这一步，研究共性需求。需要做处理的需求通常与下面的问题有关：

持久性
透明的对象分布
安全特性
错误检查与恢复
事务管理

活动：设计一个用况

设计一个用况的目的是为了：

识别设计类或子系统，其实例需要取执行用况的事件流。
把用况的行为分布到有交互作用的设计对象或所参与的子系统。
定义对设计对象或子系统及其接口的操作需求。
为用况捕获实现性需求。

识别所参与的设计类

这一步，我们将识别用况所需要的设计类，步骤如下：

研究参与相应的用况实现-分析中的分析类，识别哪些由构件工程在类设计过程中创建的或者有勾结设计师在构件设计过程中创建的分析类所跟踪对应的设计类。
研究相应的用况实现-分析的特殊需求，识别哪些由构架设计师在构件设计过程中所发现的或者由构件工程在类设计过程中所发现的实现特殊需求的设计类。
最终应该识别所需要的类，并且应该只当一些构件工程师来复杂执行这一任务。
如果一些针对特定用况时合计的设计类仍然没有找到，用况工程师应该将该信息同胞构件设计师或者构件工程。

描述设计对象间的交互

当有了实现永康所需要的设计类的轮廓之后，就需要详细描述相应的设计对象时如何交互的。着可以通过使用包含参与的参与者实例、设计对象以及它们之间的消息传递的顺序图来实现。

顺序图的创建过程时：从用客流的初始点开始，逐个分析该用况流上的每一步，并决定哪些设计对象和参与者实例间的交互需要实现。注意：

用况由参与者实例到设计对象传递的消息所调用。
对于前面所表示出来的每个设计类，应该至少有一个设计对象参与到某个顺序图中。
消息在对象生命线间传递以便实现用况。
图中序列应该时首先要关注的，因为在用况实现时用况实现-设计时主要的输入。
利用标签和事件流-设计来补充顺序图。
顺序图应该处理要实现的用况的所有关系。

识别参与的子系统和接口

迄今为止，我们以及将用况设计称为类及其对象的协作。然而，有时候，用用况所参与的子系统或子系统皆苦来设计一个用况会更为合适。

首先，需要识别实现用况所需的子系统，步骤如下：

研究参与相应的用况实现-分析中的分析类。识别包含哪些分析类的分析包。然后识别能够跟踪到哪些分析包的设计子系统。
研究相应的用况实现-分析的特殊需求。识别实现哪些特殊需求的设计类。然后识别哪些类的设计子系统。

描述子系统间的交互作用

当有了实现用况所需的子系统的轮廓时，就需要描述它们所包含的类的对象在子系统曾上时如何交互的。

获取实现性需求

在这一步，我们将捕获基于一个用况实现的所有需。

活动：设计一个类

设计一个类的目的是为了创建一个设计类；这个设计类能够实现其在用况实现中以及非功能性需求中所要求的角色。着包括维护该设计类本身以及它的如下一些方面的内容：

操作
属性
所参与的关系
实现操作的方法
强制状态
对任何通用设计机制的依赖
与实现相关的续期
需要提供任何接口的正确实现。

勾画设计类

首先，需要根据给定分析类或接口作为输入来勾画出一个或几个设计类。

当给定一个或多个分析类作为输入时，使用的方法依赖于分析类的构造型：

边界类的设计一阿里与所蚕蛹的特定的接口技术
表示持久信息的实体类的设计经常安置使用特定的数据库技术的。
控制类的设计很棘手。我们需要考虑如下问题：
- 分布问题：如果时许需要被分布到网络中的几个不同节点当中并加以管理，那么在这些节点上需要单独的设计类来实现控制类。
- 性能问题：在哥哥节点上使用单独的设计类来实现控制了不一定合理，想法，可以由相同的设计类实现控制类
- 事务问题：控制类通常封装事务，它们相应的设计也必须与当前使用的事务管理技术像结合

识别操作

在这一步，我们将识别需要由设计类来提供的操作，并用编程语言的语法加以描述。笨猪的重要输入有：

设计类所跟踪的任何分析类的职责。
设计类所跟踪的任何分析类的特殊需求
设计类需要提供的接口
该类所参与的用况实现-设计。

识别属性

在这一步，我们将识别设计类所需的属性，并用编程语言的语法来加以描述。一个属性详细说明了一个设计类的特性，并经常被类的操作所隐含和调用。在识别属性时要牢记如下的通用知道方针：

考虑设计类所跟踪的任何分析类的属性
用编程语言来约束可用的属性类型。
当选择一个属性类型时，尽可能重用以及存在的属性类型
单个的属性实例不能被多个设计对象共享。
如果一个设计类因为其属性的原因变得复杂而难于理解，那么其中的一些属性可以分离出来编程它们自己的类。
如果一个类存在大量的或者复杂的属性，可以在一个单独的、只显示属性部分的类图中进行阐述。

识别关联和聚合

在顺序图中涉及对象相互作用，这种对象间的交互通常需要它们对应的类之间有关联。因此，构件工程师应该研究顺序途中的消息床底，已确定需要哪些关联。

类之间关系的数量应该最小化。

在识别和惊呼阿瓜连和聚合时，应牢记如下的通用知道方针：

考虑包括在相应的分析类中的关系和聚合。
在当前使用的编程语言的支持下，精化关联多重性、角色名称、关联类、有序角色、合中角色和n元关联
精化关联的到航行。

识别泛化

应该用与编程语言所定义的语法先沟通的语法来使用

描述方法

在涉及过程总，方法时用来详细说明操作时如何实现的。

描述状态

某些设计对象时有状态控制，也就是说，当它们接收到一个消息时，它们的状态决定来它们的行为。在这种情况下，用状态图来描述一个设计对象的不哦她那个状态转移就很有意义。

处理特殊需求

在这一步，我们将处理在前面步骤没有考虑到的任何需求。

活动：设计一个子系统

设计一个子系统的目的是为了：

确保该子系统进坑你地独立于别的子系统或它们的接口。
确保该子系统提供正确的接口。
确保该子系统实现其目标，及提供其接口所定义操作的正确实现。

维护子系统的依赖关系

应该定义和维护一个从子系统到其他子雄他那个的依赖关系。

维护子系统所提供的接口

由子系统所提供的接口所定义的操作需要支持该子系统在不同用况实现中所扮演的所有角色。

维护子系统的内容

当一个咨询哦那天提供由它的接口所定义操作的正确实现时，这个子系统就达到了它的目的。

设计小结

设计的主要结构时设计模型，设计模型收分析模型的影响，它要激励保持系统的结构，并用作实现的蓝图。设计模型包括如下一些元素：

设计子系统和服务子系统以及它们的依赖关系、接口和内容。居于最高两个层次的设计子系统的轮廓基于分析包。设计子系统的部分依赖关系的轮廓基于相应分析包的以来管。部分接口的轮廓基于分析类。
设计类，包括主动列以及它们的擦偶哦、属性、关系和实现性需求。一些对构件由重要意义的设计类的轮廓基于对构件由重要意义的分析类。
用况实现-设计，它描述如何用设计模型内的协作关系来设计用况。
设计模型的构件视图，包括对构件由重要意义的元素。

设计还阐述实施模型，它描述了系统分布应具备的任何网络配置。实施模型包括：

系欸但以及它们的特征和连接关系
主动类到节点的初步映射
实施模型的构件视图，包括对构件由重要意义的元素。设计模型和实施模型被看成时后续的实现和测试活动的主要输入，我们将在后面的章节中介绍这些内容。特别要注意的时：
设计咨询哦那天和服务咨询哦那天将由包含实际构件的实现子系统你里实现。浙西而是先咨询哦那天将一对一地对应到设计咨询哦那天
设计类将包含源代码的文件构件来实现。
当按很小的、可管理的步骤来规划和实施是西安工作时，将使用用况是西安-设计来阐述一些列的构造
当采用把可执行构件实施到系欸但上的方法来对系统进行分布时，将用到实施模型和网络配置。

设计

引言