分析

引言

在分析阶段，我们通过精化和组织需求不会阶段所描述的需求来对其进行分析。 这样做的目的时为了更精确地理解需求，也是为了得到一个易于维护且有助于确定系统结构的需求描述。

即使我们与客户就系统功能达成了共识，但很可能还存在着尚未解决的系统需求问题：

• 用况必须尽量保持独立。所以，在需求捕获阶段，用况之间的干扰、并非与冲突问题可能没有得到解决。
• 用况必须使用客户语言来描述。在不求捕获阶段，许多本来可以用更形式化的图符来景区描述的细节问题，可能因此得不到解决，或者只能进行模糊的描述。
• 每个用况的构造都是为了构成完整而且直观的功能规格说明。关于所描述的需求见的荣誉问题可能无法在需求捕获期间解决。

由于存在上述为解决的问题，分析的主要目的就是通过进一步深入分析需求来使问题得以解决，但与需求捕获象彼，最主要的差别在于它可以使用开发人员的语言来描述这些结果。

我们可以在分析阶段更多地探究系统内部，从而解决用况间的干肉以及类似的我呢提。

在分析阶段哦我们卡可以蚕蛹更为行书的语言对系统需求中的细节问题进行描述，我们称之为“精化需求”。

在分析阶段，我可以以易于理解、易于组织、易于更改和一一重现哦那个的方式来组织需求。

通过分析得到的需求结构还可以用作构造整个系统的基本输入，因为我们希望实现一个整体可维护的系统，而不仅仅使描述系统需求。

分析概述

分析阶段中所用的语言是基于一种称为分析模型的概念曾对象模型。

分析模型有助于我们按前面所提出的路线精化需求，并探究系统的内部，包括其内部的共享资源。实际上内部资源可以表思维分析模型中的对象。而且，分析模型提供了更强的表达能力和形式化方法。分析模型还有助于我们组织需求，并能提供一种侧重于可维护性的结构。

为什么分析不同于设计与实现

原因在于：设计与实现远比分析复杂，因此需要分开来考虑。

通过分析，我们实现了对所关心问题的分离：通过界定在后续的设计与实现活动应解决的问题和应作出的决定来准备和简化这些活动。

分析目的：小结

一分析模型的形式来分析需求是很重要的：

• 分析模型产生的需求规格说明比从需求捕获得到的结构更为精确。
• 分析模型使用开发人员的语言来米搜狐，因此可以引入更为形式化的方法，用户探究系统内部的运作方式。
• 分析模型以易于理解、易于编织易于改变的方式，总之，以易于维护的方式来组织需求
• 分析模型可以看作是设计模型的切入点。

何时使用分析的具体实例

• 通过单独地进行分析，而不是将 它作为设计与实现的一个完整部分来执行，可以用较低的成本完成大部分系统分析工作。然后可以利用分析的结构来规划后续的设计与实现工作。
• 分析提供了系统的盖帽，而通过研究设计或实现的结构来了解系统可能会更苦难一些。
• 系统的而某些部分存在备选的设计或实现。
• 系统构造时使用了一个复杂的遗留系统。

分析在软件生命周期中的作用

最初的细化迭代终点在于分析。它有助于建立一个可靠且稳定的构架，并利于深入理解需求。之后，在细化阶段的木器与构造阶段，当构架以及稳定并且需求明确后，终点便转移到设计与实现上。

对于每个项目，都应该以某种方式达到分析的目的和目标。但是，集体如何看到和使用分析，每个项目可能各不相同：

• 项目使用分析模型来描述分析结构，并在整个软件生命周期内维护该模型的一致性。
• 项目使用分析模型来描述分析结构，但晋江七十位过渡性的中间工作，可能终点在细化阶段。此后，在构造阶段，随着设计与实现活动的展开，就不在维护分析模型。
• 项目分本就不适用分析模来描述分析结构，而是将分析需求作为需求捕获或设计的一个完整部分。

制品

制品：分析模型

分析模型由代表该模型顶层包的分析系统来表示。使用其他分析包可将分析模型组织成为更易于管理的若干部分，这些部分代表了对系统设计中的子系统或可能时整个系统的某一层的抽象。分析类则代表了对系统设计中的类或子系统的抽象。在分析模型中年，用况时通过分析类机器对象实现的，并由分析模型中的各种写作来表示，并标志位用况实现-分析。

制品：分析类

分析类带波案例对系统设计中的一个或几个类或若干子系统的抽象。这种抽象具有如下特点：

