面向对象嵌入式系统开发4-嵌入式系统分析

面向对象嵌入式系统开发4-嵌入式系统分析

4.1 嵌入式系统分析的内容与目标

 分析的目的是定义待开发系统的基本性质。所谓基本性质指的是如果没有他们，系统机会出错或者不完整的那些性质。换句话说"要源于用户需求，而高于用户需求“。
 分析关注的是分析模型（概念模型）的创建。分析中要确定的是必须完成哪些内容，而不是如何完成。分析从来就不是一个机械过程，对问题的准确表示要涉及经验和判断，在许多时候更像一种艺术。开发者在提出关于设计的复杂问题前，首先要全面地理解问题。合理的模型对于那些可扩展、高效的、可靠的和正确的应用来说是一个先决条件。
 在分析阶段，开发者要考虑如何利用现有的信息资源，如用户需求文档、业务会谈记录和相关的应用调研资料，并消除他们之间的歧义。由于对需求理解上存在的渐进迭代的必然性，业务专家常常无法确定出准确的需求，所以必须配合软件开发来细化需求。建模加速了开发者和业务专家之间的融合，因为模型的多次迭代要比代码多次实现更快速。
 系统需求分析更关注系统本身的功能需求和非功能需求部分。系统需求的获得不仅仅根据用户需求文档还要进行同用户的业务会谈和相关应用的调研活动。在处理大型复杂系统时，相关领域知识的学习对于建立正确的系统十分重要。
 嵌入式系统分析的最终结果是产生一个由类模型、状态模型和交互模型组成的分析框架。根据ROPES模型，分析过程分为需求分析、系统分析和对象分析三个子阶段。需求分析的目的是产生由用例图和顺序图组成的用户需求模型。用例来自于用户的功能需求，顺序图用来说明用例的行为过程和行为约束。从3.2.3小节可知系统分析主要涉及软件、机械和电子三方面给的系统级功能划分，通常在大规模复杂系统中占重要地位。如果从嵌入式软件视角出发，可以把系统分析和对象分析结合在一起而采用系统结构分析和系统行为分析两个步骤。系统结构分析的目的是找到系统的重要结构概念，形成在分析层面的类模型。系统行为分析则在类模型的基础上把系统外部可见的功能分解到内部结构元素上，最后完成系统的状态模型和交互模型。

4.2 用例驱动的嵌入式系统需求分析

 系统需求分析的根本问题就是要了解外部的重要对象以及他们与系统之间的相互作用。早期的需求分析可以理解为最最终产品外部行为的深入刨析过程，而后期的需求分析迭代主要是处理系统内部组件的边界定义。
 UML需求表示法的一个突出特点是很直观，而且开发人员可以根据用户可选的精确度和完整程度来选择详细的表示方法来未系统建模。需求分析中涉及到的主要问题有：

• 确定大的、相对独立的功能块，并以一种便于理解且无二义性的方式细化其行为
• 辨识外部环境中的参与者，这些参与者通过某些方式与系统交互。
• 给出系统和参与者集合之间传递的每条消息，保活那些表示事件发生的消息的寓意和特征。
• 对使用不同消息进行交互的协议进行细化，包括所要求的顺序关系、前置和后置条件不变量。
    需求通常是领域专家提出和指定的，这些专家可能是系统的最终用户、市场销售人员或者相关领域的研究人员。这些专家大多数不习惯严格按照系统开发人员的思维模式去考虑问题，这种分歧始终是分析人员需要拉近和填平的关键性鸿沟。需求分析的任务就是获取真正的需求。实际上，需求的获取不仅要获取并记录领域专家提出的需求，而且还要研究领域知识以便于对应用问题的确切理解。另外，分析人员还要站在开发人员的视角上去理解和描述需求，使得开发人员能够自然而然地理解所要面对的问题。
   系统需求通常分为功能需求和非功能需求。功能需求是外部可查看到的系统的预期行为。例如，通信录条目的录入等。这些功能性需求不考虑性能、可靠性和保险性，只需要落实系统需要做些什么。非功能需求也称约束条件或者服务质量需求Qos,它规定了相应功能需求的性能、可靠性以及保险性。非功能需求不独立存在，是对一个或多个功能需求的细化。例如，通信条目录入相继按键输入不超过2s。非相关性需求的获取需要分析人员的经验，有时这类需求会议”不言而喻“的方式从分析人员面前溜过。
   分析人员用来记录需求的主要工具是用例。用例描述的是系统的一项内聚的功能块，该功能块以黑盒形式对系统外部具有可见性。用例完全是是对行为的描述，不会定义或者隐含对象或者类的集合。一个用例是外部可见的，表明系统的该项行为要和系统的外部对象相互作用。这些系统外部的对象就是参与者。用例与参与者相关联，使得他们彼此之间能够交换信息。
   参与者可能是用户或者外部可见的子系统和设备，如传感器和执行器等。参与者是操作系统的人还是系统交互的设备，取决于系统的作用领域。如果系统开发包括与用户交互的设备开发，则用户是参与者。如果所开发的系统必须与某些现有的或者单独提供的设备交互，则这些设备是参与者。这根据系统的作用域，这些设备始于所定义的系统交互的第一个层面。另外，根据迭代增量式开发原则，在深入到系统的组件构成（如子系统、协作、模式）层次的分析时，组件外部的系统与组件交互，因而组件外部的系统也需要看成是参与者。
   有一点很重要：用例不定义甚至不暗指任何特定的系统内部结构。用例通过对象间的协作来实现。因此、从需求分析到对象分析会涉及到用例与对象间的多重映射关系。
   记录用例并给出相关的参与者仅是分析人员的小部分工作。分析人员必须给出参与者和系统间传递的消息以及相关属性和交互协议。消息是发送者和接收者之间的对象。消息往往具备一些必要的属性，以便刻画系统的功能及非功能需求。
   从逻辑的角度，消息包含语义和特征标记两个方面内容。消息的语义就是它的含义，比如”插入控制棒“等。特征标记指特征的名称和参数特性。前置条件不变式和后置条件不变式是两种基本状态，分别在消息发送前和消息接收后假定为真的条件表达式。在实际上，消息是从一个对象到另一个对象的通信，它可以是信号或者调用。
   消息的Qos特性主要包含消息的到达模式和消息的同步模式，也可以具有如可靠性等其他属性。如图
  
   事件可以触发消息的发送。事件会在对系统有一定意义的某个时空发生。UML定义四种事件构造型：信号事件、调用事件、改变事件和时间事件。
   信号事件代表接收到一个信号，该信号是对象之间进行通信协作的有名实体。触发器指定信号类型，事件的参数也就是信号的参数。信号由一个对象明确地发送给一个或一组对象。发送者在发送信号时明确地规定了信号的参数。接收者在接收到信号后可能出发0/1个转换。信号时对象间异步通信的显示手段。
   调用者表示接收到要给激活操作的请求，即接收到一个调用。期望的结果是事件的接收者除去一个转换或者提供一项服务，从而执行相应的操作。转换完成后，调用者收回控制权。
   改变事件表示满足事件中某个表达式所表述的布尔条件。触发器指定一个布尔条件作为表达式。这种事件隐含了对于控制条件的不间断测试。当条件从假变成真时，事件将发生，并将引发并激活对象的一个转换。如果对象内的一个属性的改变打算触发另一个对象的改变，而这个属性对另一个对象是不可见的，那么这种情况应建模为属性拥有者上的一个改变触发器，他触发一个内部转换并将一个信号发送给另一个对象。
   时间时间表示满足一个时间表达式，比如对象进入某个状态后经过一段给定的时间，或者到达某个绝对时间。触发器制定了事件表达式。无论是经过时间还是绝对时间，都可以用系统的现实时钟或者虚拟时钟来定义。

