|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
9.3.1节从用户的观点对系统进行了用例建模，但获得了用例并不意味着分析的结束，还要对需求进行深入研究，获取关于问题域本质内容的分析模型。分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信实现系统行为（动态模型）。
|
|
|
|
为了使模型独立于具体的开发语言，需要把注意力集中在概念性问题上而不是软件技术问题上，这些技术的起始点就是领域模型。领域模型又称为概念模型或域模型，也就是找到代表那些事物与概念的对象，即概念类。概念类可以从用例模型中获得灵感，经过完善将形成分析模型中的分析类。在迭代开发过程中，每一个用例对应一个类图，描述参与这个用例实现的所有概念类，用例的实现主要通过交互图来表示。
|
|
|
|
|
|
（1）发现领域对象，定义概念类。发现类的方法有很多种，其中最广泛应用的莫过于“名词动词法”。它的主要规则是从名词与名词短语中提取对象与属性；从动词与动词短语中提取操作与关联；而所有格短语通常表明名词应该是属性而不是对象。
|
|
|
|
（2）识别对象的属性。属性是描述对象静态特征的一个数据项。可以与用户进行交谈，提出问题来帮助寻找对象的属性。属性是概念类所拥有的特性，从概念建模的角度看，属性越简单越好，要保持属性的简单性，应该做到4个方面：仅定义与系统责任和系统目标有关的属性；使用简单数据类型来定义属性；不使用可由其他属性导出的属性（冗余属性）；不为对象关联定义属性。最后，要对属性加以说明，包括名称和解释、数据类型，以及其他的一些要求。
|
|
|
|
（3）识别对象的关系，包括建立类的泛化关系、对象的关联关系。理清类之间的层次关系，决定类之间的关系类型，确定关系的多重性和角色的导向性。多重性指定所在类可以实例化的对象数量（重数），即该类的多少个对象在一段特定的时间内可以与另一个类的一个对象相关联；导向性表示可以通过关联从源类导向到目标类，也就是说给定关联一端的对象就能够容易并直接地得到另一端的对象。
|
|
|
|
（4）为类添加职责。找到了反映问题域本质的主要概念类，而且还理清它们之间的协作关系之后，我们就可以为这些类添加其相应的职责。类的职责包括两个主要内容，分别是类所维护的知识、类能够执行的行为。可以使用状态图来描述系统中单个对象的行为。
|
|
|
|
（5）建立交互图。多个对象的行为通常采用对象交互来表示，UML 2.0提供的交互图有顺序图、交互概览图、通信图和定时图。每种图出于不同视点对行为有不同的表现能力，其中最常用的是顺序图，几乎可以用在任何系统的场合。顺序图的基本元素有对象、参与者、生命线、激活框、消息和消息路线，其中消息是顺序图的灵魂。
|
|
|
|
：在整个开发的过程中，分析模型是不断演变的，最初的分析模型主要是围绕着领域知识进行的，对现实的事物进行建模。而后，则不断地加入设计的元素，演变成为运行于计算机上的架构和结构。其演变过程中最主要的变化体现在以下3个方面：
|
|
|
|
（1）根据鲁棒分析和交互分析的结果，补充类的属性和操作，不断地细化其内容，更细致地刻化类之间的关联关系，以便体现代码的核心。
|
|
|
|
（2）添加许多与计算机实现相关的技术类，以体现系统的实现结构。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
序列图、通信图、交互概览图和计时图均被称为交互图，它们用于对系统的动态方面进行建模。一张交互图显示的是一个交互，由一组对象和它们之间的关系组成。包含它们之间可能传递的消息。序列图是强调消息时间顺序的交互图；通信图则是强调接收和发送消息的对象的结构组织的交互图。
|
|
|
|
交互图用于对一个系统的动态方面建模。在多数情况下，它包括对类、接口、构件和节点的具体的或原型化的实例以及它们之间传递的消息进行建模，所有这些都位于一个表达行为的脚本的语境中。交互图可以单独使用，来可视化、详述、构造和文档化一个特定的对象群体的动态方面，也可以用来对一个用例的特定的控制流进行建模。
|
|
|
|
|
|
|
|
序列图（sequence diagram）是场景（scenario）的图形化表示，描述了以时间顺序组织的对象之间的交互活动。如下图所示，形成序列图时，首先把参加交互的对象放在图的上方，沿X轴方向排列。通常把发起交互的对象放在左边，较下级对象依次放在右边。然后，把这些对象发送和接收的消息沿Y轴方向按时间顺序从上到下放置。这样，就提供了控制流随时间推移的清晰的可视化轨迹。
|
|
|
|
|
|
|
|
|
|
序列图有对象生命线。对象生命线是一条垂直的虚线，表示一个对象在一段时间内存在。在交互图中出现的大多数对象存在于整个交互过程中，所以，这些对象全都排列在图的顶部，其生命线从图的顶部画到图的底部。但对象也可以在交互过程中创建，它们的生命线从接收到构造型为create的消息时开始。对象也可以在交互过程中撤销，它们的生命线在接收到构造型为destroy的消息时结束（并且给出一个大X的标记表明生命的结束）。
|
|
|
|
序列图有控制焦点。控制焦点是一个瘦高的矩形，表示一个对象执行一个动作所经历的时间段，既可以是直接执行，也可以是通过下级过程执行。矩形的顶部表示动作的开始，底部表示动作的结束（可以由一个返回消息来标记）。还可以通过将另一个控制焦点放在它的父控制焦点的右边来显示（由循环、自身操作调用或从另一个对象的回调所引起的）控制焦点的嵌套（其嵌套深度可以任意）。如果想特别精确地表示控制焦点在哪里，也可以在对象的方法被实际执行（并且控制还没传给另一个对象）期间，将那段矩形区域阴影化。
|
|
|
|
|
|
通信图（communication diagram）强调收发消息的对象的结构组织，在早期的版本中也被称作协作图。通信图强调参加交互的对象的组织。产生一张通信图，首先要将参加交互的对象作为图的顶点。然后，把连接这些对象的链表示为图的弧。最后，用对象发送和接收的消息来修饰这些链。这就提供了在协作对象的结构组织的语境中观察控制流的一个清晰的可视化轨迹。
|
|
|
|
|
|
通信图有路径。为了指出一个对象如何与另一个对象链接，你可以在链的末端附上一个路径构造型（如构造型local，表示指定对象对发送者而言是局部的）。通常只需要显式地表示以下几种链的路径：local（局部）、parameter（参数）、global（全局），以及self（自身），但不必表示association（关联）。
|
|
|
|
通信图有顺序号。为表示消息的时间顺序，可以给消息加一个数字前缀（从1号消息开始），在控制流中，每个新消息的顺序号单调增加（如2、3等）。为了显示嵌套，可使用带小数点的号码（1表示第一个消息；1.1表示嵌套在消息1中的第一个消息；1.2表示嵌套在消息1中的第二个消息；等等）。嵌套可为任意深度。还要注意的是，沿同一个链，可以显示许多消息（可能发自不同的方向），并且每个消息都有唯一的一个顺序号。
|
|
|
|
|
|
交互概览图是UML 2.0新增的交互图之一，它描述交互（特别是关注控制流），但是抽象掉了消息和生命线。它使用活动图的表示法。纯粹的交互概览图中所有的活动都是交互发生。另一种新增的、特别适合实时和嵌入式系统建模的交互图称为计时图，计时图关注沿着线性时间轴、生命线内部和生命线之间的条件改变。它描述对象状态随着时间改变的情况，很像示波器，适合分析周期和非周期性任务。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
结构化设计方法中使用结构图来描述系统的体系结构，指出一个系统由哪些模块组成，以及模块之间的调用关系。结构图的基本成分有：模块、调用和数据。
|
|
|
|
|
|
在结构化设计中，模块指具有一定功能并可以用模块名调用的一组程序语句，如函数、子程序等，它们是组成程序的基本单元。
|
|
|
|
一个模块具有外部特征和内部特征。模块的外部特征包括：模块的接口（模块名、输入／输出参数、返回值等）和模块功能。模块的内部特征包括：模块的内部数据和完成其功能的程序代码。
|
|
|
|
在结构图中，模块用矩形表示，并用名字标识该模块，名字应体现该模块的功能。
|
|
|
|
|
|
结构图中模块之间的调用关系用从一个模块指向另一个模块的箭头来表示，其含义是前者调用了后者。
|
|
|
|
|
|
模块间还经常用带注释的短箭头表示模块调用过程中来回传递的信息。箭头尾部带空心圆的表示传递的是数据，带实心圆的表示传递的是控制信息，如下图所示。
|
|
|
|
|
|
|
|
可以在结构图上添加一些辅助符号进一步描述模块间的调用关系。如果一个模块是否调用一个从属模块决定于调用模块内部的判断条件，则该调用模块间的判断调用采用菱形符号表示；如果一个模块通过其内部循环的功能来循环调用一个或多个从属模块，则该调用称为循环调用，用弧形箭头表示。判断调用和循环调用的表示方法如下图所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
类图（class diagram）展现了一组对象、接口、协作和它们之间的关系。在面向对象系统的建模中所建立的最常见的图就是类图。类图给出系统的静态设计视图。包含主动类的类图给出了系统的静态进程视图。
|
|
|
|
类图中通常包括下述内容：类；接口；协作；依赖、泛化和关联关系，如下图所示。
|
|
|
|
|
|
|
|
类图中也可以包含注解和约束。类图还可以含有包或子系统，二者都用于把模型元素聚集成更大的组块。
|
|
|
|
类图用于对系统的静态设计视图建模。这种视图主要支持系统的功能需求，即系统要提供给最终用户的服务。当对系统的静态设计视图建模时，通常以下述三种方式之一使用类图。
|
|
|
|
|
|
对系统的词汇建模涉及做出这样的决定：哪些抽象是考虑中的系统的一部分，哪些抽象处于系统边界之外。用类图详细描述这些抽象和它们的职责。
|
|
|
|
|
|
协作是一些共同工作的类、接口和其他元素的群体，该群体提供的一些合作行为强于所有这些元素的行为之和。例如当对分布式系统的事务语义建模时，不能仅仅盯着一个单独的类来推断要发生什么，而要有相互协作的一组类来实现这些语义。用类图对这组类以及它们之间的关系进行可视化和详述。
|
|
|
|
|
|
将模式看作为数据库的概念设计的蓝图。在很多领域中，要在关系数据库或面向对象数据库中存储永久信息。可以用类图对这些数据库的模式建模。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
随着嵌入式技术的发展，特别是在后PC时代，嵌入式软件系统得到了极大的丰富和发展，形成了一个完整的软件体系。如下图所示，这个体系自底向上由3部分组成，分别是嵌入式操作系统、支撑软件和应用软件。
|
|
|
|
|
|
|
|
嵌入式操作系统（Embedded Operating System, EOS）由操作系统内核、应用程序接口、设备驱动程序接口等几部分组成。嵌入式操作一般采用微内核结构。操作系统只负责进程的调度、进程间的通信、内存分配及异常与中断管理最基本的任务，其他大部分的功能则由支撑软件完成。
|
|
|
|
嵌入式系统中的支撑软件由窗口系统、网络系统、数据库管理系统及Java虚拟机等几部分组成。对于嵌入式系统来讲，软件的开发环境大部分在通用台式计算机和工作站上运行，但从逻辑上讲，它仍然被认为是嵌入式系统支撑软件的一部分。支撑软件一般用于一些浅度嵌入的系统中，如智能手机、个人数字助理等。
|
|
|
|
嵌入式系统中的应用软件是系统整体功能的集中体现。系统的能力总是通过应用软件表现出来的。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
RPR的体系结构如下图所示。RPR采用了双环结构，由内层的环1和外层的环0组成，每个环都是单方向传送。相邻工作站之间的跨距包含传送方向相反的两条链路。RPR支持多达255个工作站，最大环周长为2000km。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
用例是一种描述系统需求的方法。用例图（use case diagram）展现了一组用例、参与者（Actor）以及它们之间的关系。
|
|
|
|
用例图中通常包含三种元素：用例、参与者、用例之间的关系，如下图所示。
|
|
|
|
|
|
|
|
参与者是指存在于系统外部并与系统进行交互的任何事物，既可以是使用系统的用户，也可以是其他外部系统和设备等外部实体。
|
|
|
|
用例是描述系统的一项功能的一组动作序列，这样的动作序列表示参与者与系统间的交互。
|
|
|
|
用例之间通常存在三种关系：包含（include）、扩展（extend）和泛化（generalization）。
|
|
|
|
（1）包含关系。当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。其中被提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例。当多个用例需要使用同一段事件流时，抽象成为公共用例，可以避免在多个用例中重复地描述这段事件流，也可以防止这段事件流在不同用例中的描述出现不一致。当需要修改这段公共的需求时，也只要修改一个用例，避免同时修改多个用例而产生的不一致和重复性工作。另外，当某个用例的事件流过于复杂时，为了简化用例的描述，也可以将某一段事件流抽象成为一个被包含的用例。
|
|
|
|
（2）扩展关系。如果一个用例明显地混合了两种或两种以上的场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例。
|
|
|
|
（3）泛化关系。当多个用例共同拥有一种类似的结构和行为时，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。
|
|
|
|
用例图用于对系统的静态用例视图进行建模。这个视图主要支持系统的行为，即该系统在它的周边环境的语境中所提供的外部可见服务。
|
|
|
|
当对系统的静态用例视图建模时，可以用下列两种方式来使用用例图：
|
|
|
|
|
|
对一个系统的语境进行建模，包括围绕整个系统画一条线，并声明有哪些参与者位于系统之外并与系统进行交互。在这里，用例图说明了参与者以及它们所扮演的角色的含义。
|
|
|
|
|
|
对一个系统的需求进行建模，包括说明这个系统应该做什么（从系统外部的一个视点出发），而不考虑系统应该怎样做。在这里，用例图说明了系统想要的行为。通过这种方式，用例图使我们能够把整个系统看作一个黑盒子。你可以观察到系统外部有什么，系统怎样与哪些外部事物相互作用，但却看不到系统内部是如何工作的。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
状态图（statechart diagram）展现了一个状态机，它由状态、转换、事件和活动组成。状态图关注系统的动态视图，它对于接口、类和协作的行为建模尤为重要，它强调对象行为的事件顺序。状态图通常包括：简单状态和组合状态、转换（事件和动作）。如下图所示。
|
|
|
|
|
|
|
|
可以用状态图对系统的动态方面建模。这些动态方面可以包括出现在系统体系结构的任何视图中的任何一种对象的按事件排序的行为，这些对象包括类（各主动类）、接口、构件和节点。当对系统、类或用例的动态方面建模时，通常是对反应型对象建模。一个反应型或事件驱动的对象是这样一个对象，其行为通常是由对来自语境外部的事件做出反应来刻画的。反应型对象在接收到一个事件之前通常处于空闲状态。当它接收到一个事件时，它的反应常常依赖于以前的事件。在这个对象对事件做出反应后，它就又变成闲状态，等待下一个事件。对于这种对象，将着眼于对象的稳定状态、能够触发从状态到状态的转换的事件，以及当每个状态改变时所发生的动作。
|
|
|
|
|
|
|
|
|
|
|
|
|