• 分析类侧重于处理功能性需求，而把非功能性需求推出到后续的设计与实现活动中将这些需求表示为类的具体需求是在实现。这使得分析类在问题与语境中更加突出、更加概念和，而且预期对应的设计与实现类象彼具有更大的粒度。
• 分析类很少根据操作机器特征标记来定义或提供接口，而是通过较高的、非形式化层次的职责来定期其行为。职责时对由类定义行为的内聚自己的文本描述
• 分析类定义属性，但这些属性还处于较高的层次。通常这些属性的类型时概念性的，而且应从问题领域来考虑。分析期间定义的各种书信他通常在设计与是西安阶段对应各种类。
• 分析类涉及到关系，尽管这些关系和设计与实现阶段的对应部分象彼更加概念和。
• 分析类总能符合三种基本构造型中的一种：边界类、控制类或实体类。

边界类

边界类用于建立系统与其参与者之间交互的模型。这种交互通常包括接受来自用户和外部系统的信息与请求以及将信息与请求提交到用户和外部系统。

边界类对系统中依赖于参与者的部分江门，也就是说，边界类用于阐明和手机系统的边界需求。这样，通常就把用户界面或通信接口的变化隔离在一个或多个边界类中。

边界类仍然应该保持在一个较高的概念化层次上。只要边界类能够说明通过交互所实现的目标就足够，而不必描述如何具体实现这种交互，因为这是在后续的设计与实现活动中所考虑的问题。

每个边界类至少应该与一个参与者有关，反之亦然。

实体类

实体类用于对畅销且持久的信息建模。实体类主要时对诸如个体、实际对象或实际时间的某些现象或概念的信息及相关行为建模。

大多数情况下，实体类时直接从业务对象某些中相应的业务实体类得到的。

控制类

控制类代表协调、排序、事务处理以及对其他对象的控制，经常用于封装与某个具体用况有关的控制。

系统的动态特征通过控制类来建模，因为控制类处理和协调主要的动作和控制流，并将任务委派给其他对象。

控制类并不封装与参与者交互有关的我呢提，也不封装与系统处理的畅销、齿距信息有关的问题，这些我呢提分别时由边界类和实体类封装的。而控制类对控制、协调、排序、事务处理、又是时设计其他多个对象的复杂业务楼及进行恩准，因而能将它们与变化隔离开来。

制品：用况实现-分析

用况实现-分析时分析模型内部的一种协作，它描述了如何根据分析类几千台交互的分析对象来是西安和执行一个具体的用况。于是，一个用况实现便可以很直接跟踪到用况模型中的具体用况。

用况实现包括事件流的文本描反应参与用况实现的分析类的类图以及按照分析对象的交互作用描述特定六实现或用况脚本的交互图。

类图

一个分析类机器对象经常参与多个用况实现，而一个具体类的某些职责、属性及管理通常至于一个用况实现相关。因此，在分析期间，协调不同的用况实现可能具有的类机器对象上的所有需求时重要de.zhel做到这一点，我们为用况实现附加上类图，以表明参与用况实现得嘞及其关系。

交互图

当参与者像系统发送某种形式的消息而激活用况时，开始执行该用况中的动作序列。在分析阶段，建议使用协作图来描述用况的是西安，因为我们主要关重的时确定需求和对象的职责，而不是确定详细的按时间顺序的交互序列。

对于用况是西安中分析对象的创建与中间，不同对象具有不同的生命周期：

• 一个边界对象无需专用于一个用况是西安。但是边界对象经常时在单个用况是西安的内部创建和中介的
• 一个实体对象通常不专用于一个用可实现。
• 控制类通常对于具体用况有感的控制进行封装，着表明控制对象时在用况开始时创建，而在用况结束时中介。

时间-分析流

描述用况是西安的图v本身不易读懂，因此，补充椅子额解释性的文本可能很有用。文本应该按照对象来写，正是它们之间的相互作用实现了用况。但是文本不应该提及任何哟管对象的属性、职责以及关联等内容，因为它们变化的很频繁以致不易维护。

特殊需求

特殊需求时对手机到的一个用况是西安上的所有肺功能需求的文本说明。其中有些需求在需求工作流期间已经以某种形式被捕获，只需针对用况是西安-分析将它们进行一定变化即可。但有些需求则时新的或随着分析工作的进行而派生出来的。

制品：分析包

分析包提供了一种方法，以可关系分块的方式对分析模型的制品进行组织。分析包可以包括分析类、用况实现及其他分析包。

分析包应该具有腔内举行于弱耦合性。

此外，分析包还具有一下特点：

• 分析包可以表示对分析内容的分割
• 分析包应基于功能性需求于问题领域来创建，并且应能够被具有该领域知识的人所理解。
• 分析包很可能称为设计模型中两个高级应用层中的子系统，或在子系统中分布。

服务包

除了向参与者提供用况之外，每个系统还向其客户提供一组服务。客户抽取适当的服务组合以便向它的用户提供必须的用况来完成业务：

• 一个用况确定了一个动作序列。通常，用况不是鼓励存在的
• 一个服务表示用于多个用况的、功能上紧密相关的动作集合。
• 用况针对用户，而服务针对客户。