4.2.1用例

  参与者与系统的所有交互都可以量化成用例。例如，再打电话中，用例打电话会涉及到主叫和被叫两个用例。
 用例依赖于底层的事件和消息流。这些时间流和消息流在交互模型中都有所表示。
 用例标识系统的功能，并根据用户的观点来组织这些功能。在描述全局约束和其他非局部功能的时候，传统需求清单还是有作用的，例如平均故障时间以及整体吞吐量等。使用时把用例模型作为主要需求捕获手段而其他方法任然可以作为辅助技术。
 用例模型准则：

• 确定系统边界
• 确保关注参与者
    如果某个真实的对象体现了多种目的，就要分别用单个参与者来捕获他们。例如计算机可以划分三个参与者：系统管理员、数据库管理员和计算机用户。
• 每个用例必须给用户提供价值
   用例应该表示成给用户提供有价值的完整事务，而不应该被定义的过于狭窄。例如，打电话来说，拨电话号码就不是一个好用例，它只是一个有价值用例打电话的一部分。
• 关注用例和参与者
• 记住用例是非形式化的
• 用例可以结构化
  

4.2.2 用例的行为描述

 无论在任何层级（系统、子系统和类），一版把整个要处理的对象堪称是一个类元，分析过程分为外部特征捕获和内部特征捕获两个过程。在捕获外部特征时，主要关心类元的外部功能，这是用用例图、顺序图或状态机就可以描述类元的全部特征；对于类元的内部，则是要分析类元间的结构关系和交互行为。在较高层，一般通过协作图或类图来描述系统静态结构关系，用顺序图和通信图来描述子类元间的交互行为。如果有必要也可以从顺序图过渡到每个子类元的状态行为，即画出子类元的状态机（顺序图生命线上可以加入状态）。而在层级的最底层，类元本身就是类或对象，此时的外部特征主要表现为类或对象的对外关系和对外服务商。其外部特征一版通过上下文就能确定，如有必要仍可以使用用例图。而在类或对象的内部，其结构是通过属性类表示，而行为则是具体落实到操作或方法上面。这时行为模式可以通过状态机、活动图甚至其他算法描述手段进行。
 在实际分析中，通常在需求分析过程处理一个类元的外部特征，而类元的内部特征在系统分析和对象分析中完成。需求分析的下一个目标就是详细描述用例。
 名字本身无法详细定义说明用例所暗含的行为，并用来构建一个正确的系统。因此，UML允许开发者对用例的行为顺序做更详细的描述，但并未规定其描述工具。
 用例的实例时执行该用例行为的一条特定路径，这样的路径称为场景。场景是说明行为的一系列动作，是指系统某个特定的期间内所发生的一系列消息和时间集合。场景中有一些分支节点，与参与者或系统的响应或动作可能有多个。每一条单独的路径构成了单独的场景。通过，需要多个场景才能完整地描述一个用例的所有行为。
 描绘场景的最常用手段是顺序图。
 用例的行为顺序描述可以通过顺序图、状态机、活动图或者某种可执行的文本代码进行。图形化的描述一般是对用例需求的进一步深入理解和精华过程中完成的。至于采用哪一种描述方式，主要根据所在建模层级和所要描述行为的目的来决定。根据笔者经验，UML顺序图可以建模用例的绝大部分场景，如果还不能描述清楚时，才可虑使用其他方式。
 经验表明，几乎所有的领域专家都能看懂用例和场景。因为这些图形化表示的需求为讨论系统行为提供了公共的语义和符号。

图4.4是购买饮料用例的顺序图场景描述。很显然，顺序图描述的用例行为比自然语言描述更接近计算机表示。通过简单的参数化消息表示，如显示（脱销、投币或选择其他），可以未进一步的分析设计打好基础。带有关键字opt的片段，表示有条件执行的片段，当片段的监护条件为true时，该片段会执行。

4.2.3外部事件和消息

 系统作为一个概念上的整体，它包含索要开发的软件、电子和机械。用例图将系统显示为一个被显示设计中其他参与者包围的实体，描述了他们之间所传递的重要消息。在后期的设计过程中将决定消息的实现方式，如对象方法的调用、RTOS消息或者通信总线上的消息等。
在需求分析阶段，主要记述系统和与之交互的参与者之间交换的消息的基本属性。
 事件的发送对系统很重要。事件与类相似，可以包含数据。事件在系统中通常以对象间或者参与者与系统间的消息传递来显现。例如，一个控制旋钮被选择时可以发送一个事件。对于点击按钮或键盘类参与者，一个方法是每次点击按钮发送一个事件；另一种方法则限制点击事件以某种频率送。在后一种方法中，点击此处被作为事件消息的参数传递。因此在场景处理中事件通常被作为事件消息来操纵，所以在处理用例时，事件和消息基本上时同义词。
 消息到达描述了消息实例集的时序行为。UML没有直接对此进行规定，但是到达模式的特征刻画对可调度性分析和期限分析是至关重要的。尽早定义消息到达模式在嵌入式系统开发中是十分重要的。关于消息到达模式参考图4.1.通过消息和事件特征的了解，可以早一点完成不同类型处理器架构的性能分析，以便做出较好的业务决策，即产品是否能够在一个可接受的成本范围内提交。
 消息达到模式如果是偶发性的要进行可调度分析，就需要刻画偶发性事件达到时间的特征。偶发消息可以用如下特征进行描述：

-界定时间。比如最小/最大到达间隔时间
-集中趋势和离散统计。如平均到达速率及相应的标准偏差和标准误差。
-各个消息到达事件的自相关依赖关系。
 即使不知道背后的概率密度，对到达时间间隔进行界定也能够完成最坏情况分析。通常平均达到率是已知的，与之相关的离散统计量也是已知的。这些消息对软实时系统的的可调度性分析尤为有用。
 大多数简单的分析都假定事件达到是相互无关的。比如，一个消息的达到时间不会影响消息序列中下一个消息的达到时间。不过有时某些消息之间可能具有时间相关性（如在tcp/ip协议中被分解为多个ip包的数据).另外，也会遇到一类消息到达时间区域成批达到的模式，这样的消息称为突发消息。
 周期性消息具有一定的周期特征，消息按一定的周期到达，并可以有一定的抖动。抖动是指消息实际到达时间与周期点时间的偏离。抖动在建模的过程中通常被视为一个随机过程，但其值总要在一定的时间之内。
 UML标准明确地为同步模式提供支持，尽管支持能力不是很强。UML明确定义的同步有调用、异步和等待模式。
 调用和等待同步相似，两者都要求发送者阻塞，知道目标完成消息处理后方才继续。调用同步模拟同一控制线程内发生函数或方法调用时控制权的转让情况。等待同步则模拟了知道消息处理结束后才将控制交给另一线程的情况。远程过程调用RPC通常正是使用这种同步模式的。异步模式从本质上就是多线程模式，描述了把消息传递给另一个对象但不转让控制权的过程。
 在实时系统中，外部消息（事件）在约束和定义系统行为方面扮演着重要角色。比如，一个空中交通控制系统必须相应和处理来自多个传感器的消息，比如雷达的“ping”消息给出的角度和距离。
 事件本身提供的信息对系统开发来说是不够的。系统对每个事件的预期响应必须从系统需要完成的动作及对该响应的时间约束等方面进行说明。通常还会需要一个复杂的协议，用以描述事件的所有可能的合法序列和消息交换序列。单独的每个时间的特征通常可以在外部事件列表中记述。事件和消息交互协议最好用该用例相关的顺序图结合描述。
 在实时系统的领域中，定义外部定时需求对理解问题也是很关键的。一个即便是具有正确结果的消息而如果是提交时间过了期限，对于硬实时来说也属于系统失效。如果消息是周期性的，则他们的周期和抖动范围就必须定义；如果消息是偶发性的，他们的随机属性就必须被定义。系统的响应时间必须根据时间要求来定义。在软期限的系统中，则必须规定其他的守时性衡量方法，例如，可接受的平均延迟时间。
 很多动作的执行要持续一段很长的时间，过程的相应和处理顺序可能是非常重要的。例如，各类控制系统的事故处理，可能需要先关闭某些会造成危险的硬件然后再进行报警或相反。这些问题往往是领域和系统所特有的，在需求在要尽早明确下来。
 在大多数实时系统中，时间–响应需求是一项重要的指标。事实上，这类需求为系统要完成这一行为的一系列自行为定义了性能预算。随着对象和类被定义出来，这些性能预算会沿着分析和设计阶段传播下来。最后，性能需求在执行线程对事件作出响应时，体现为各个操作和函数调用的性能预算。所有子操作预计之和必须满足在最上层给出的系统性能需求。例如，对一个控制事件的响应需600ms，整个响应通过5个顺序操作实现的，在最坏情况下，这5个操作事件之和也不能超过600ms。

4.2.4 需求模型

 系统的需求模型由系统用例图再加上对用例行为顺序描述的顺序图组成。一般顺序图要对用例的主流、可选流和异常流分别表示。顺序图除了这些功用外，也可以捕获系统的大部分实时性约束需求。
 需求模型的建立过程主要是从确定系统的整体边界开始，再寻找参与者和识别用例，然后通过场景和顺序图来详细描述和充实用例。也可以为复杂的或者有充分
细节的用例编制活动图。需求模型的建立通过如下步骤进行：

-确定系统边界；
-寻找参与者；
-寻找用例
-寻找初始和终止事件；
-准备普通场景；
-增加变化和异常场景；
-寻找外部事件；
-画顺序图；
-组织参与者和用例；

确定系统边界

 必须要确定系统包含哪些功能。更重要的是，要确定它应该忽略哪些内容。如果系统边界确定的话，就可以把系统看成是一个和外界交互的黑盒。把整个系统看成是一个类元或者一个对象，而他的内部细节被隐藏起来。需求分析阶段，需要确定的是系统的意图以及呈现给参与者的视图。而在设计阶段，则是根据已经确定的外部行为为其建立能够实现该行为的内部结构。

寻找参与者

 参与者可以是人、外部设备和其他软件系统。参与者并不受系统的控制，可就是说参与者在使用系统时可能会犯错误。
 每个参与者都代表一个理想化的会执行一部分系统功能的用户。参与者呈现给系统的是一致的界面，外部对象可能会是多个参与者。例如,某人可能是同一家银行的出纳员和客户。

寻找用例

 用例将系统功能划分成少数离散单元，所有的系统行为都必须处在某种用例之下。确定要在什么地方安排用例边界行为并不十分容易。在划分分区的时候总是会出现边界情况，有时候不得不做出一些随意的决策。
 每个用例都应该表示系统所提供的一类服务，即给参与者提供有价值的内容。要努力是所有用例都保持相似的层次细节。要尽量关注用力的主要目标，并推迟实现策略。通常应该将用例与发起用例参与者关联起来，但用例图也应该涵盖其他的参与者。
 除了初步的用例图外，应该在每个用例下面写下一两句需要的用例描述。

寻找初始和终止事件

 用例将系统功能拆分成离散单元，并显示了每一个单元所涉及的参与者，但他们并没有清晰地显示行为。要理解行为就必须理解履行每一用例的行为顺序。可以从寻找每个用例的事件开始，确定哪个参与者发动了用例，并且定义它发送给系统的事件。在许多情形下，初始事件是对用例所提供服务的一种请求。在另一些情况下，初始事件是触发一些串活动的事件。
 还应该确定一个或多个终止事件以及每个用例究竟要包含多少个终止事件。例如，申请贷款的用例的终止事件包括提交申请，批准或拒绝贷款请求，交付贷款金额或最终偿还贷款并闭户。