在统一过程中，服务的giant是由服务包支持的。服务包在按照系统提供的服务而组织的分析包层次结构中处于较低层。关于服务包需要注意以下几点：

• 服务包包含了一组功能上相关的类
• 服务包时不可分割的。每个用户要么得到服务包中的所有类，要么根本得不到其中的任何一个类。
• 在实现用况时，可能会由一个或多个服务包参与其实现。
• 一个服务包经常很少于其他服务巴奥相关
• 一个福报往往至于一个或少数几个参与者有关
• 以复服务包所定义的功能，在设计于实现时可作为一个单独交互的单元来处理
• 服务包可能时互相排斥的，或则和它们可以表示同一种服务的不同方面或不同形式
• 服务包构成了后续的设计和实现活动的基本输入，并将按章服务仔细听来辅助构造设计和实现模型

服务包时可重用的

服务包称为饭呢西歧见针对重用进行构造的主要工具，它还影响到系统的设计于实现，并最终获得可重用的构件。

制品：构架描述（分析模型的视图）

通常认为分析模型中的夏利制品对构架时重要的：

• 从分析模型到分析包机器依赖关系的分解。在设计和实现期间，这种分继往往会影响到处于高曾子系统，因此，它对整个构架而言通常时很重要的。
• 关键的分析类；封装重要通信接口和和用户阶段机制的边界类；封装具有较大覆盖范围的重要时间序列的控制类；以及通用的、主要的、与其他分析类关系紧密的分析类。
• 实现某些重要的关键性功能的用况实现。

工作人员

工作人员：构架设计师

在分析工作流期间，构架设计师对分析模型的完整性复杂，却博爱分析模型作为一个整体的正确性、一致性和易读性。

工作人员：用况工程师

用况工程师复杂一个或几个用况实现的完整性，却博爱它们实现了格子的需求。

工作人员：构件工程师

构件工程师定义并维护一个或多个分析类的职责、属性、关系和特殊需求，确保每个分析类能实现来自它所参与的哥哥用况实现的需求。

构件工程师还要维护一个或多个分析包的完整性，包括却博爱它们内容的正确性以及对其他分析包依赖的正确性和最小性。

工作流

分析模型的建立时由构架设计师通过确定主要分析包、仙剑的实体类和公用需求启动的。而后，用况工程师通过规定参与分析类的每个类的行为需求来实现每个用况。然后这些需求又由构件工程师为每个类创建一致的职责、属性和类之间的关系确定下来并集成到每个类中。

活动：构架分析

构架分析的目的时通过确定分析包、仙剑的分析类和公用的特殊去修来概述分析模型和构架。

确定分析包

分析包提供了一种方式，用于将分析模型组织成更小、更可管理的快。

最初确定分析包自然时基于功能需求和问题领域。因为要将功能需求捕获为用况，所以一种确定分析包的简单方式是将一些用况的主要部分分配给一个具体包，然后再该报中实现相应的功能。以下是将用况恰当地分配给具体包的准则：

• 需要支持一个具体业务过程的用况。
• 需要支持系统的一个具体参与者的用况。
• 通过泛化和扩展关系建立用况的关联。

这种包会将变化分别局限于一个业务过程、一个参与者行为或一个紧密相关的用况集合中。这种方法再最初有助于将用况分配到包中。用况通常并不局限于一个包内，而是跨越几个包。因此，随着分析工作的进行，当用况时限为类之间的写作时，就会得到一个更加精化的包结构。

确定分析包之间的共性

再包间经常会发现共性的内容。处理这种情况的恰当方法是抽取出共享类，把它作为一个单独的分析包，或知识放到其他包的外面，然后让其他包依赖于这个通用的包或类。

这种表示共性的共享类很想是实体类，且可跟踪到领域或业务的实体类。因此，如果领域或业务的实体类是共享的，就值得对它们进行研究，而且通用分析包是再分析阶段中才确定的。

确定服务包

恰当的服务包通常是再分析工作的后期、当对功能需求有了清晰的理解并且大多数分析类已经存在的适合确定的。统一服务包中的分析类都是用于相同的服务。

通常按以下步骤来确定服务包：

• 为每个可选的服务确定一个服务包。这种鞥服务包是一个定制的单元。
• 为每个科恩那个称为可选的服务确定一个服务包。为由功能相关的类所提供的每个服务确定一个服务包。

定义分析包间的依赖

如果分析包的内容间彼此关联，就应该定义分析包间的依赖。

我们的目标是确定相对独立和低耦合度、但具有高内聚性的包。为了阐明这种依赖，对分析模型划分层次是有益的，可以将钻用应用包放在一个较高层，而将多个通用包放在一个较低层。

确定显见的实体类

通常恰当的方法是，基于再需求捕获阶段定义的领域类和业务实体，对最重要的实体类提出初步建议。然而，大部分类是创建用况实现时定义的。