准备普通场景

 这些场景描述了主要的交互、外部显示格式以及信息交换等。场景是指在一组交互对象之间发生的一系列事件。
 对于大多数非实时系统来说，逻辑上的正确性要取决于交互序列，而不是交互的确切时间。而对于实时系统而言，除了交互序列顺序外，交互完成的时间有时也是正确性的一部分。或者说，即使交互顺序正确而交互时间没有达到要求，系统仍然是错误的。交互时间的捕获可以通过附加在顺序图上的约束来实现。
 为普通情形（主线）准备场景，也即没有任何异常输入或者错误条件的交互。每当系统中对象和外部代理之间有信息交换的时候，就会发生事件，被交换的信息就是时间的参数。对于每个事件，应该确定发起事件的参与者以及事件的参数。

增加变化和异常场景

 在准备后普通场景之后就好考虑特例了。例如，省略掉的输入，最大、最小值以及重复值等。然后，要考虑错误情形，包括无效的输入，中途取消和没有响应等。最后，要考虑叠加在基本交互之上的其他不同类型的交互。例如，帮助请求和状态查询等。

寻找外部事件

 检查场景，寻找所有的外部事件，包括所有的输入、决策、中断以及与用户或外部设备之间的往来交互。事件可以触发目标对象产生动作。对于计算来说，要注意内部计算步骤不是事件，而与外部交互的计算才能作为事件。用场景来寻找普通事件，但不要忘记异常事件和错误条件。
 应该把对控制流有着相同效果但参数不同的事件归类到同一个事件名称下面。例如输入密码应该是一个事件，其参数是密码值。密码值的不同不会影响控制流。
 也要注意某些参数或量化值从量变到质变的情况。这时，必须确定量化值之间的差异何时会大到要区分不同的事件。例如，键盘上的不同数字键通常会被看成是相同的事件，因为计算控制对数值并没有依赖性。但是如果按下“Enter”键，可能会被看成不同的事件。

画顺序图

 为每一种场景都准备一张顺序图。顺序图显示了交互过程中的参与者和他们之间的消息序列。每种参与者都会在图中分配为对应的一列。这样，从顺序图中就可以总结出每个类接收和发送的事件。

组织参与者和用例

最后用关系（包含、扩展和泛化）来组织以上步骤得到的所有用例。

实例：PDA中一个模块的需求模型

 该模拟PDA的实现平台为UP-NetArm3000嵌入式系统开发实验平台。
 要求在嵌入式系统平台上实现通信录的录入、修改和查询功能。每项通信录条目包含姓名、固定电话号码、移动电话号码和电子信箱。录入时作为一个整体条目，在保存前可以修改；查询按姓名的字母顺序。要求可存储条目不少于100条，用英文方式实现。

1.确定系统边界

 此问题系统边界时清晰的，即PDA系统本身。

2.寻找参与者

 参与者就是使用PDA系统的人。但作为参与角色，可以是通讯录的录入者，或者通讯录的使用者。两者都可以参与修改通信录的操作。

3.寻找用例

 从系统提供的功能上，可以看出通信录的录入、修改和查询时系统外部可见的功能，因此可以确定3个对参与者有意义的用例，即通讯录录入、通讯录修改和通讯录查询。

4.寻找初始和终止事件

 通信录录入用例：通信录录入者在系统菜单中选择通信录录入选项开始这个用例；在通信录录入界面选择保存结束将这个用例。
 通讯录修改用例：通信录录入这在通信录查询界面在选择通信录修改选项开始这个用例；在通信录查询界面选择保存结束这个用例。或者，通讯录使用者在系统菜单中选择通信录查询选项开始这个用例；在通信录查询界面选择保存结束这个用例。
 通信录查询用例：通信录使用者在系统菜单中选择通信录查询选项开始这个用例；在通信录查询界面选择退出结束这个用例。

5.准备普通场景

6.增加变化和异常场景

7.寻找外部事件

 本例的外部事件全部来自于用户的按键，按键的类别为选择键、数据键和确认键。确认键和选择键属于命令键，是单间组合，其外部时间参数就是命令键的键值。数据键可以是数字键或字母键，为多键组合。或者说输入的实际内容从命令键开始，再遇到命令键结束。正常输入时，两次命令键之间的全部输入就是外部事件的参数。

8.画顺序图

9.组织参与者和用例

4.3 嵌入式系统结构分析

 一旦系统的外部环境确定，系统分析师就必须辨别出系统内部的关键对象和类以及他们之间的关系。现在还没有工具自动暗藏由外部功能描述到内部结构转换及功能分解，分析师必须人工处理这项工作。处理时要保证问题域中的核心概念被正确地集体化为类，并要确保这些类与领域中的其他概念之间存在合理的关系。

4.3.1 领域分析与问题陈述

 领域分析关注的重点是真实世界中传达应用语义的内容。领域对象所携带的有关真实世界对象的信息，一般都是被动的。对于嵌入式系统分析来说，领域分析一版要通过学习所涉及领域的专业书籍以及同领域专家交流来进行。领域分析的最终结果是要结合用户提出的需求，形成一个描述所开发问题的问题陈述文本，也可以建立一个领域类模型。
 问题陈述时由分析师根据在项目初期阶段的一系列活动，包括研究用户提出的需求，领域分析、与领域专家及最终用户讨论需求和形成的需求模型等，生成一个简短的且能够真实反映需求内容的文本。其目的时为下一阶段发现对象活动准备输入。
 如果在需求模型中的用例描述是采用文本说明的方法，也可以用对所有用例的行为顺序说明文档取代问题陈述来作为发现对象过程的输入。如果采用这种方式作为发现对象活动的输入，则总结问题陈述活动可以越过。

4.3.2 发现对象

 用例模型驱动对象模型。每个用例都通过一组在一起工作的对象来实现，在UML中称为协作。协作代表了一组对象，这些对象（通常是复合对象，在后期的活动中可进一步精化）具有特定的角色，在分析层级上以实现用例为目的。

 在非用例驱动的系统开发中往往会出现一下两种情况：1.开发人员想当然地在系统中添加了超出系统实际需要的特征。2.忽略了系统的一些特性。如果采用用例驱动的对象分析，就可以避免上述两种情况。
 一旦出创建了对象模型，系统级的用例就可以被提炼，再加以考虑标识过的对象及其关系。这样就允许检查对象模型是否满足在用例中指定的需求，并且说明了对象是如何通过协作来完成用例的。
 "找对象“(发现对象、标识对象）的问题是关系到所建设系统的终身大事的问题。不过这里的对象是一组而不是一个，其目标是通过协作实现用例。面向对象的分析没有魔法，只有靠不断地学习和总结才能提高找对象的技巧。
 在多年来面向对象的分析实践中，这个领域的许多大师和系统分析人员总结了大量的建立分析模型的方法，读者在使用这些方法进行分析时要注意，不要试图在任意一个项目上把他们都用到。

-1.陈述名词
 所谓陈述名词方法就是强调问题文本描述中的每一个名词和名词短语，并将其视为潜在的对象或对象的属性。

 实际中常见的做法是找出第一类中的对象。有时候，属性很明显地只是对象的特征。当存在疑问时，可以试着把名词划分到对象一类中。如果随后的分析发现这个名词不具有独立性，而是依赖于某些概念名词并反映该名词的某个方面，那他就是该对象的属性。

• 标识因果
  
  前两类对象称为因果对象。因果对象时能自动执行动作，协调构件对象的活动，或者生成事件的对象。很多因果对象最终成为了主动对象，并作为任务的根组成其他对象。

-标识服务设备
 嵌入式系统利用传感器和控制器与其周围环境交互。这些设备又连接到其他设备来完成系统控制或者监控空能。提供系统所用信息的设备通常建模为对象，并且必须被配置、校准、启用和控制，一边能够为系统系统服务。当必须维护设备信息和状态时，这些设备就应该建模为对象，以便维护与其操作相关的信息。
 被动对象没有因果对象那么明显。它们可以提供被动的控制服务、数据存储或者两者兼而有之。通常的开关（如继电器、可控硅等）就是一个被动的控制对象。它为因果对象提供了服务，但本身却没有发起动作。被动对象也成为服务器，因为它们为客户端对象提供服务。
 在嵌入式系统中常见的被动对数据对象由传感器、显示器、打印机等。嵌入式系统的任何模拟信息输入是经过传感器变换再经A/D转换器输入的。建模时不考虑硬件实施可以把它们看成是一个对象，称为传感器。硬件的被动服务者有时也可能是一个芯片、如FFT的校验等专用芯片。

• 标识真实世界的事物
   面向对象系统经常需要建模真实世界中对象的信息或行为，即使他们不属于系统本身的一部分。例如，各种抄表系统必须建模客户的相关特征，即使这些客户明显地位于系统之外，典型的客户对象属性一版会包含姓名、地址、联系方式、表号、上次使用量等。
   这种策略着眼于真实世界中与系统交互的事物，但并不是这些对象的所有侧立面都会被建模，而仅是对系统有意义的属性才会被建模。

• 标识关键概念
   关键概念是位于具有感兴趣的属性和行为的领域内部的重要抽象。这些抽象通常可能不是现实世界的物理存在。在图形用户界面领域内，窗口就是一个关键概念。在处理商业POST时，账户就是要给关键概念。在处理特定领域时，不要忽略了这类概念，通常他们在概念模型中是一个重要对象。

• 标识事物
   事物时必须持续一段有限的事件并代表其他对象之交互的存在。事物对象在通用计算系统中更为常见。如，存款、开户、注销、交易等。在先嵌入式系统中，如显示、报警、错误处理、任务调度、监护条件判别等是比较常见的处理事务。

• 标识持久信息
   持久信息通常在被动对象中，比如堆栈、队列、树或数据库等。不管是易变的内存介质，还是长期不变的存储介质，都可以存储持久信息。

• 标识可视化元素
   很多嵌入式系统直接或间接与人类用户交互，如手机、个人数字助理、数码相机等等。嵌入式系统的GUI由于嵌入式系统本身所特有的资源紧缺性和人机接口的多样性，通常照搬WIndows技术是不现实的。比如间的用一个发光二极管标识电源或系统运行状体，而复杂的可以像windwos窗口一样具有按钮、窗口、滚动条、图标和文本等显示对象。
   在嵌入式系统软件三层结构中，往往把人机显示划归到表示层。对于教简单的的显示系统，显示元素常常要作为系统对象，在系统分析和设计时统一考虑。但是按照软件逻辑清晰的原则，建议即使是简单的显示系统，在软件逻辑设计是任然要把显示功能和问题逻辑功能分开在两层。
  

• 标识控制元素
   控制元素是控制其他对象的实体，是因果对象的一种具体类型。他们可以是简单的对象或者是精致的控制系统，比如：PID控制环，模糊逻辑推理机、专家系统推理机、神经网络仿真等。另外，某些控制元素可能是允许用户输入名利的呢的物理接口设备，如按钮、开关、键盘等。

• 遍历用例
    用例场景的应用是另外一种发现对象的方法。它可以标识遗漏的对象，以及测试实现用例的对象协作。
   这一过程可以通过精化用例场景机械地完成。一旦我们标识并获得了写作中的对象组，单个的系统对象就可以用协作中的对象组替代。具有概念化内部结构的场景提供了一个更详尽或精华的视图，并能验证协作是否确实实现了用例。
  
  
  

4.3.3 标识关联

 在早期的分析阶段，某些对象看上去与其他对象有关，不过他们有咋样的关系总是不太清楚。首先是标识这样的关联的存在，然后考虑将这写关联特征化。
 同样也存在一些标识对象关联的策略。，每条消息都暗含了一个关联。

• 标识消息
• 标识消息源
• 标识消息存储着
• 标识消息处理程序
• 标识整体-部分结构
• 标识共同-具体抽象的结构
• 应用场景

1.标识消息

 每个消息都暗含了参与对象的一个关联。通过用例的产经或问题陈述发现绝大部分外部消息，协作对象之间的消息可以在后边的步骤中获得。

2.标识消息源

 探测信息或时间的传感器以及信息或事件的创建者都属于消息源。内部对象间的消息是对系统边界上的消息的分解和细化的处理过程。

3. 标识消息存储者

 消息存储者用于归档消息，或者为其他对象提供一个信息中央存储池。

4.标识信息处理程序

某些对象集中处理信息的调度和处理。他们组成了与消息源或消息存储中任意一个连接，胡总和两者兼而有之。

5. 标识整体-部分结构

 对象间的聚合关系。整体通常发送消息给它的部分。

6.标识共同-具体抽象的结构

 某些对象通过抽象级别的差异来相互联系。例如，单个的高级抽象由一些更具体的对象的共同特征提取而得到。

7.应用场景

 利用已标识的对象遍历所有场景，这些场景清楚地署名了如何在对象间发送消息。
 上诉的集中方法也不是完全正交的，有时通过两或三个方法就可以找到所有的关系。
 把找到的每一条消息都表示为关联的两个对象之间的一个关联。在逻辑上，关联是双向的，除非附加的导航装饰明确地限制了其方向性。
 通信的面向对象抽象就是以关联作为管道来发送西澳西的。有很多中实现这种管道的方法，如OS句柄，RTOS消息发送、RPC以及通过总线或者网络传递消息等。不过在嵌入式系统中，关联以简单指针或者对象引用的方式来实现则更为常见。
 当关联仅在一个方向能够导航时，通常成为客户-服务器模式关联。客户是常有引用的对象；服务器则带有数据或者由用户激活的操作。