领域模型中领域类之间的聚合和关联可用于确定相应实体类之间的暂时的关联集合。

确定公用的特殊需求

特殊需求是再分析过程中出现的需求，捕获它以便再后续的世界和实现活动中进行适当处理时十分重要的。

构架设计师复杂确定公用的特殊需求，以便开发人员能够引用它们作为个别的用况实现和分析类的特殊需求。

活动：分析用况

分析一个用况的目的在于：

• 确定分析类，其对象要执行用况的事件流。
• 将用况的行为分配给像交互的分析对象。
• 捕获用况实现中的特定需求。

用况分析的另一术语时用况精化，我将每个永康精化为分析类的协作。

确定分析类

再这一步，我们确定控制类、实体类和边界类，它们对于实现用况和表示他们的名称、职责、属性和关系是必须的。需求中描述的用况对于确定分析类有时还不够详细。为了确定分析类，必须就系统内部类精化用况说明。这种精化应该再事件的文本流中被捕获，用以作为用况实现的分析描述。以下是确定分析类的一般性准则：

• 通过详细研究用况说明和已有的领域模型来确定实体类，接着考虑用况实现中需要设计和处理的信息。
• 为每个由人充当的参与者确定一个主要边界类，并使这个类代表于参与者像交互的用户界面中的主窗口。
• 为每个初期建立的实体类确定一个基本边界类。
• 为每个由外部系统充当的参与者定义一个主要边界类，十七代表通信接口。
• 确定一个控制类，复杂处理用况实现中的控制和协调关系，然后按照用况实现的需求度该控制类进行精化。

描述分析对象间的交互

当有了一个实现用况所需要的分析类的框架之后，就需要描述对应的分析对象间如何进行交互。

捕获特殊需求

再这一步，我们捕获对一个用况实现的所有需求，如非功能性需求；这个用可实现使再分析阶段中确定，但应该再设计和实现阶段中进行处理。

再捕获这些需求时，尽可能参照已由构架师确定的公用特殊需求。

活动：分析类

分析一个类的目的在于：

• 依据分析类再用况实现中的角色来确定和维护它的职责。
• 确定和维护分析类的属性及其关系
• 捕获对该分析类实现的特殊需求

确定职责

通过组合一个类再不同用况实现中所充当的所有角色可以用例汇集该类的职责。通过呀牛它们的类图和交互图可以确定该参与的所有用况实现。

有多种方式可以用来汇集类的职责。一种简单的方法时每次从一个角色中抽取出职责，再附件上每次基于一个用况实现得到的补充职责或改变现存的职责。

确定属性

属性详细说明了分析类的特性，它通常由类的职责直接或间接决定。

确定关联和聚合

分析对象通过协作图中的链彼此进行交互。这些链通常时分析对象的相应类之间关联的食堂里。

类之间的关系数目尽量少。它主要不是现实事件中那种能作为聚合或关联来建模的关系，而是为了相应各种用可实现的需求而必须存在的那种关系。

构件工程师还要定义关联的郭崇兴、角色名称、子关联、关联类、有序角色、限定角色和n元关联。

确定泛化

再分析阶段，从几个不同的分析类中抽取共享和公用的行为是应该使用泛化。泛化应处于较高的概念层，其主要目的时使分析模型易于理解。

捕获特殊需求

研究用况实现的特殊需求，它们可能包哈喽与分析类有关的补充需求。

活动：分析包

分析一个包的目的在于：

• 却博爱该分析包尽可能与其他分析包无关。
• 确保该分析包能够达到实现一些领域类或用况的目的。
• 描述依赖以便能够对未来变化的影响进行估计。

下面使这种活动的一些通用的指南：

• 定义和维护改包与其他包的依赖。
• 确保报中包含恰当的类。通过只包含功能相关的对象来设法增强包的内聚性。
• 限制对其他包的依赖。如果报中包含了过于依赖其他包的类，应考虑对这些类进行重新定位。

分析小结

分析工作流的结果使分析模型，它使通过精化和组织需求来对其进行分析的概念性对象模型。分析模型包括一下元素：

• 分析包和服务包以及它们之间的关系和内容。
• 分析类、它们的职责、属性、关系和特殊需求。
• 用可实现-分析描述如何按照分析模型中的协作以及它们的特殊需求来精化用况。
• 分析模型的构件视图，包括对构件重要的元素。

分析模型会对设计模型产生如下的影响：

• 分析包和服务包会分别对专用车和通用应用层的设计子系统和服务子系统产生中啊哟影响。
• 分析类将用作射击类的规格说明
• 用可实现-分析由两个主要目的：
  • 有助于针对用况创建更为精确的规格说明
  • 作为设计用况使的输入。
• 分析毛线哦ing的构件视图再创建设计模型的构件视图时用作输入。