4.3.4 标识对象属性

 属性是被命名的类的特征，它描述了该特性的实例（即对象）可以取值的范围。属性虽然也是名词性，但它的作用是描述或说明其他实体的，而不是本身独立存在的。属性是反映对象结构特征的，是对象的数据部分你。如传感器对象可能包括校准常量和测量值这样的属性。属性几乎总是基本的，不能再分为子属性。如果分析时发现所假定的属性不是基本的，那么应该将其建模为主对象所关联的对象，而不是主对象的属性。例如，如果传感器有一个简单的刻度校准常量，那么就将其建模为传感器对象的一个属性。然后，如果传感器对象具有一套完整的校准常量，那么最好将每个校准常量都建模为由带“1-*”多重性的传感器对象单向集合的对象。对于传感器的非基本属性图4.18（a)建议建模为4.18（b)。在实现这一组常量可以由一个容器类管理。该过程可以在分析阶段进行（如果系统足够小）,也可以在设计细化阶段进行(如果系统足够复杂）.需要说明的是，用这种建模容器并不必然给性能或内存利用率带来额外的开销，反而提供了更好的封装性和使系统更容易维护。

 在建模中，有时可能存在无属性的对象。无属性的对象在面向对象建模中仍然是有效的对象。例如，一个按钮是一个合理的对象，如果不是考虑安放位置或系统外观，他的大小，颜色对软件系统建模来说没有任何意义，只有开和关的操作行为才是需要关心的。在UML中没有属性的对象称为接口。

4.3.5 建立系统的类模型

 在前面标识对象的一系列活动中，所描述的对象协作都是围绕着实现用例为目的的。他们所描述的对象有很多在结构上是相同或重复的。另外，在围绕着实现不同的用例而确定的相互协作的对象也会存在交叉。或者说，为两个用例实现而定义的协作中的对象，站在系统的视角观察根本就是同一个对象。这样，就需要从系统的整体视角来整合所有对象，通过系统统一的类图来实现所有用例所提出的功能要求。这些整合包括提炼所有共同的对象为类，合并交叉的对象为类，泛化具有共同特征的类等。这是一个由特殊到一般的过程。抽象出所有的类后，再从关系的视角合并对象之间的关系为类之间的关系，最后得到系统分析的类模型。
 在系统分的类模型中，主要设计概念类和应用类两种结构型类。概念类主要是确定应用领域中的概念，一般要在领域分析或对应用领域的专业知识的理解中获得。在嵌入式系统中，领域概念通常会融合在需求文档中的形式提供给分析人员。这些类的获得通过"陈述名词“应用类界定了应用程序本身，而不是由应用程序操作的真实世界对象。多数应用类都是面向计算机的，他们定义了用户感知应用程序的方式。

1.发现类

 类是对象的抽象。类模型描述了应用程序的类以及他们之间的相互关系。反映协作的对象图只是类图在程序运行中的一个快照。在一个应用系统中，类图是稳定的，是系统软件框架的核心部分。而协作和对象图则是系统运行在某一个特定瞬间的一种软件结构和关系。因此，只有获得类图，才能在更为稳定的框架下和更为系统的视角里全面地描述系统。

2.定义类关系

 对象间关联的存在意味着其中一个对象或者两者都向对方发送消息。关联是指结构上的，也就是说它必须是类的一部分，或者说关联本身也是一种类元。除非由明确的限制，通常关联在逻辑上都是双向的。在分析模型中，可以不去计较关联的实现到底是单向的还是双向的，这个细节问题可以留到设计模型中去解决。
 聚合是一种特殊类型的关联，它表现的是整体-部分关系。聚合也是关联的一种情况。聚集表示了这这样一种思想：聚集是它的每一部分的总和。例如，个人计算机系统是一个聚集体，它由主机箱、键盘、鼠标、显示器、调制解调器、打印机等组成，还可能包括几个音箱。

 组合是一种强类型的聚合。组成类必须创建并销毁它的构件。

 泛化是父类与子类的分类关系。分类层次结构中较高级别的类有时称作父类、泛化类、基类或者是超级类。从基类继承了属性和操作的类称为子类、特化类或者派生类。图4.21中的按钮自来就是沿着行为特性特化而来的。简单按钮在被按下时发出事件消息，但是他们没有状态记忆。触发按钮根据连续的按钮操作在两个状态之间切换。多状态按钮根据各个按键组合通过一个状态机运行。组按钮在被按下时，删除组内所有其他按钮。

 继承意味着几乎时对于所有的类，只要有一个子类成立，那么它所有的子类都是成立的。子类可随意用来特化和扩展继承来的特征。特化时指子类可以多态地重新定义一个操作，使之在语义上更适合自己。扩展时子类可以添加心得属性、操作、关联等。
 可替代性是值子类的实例对于超类的实例总是可以替代的，并且不需要破坏模型的语义。这杯称为Liskov替代准则LSP.例如狗是动物，所有动物的属性狗也有。所有动物的行为，狗也有。
 依赖关系是标识一个或几个模型中两个元素间关系的语句。依赖意味着一个模型元素以某种方式使用另一个模型元素。一下步骤是对已经确立的类模型进一步完善的过程，从中可能会发现遗漏的类和进一步优化类图结构

3.确定用户界面

 图4.14多数交互都可以划分为两个部分:应用逻辑和用户界面。用户几面在系统的表示层，是以一致的方式给用户提供访问系统的对象、命令和应用选项的一个或一组对象。分析阶段的重点时信息流和控制，而不是表示格式。如果表层细节被仔细隔离开来的化，就可以使用形同的结构逻辑从通信线路、文件、按钮、触摸屏、按键或者远程链路等出接收输入。
 在分析阶段，在细节层次上要以粗略的粒度处理用户界面。不要担心如何输入独立的数据，相反要尽量确定用户可以执行的命令。命令是对服务的一种大规模的请求。例如”航班预定“和”在存储库中寻找匹配的条目"等都是命令。输入命令信息和调用命令的格式相对而言都易于改变，因此要首先定义命令。
 对于较复杂的嵌入式系统用户界面，例如，具有较大平面液晶显示的PDA系统，要先草拟出一种示例界面，有助于将应用程序操作可视化。在这张方式中，很容易发觉是不是什么重要的内容被遗漏掉了。若有体检，也可以把界面伪装起来而用哑过程来模拟应用逻辑，让用户来试用。将应用逻辑从用户界面去耦，既可以检验应用逻辑框架的正确性和合理性，也可以在应用模块具体开发者提供一个稳定的上下文。

4.定义边界类

 系统必须能够操作和接收来自外部资源的信息，但系统的内部结构不应受制于外部信息。定义边界类，将系统内部与外界隔离开来，时处理这类问题的可取方法。

5.确定控制器

 控制器是一种管理应用程序内部控制权的主动对象。它接收外界或系统内部对象的信号，响应他们，调用对象是的操作，以及给外界发送信号。控制器是以对象的形式捕获的一段具体化的行为，这种行为要比普通代码更容易操作和转换。多数应用的核心都是一项或多项控制器，由它们来组织应用程序的行为序列。在多任务系统中，控制器类表现为一个系统任务，在类模型中表现为主动类。
 在设计控制器的行为过程中，多数工作是建模状态图，具体活动在4.4.3小节介绍。然而，在这里主要是捕获系统中的控制器、每一种控制器所维护的控制信息以及控制器到系统中其他对象的关联等这类反映结构内容的信息。

6.检查用例模型

 回顾用例，并思考他么是如何工作的。

4.3.6 创建类图的讨论

 事实上，系统的前期分析目标都是朝着系统框架方向进行的。为了得到分析框架、可以用不同的路径，但分析的目标是正确的，那就是得到分析框架（或分析模型）.

 建模的任务是记述重要的系统抽象并且确定这些抽象的语义。建模当然包括定义再抽象上的属性和操作，这些属性和操作通常会在类途中描述出来。不过，也包括各个抽象再各种协作和抽象的状态空间中所扮演的角色。还可能存在一些附加的约束和重要的细节，包括抽象的职责、抽象要满足的需求以及生成的源代码。再分析阶段，核心问题是获得系统软件框架。实际上，通常不能仅仅通过手边的类模型视图来理解一个系统，还需要附加交互模型和状态模型才能全面、具体地理解整个系统。
 一下技巧有助于构建应用中的类模型，这里统一做个总结。

• 范围
  模型仅需要表示与问题相关的内容。确定哪些对象和属性，而忽略哪些对象和属性

• 简洁性
   努力保证模型的简介。使用定义清晰且没有冗余的类，尽量保证类的数目最少。

• 图的布局

• 类名的选择
   有非常强的描述和注释作用
  -引用
   不要将对象引用作为属性在对象里使用。相反，要把他们建模为关联。

• 多重性

• 关联的终端名

• 包和序列

• 关联的属性
   分析过程中，不要将关联的属性折叠进某个相关的类中

• 限定关联

• 泛化的层次

• 评审

4.4 嵌入式系统行为分析

4.4.1 对象行为

 行为被细分为活动、交互和状态机三种类型。对象的行为描述了它们随着时间的流逝，其属性和关系的变化，并以此而满足它们在系统中的职责。换句话说，行为描述了对象（类元）通过响应外部事件和内部计算而使其状态时如何改变的。对象的行为可以从单个对象的上下文角度考察，也可以从对象间协作这个更大一点的上下文角度考察。可以有不同方法规定对象的全部行为，其中最重要的方法就是把对象行为建模为有限状态机。而交互模型可以帮助测试状态行为模型，以确保对象 能够相互合作共同履行系统的职责。当确立了软件框架中的状态模型和交互模型后，就可以从状态模型和交互模型中得到类操作的定义。最终，类的操作实现了它的行为。在面向对象的分析和设计活动中，状态模型所适用的主题往往时很明确的，用UML的话来说，这种主题通常是一个类元，一般会是一个类，不过也可以时其他类型的类元，比如说用例，甚至也可以是一个协作。
 行为指的是事物变化的方式。对象的行为是通过类操作集合以及应用类操作时的约束来定义的。在计算系统在，所有对象的行为都是有一定约束的。功能性约束将操作的使用限制在一个定义良好的序列中，在这样的序列中满足前置/后置条件不变式。功能性约束通常使用有限状态机来建模。此外常常存在其他非功能性约束。这些约束被认为是服务质量（Qos)约束，他给出了行为完成的质量。例如，一个动作应该花多长事件？或者一项计算呢精度。在实时嵌入式系统分析中，对对象行为给出规约时必须同时兼顾功能和Qos两个方面。Qos约束通常采用一种约束语言来建模。常见的约束语言有结构化英语、数学语言、时态逻辑以及OCL。

4.4.2 状态行为

1.状态

 如果一个对象的行为能够用一张状态图来捕获、描述，那么就称这个对象时反应式的。这类对象的行为空间被划分为不连续的、不重合的存在条件，这些条件称为状态。状态是能够持续一定时间阶段的基本条件，他可以与其他类条件区分开来，并且各个条件之间是不连续的。一个可区别的状态意味着从观察的角度看，它在所接收的事件或作为接收事件响应的结果所采取的转换方面会有所不同。用最简单的话来说，状态时对象是的一个条件，在该条件存在期间，对象接收一组事件，并执行某些动作和活动，基于所接收到的事件，对象可以转换到其他状态集合。一个状态与其他状态的区别主要体现在如下方面

• 所接收的输入事件
• 作为输入时间的结果，对象所采取的输出转换以及当转换实施以后，对象可以达到的后续状态的可达图
• 针对进入状态所执行的动作
• 针对退出状态所执行的动作
• 所执行的活动
   如果两个状态在任何一个方面有所不同，那么它们就是两个不同的存在状态。
   一个对象的状态可以分解成子状态，就是说，状态是可以嵌套的。例如，传感器的状态空间在较高层次上可以分解为{关闭，开启}两个状态的集合而开启状态还可以进一步分解成{等待命令，采样，转换，校准，提交结果}等子状态。外层状态被称为超状态或复合状态，内存状态称为子状态。UML对超状态的分解可以有或状态和与状态两种方式。或状态是指超状态中的所有子状态具有“或”的关系，与状态也称为正交区，指的是超状态中所有子状态具有“与”的关系，在任何时候如果对象处于某个超状态，那它必须同事处于其所有子状态之中。与状态反映了超状态内部的并发行为。

2.事件、转换、动作和活动

 转换由事件引发，UML定义了四种事件，即:信号事件、调用事件、改变世家和时间时间。

(1)转换

 用于表示一个状态机中两个状态之间的一种关系，即一个某初始状态的对象通过执行指定的动作而进入第二种状态。这种转换需要某种指定的事件发生和指定的和监护条件得到满足

(2）动作和活动

 动作是一个可执行的原子计算，不能被事件中断，并且一直运行到完成。而活动则不同，它可以被其他事件中断，是对象处于某个状态期间所执行的行为。
 动作可以退出一个状态、执行一个转换和进入一个状态时执行，分别称为退出动作、转换动作和进入动作。表达式中任何动作的出现的地方也可以是一个动作序列，其中包含任意长度的动作列表。

3.为状态

 伪装态是状态集中具有状态的形式而其行为却不同于完全状态的顶点。为状态用来连接转换段，通常到一个伪装态的转换意味着会有一个到另一个状态的自动转换而不需要事件触发。

4.4.3 建立状态模型

 首先，用多个状态来确定应用类的行为，并使用交互模型来寻找这些类的事件；然后用状态图为类组织允许的事件序列；接下来，检查不同的状态图，确保公共事件的匹配；最后，用类模型和交互模型检查状态图。

1.使用状态来确定应用类

 事实上，并不是所有的类都需要附加一个状态模型描述。思考每一个应用类，并确定哪些应用类由多个状态。用户界面类和控制器类是状态模型很好的候选对象。边界类、容器类往往是静态的。

2.寻找事件

 对于应用交互模型，已经获得了大量的场景。现在要研究这些场景，并提取事件。

3.构建状态图

 选择其中一个类，并考虑顺序图。把这个类相关的事件组织成一条路径，路径弧用事件标识。任意两个事件之间的间隔就是一种状态。每种场景或顺序图对应状态图的一条路径。
 当初始状态图建立后，就要寻找图中的环路。如果事件序列可以重复无限次，那么它们就形成了环路。在环路中，第一个状态和最后一个状态时相同的。
 y一旦发现由环路存在，就要把其他顺序图合并到状态图中。寻找每张顺序图中自前一张图的分叉点。许多情况下，从对应用程序的了解中，很容易看出两条分离的路径中的哪两个状态时相同的。例如在自动售货机上插入两个五分硬币和插入一个一角硬币应该时同一个状态内的活动。
 要注意看上去等同但在某些情形下有差别的两条路径。例如PDA在校验口令时，用呼输入错误信息时，会重复输入序列，但在失败一定次数之后会进入适当处理。这种差异可以通过引入一个参数来处理，例如记忆错误的次数。
 在考虑完普通事件之后，要增加变体和异常情况。要想干脆利落地处理用户错误，通常需要比普通情形更多的思考和编码。
 如果对象与独立的输入有着复杂的交互，就可以考虑使用嵌套的状态图。但是在嵌入式系统实际开发中，一般平面状态图就足够了。

4.检查其他状态图

 检查每一个具有状态图的类，这里主要检查状态图的完整性和一致性。每一个事件都应该有一个发送者和一个接收者，偶尔它们也可能是同一个对象。没有前驱和后继的状态时可疑的的，遇到这样的状态要回到步骤3把它结合到状态图或丢弃。由于对象具有内在的并发性，要注意在难以处理时候发生输入所引发的同步错误，确保在不同状态图上对应的事件具有一致性。

5.检查类模型和交互模型

 当状态模型本身的检查完成后，接下来就要检查状态模型与框架内其他模型的一致性问题。首先，要检查状态模型与类模型的一致性问题，方法时检验其一个外部事件是否有类去最终处理它。
 然后，返回来检查交互模型的场景，方法时手工模拟每一个行为序列，并验证状态图是否标识除了正确的行为。如果发现错误，要么改变状态图，要不改变场景。不要假定场景永远都是正确的。

4.建立交互模型

 如果说软件框架时一个三脚架的话，那么交互模型就是类模型和状态模型之外的第三条支架。类模型描述系统中的对象（类）及其关系，状态模型描述对象的生存周期，交互模型描述对象之间如何通过交互来完成所讨论问题边界之外可见的功能。
 交互模型跨越了所关心的问题，描述了从问题外部的整体行为到其内部协作对象之间的交互行为。而状态模型仅是针对某一个对象并用适当简化的原则来描述它的生命全景。所有对象的状态图的集合就是状态模型。交互模型可以包括顺序图和通信图，但通常应用最多的是顺序图。
 交互模型可以在不同的抽象层次上建模。在较高层次上，交互模型表现为描述用例，也就是描述系统如何与外部参与者交互。
 进一步深入到系统内部，表现为通过系统内部元素的协作完成外部可见的功能，顺序图提供了更多的细节，并显示一组对象随着时间变化多交换的消息。消息包括异步消息和过程调用。
 创建顺序模型的准则如下

• 为每一个参与交互的对象分配一列
• 至少为每一个用例创建一个顺序图
   顺序图中的步骤应该是逻辑命令，而不是单一次的按钮点击。接下来，在设计过程中就可以确定每一个逻辑命令的确切的语法。
• 区分主动对象与被动对象
   主动对象具有自己的控制线程，如果有操作系统，通常表现为操作系统的任务，在类图中表现为主动类。主动对象总是互动的。
• 为每一个主线交互创建一个顺序图。
• 划分复杂的交互
• 增加错误或异常条件
• 过程化顺序模型
  

4.4.5 增加类的主要操作

 与传统的基于程序设计的方法不同，面向对象的分析风格在分析阶段较少地关注操作的定义。在分析到设计的过程中，具有潜在用途的操作清单是开放的，这些操作的增加时随时进行的。操作来源于类模型和标识用例的交互两个方面。
 来自类模型的操作。对于属性值和关联链接的读写时隐含在类模型中的。在分析阶段并不需要将它们显示地标识出来。这里假定属性和关联都可以访问的就可以。
 来自用例交互的操作。大多数复杂的系统功能都来自于系统的用例。在构造交互模型的过程中，用例会引发活动。许多活动与类模型上的操作相对应。例如，在交互模型中，有一个指向某个对象的调用事件，说明该对象是有一个对应该调用的操作或服务。
 检查类模型，寻找形式上与某项操作相似的操作和变体。要设法拓宽操作的定义，以包含此种变体和特里。要尽可能多地使用继承来减少相异操作的数量。将每一项操作定义在类层次结构内的正确层次上。这种细化的结果时形成更少量和更强大的操作，但他们描述起来又会比原始操作更简单，因为他们更加统一且通用。
 所有操作不是亲自处理消息，就是帮助别的操作处理消息。这意味着一旦定义了某个类的状态机，就阐明了重要的场景，这些图上显示的消息和事件就成了类的操作。操作时对象行为的表象。这种行为通常指定在状态图和场景图上。
 在UML中，操作时行为的规格说明而不是行为的具体实现。而方法才是操作（行为）的具体实现。
 为了使不同阶段的开发人员对操作有一个共同理解并且能够正确使用这些操作，需要用一个操作说明协议。其协议组成如下：

 保证前置条件不变量的职责基本上是客户端实现的。然后，服务器操作应该尽可能多地检查这些不变量。
 为类接口定义一组好的操作可能很困难。有可能方法可用来帮助如何确定这些操作。