|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
活动图（activity diagram）是一种特殊的状态图，它展现了在系统内从一个活动到另一个活动的流程。活动图专注于系统的动态视图。它对于系统的功能建模特别重要，并强调对象间的控制流程。
|
|
|
|
|
|
用活动图建模的控制流中，会发生一些事情。你可能要对一个设置属性值或返回一些值的表达式求值。你也可能要调用对象上的操作，发送一个消息给对象，甚至创建或销毁对象，这些可执行的原子计算被称作动作状态，因为它们是该系统的状态，每个原子计算都代表一个动作的执行。动作状态不能被分解。动作状态是原子的，也就是说事件可以发生，但动作状态的工作不能被中断。最后，动作状态的工作所占用的执行时间一般被看作是可忽略的。
|
|
|
|
活动状态能够进一步被分解，它们的活动由其他的活动图表示。活动状态不是原子的，它们可以被中断。并且，一般来说，还要考虑到它需要花费一段时间来完成。可以把一个动作状态看作一个活动状态的特例。类似地，可以把一个活动状态看作一个组合，它的控制流由其他的活动状态和动作状态组成。
|
|
|
|
|
|
当对一个系统的动态方面建模时，通常有两种使用活动图的方式：
|
|
|
|
（1）对工作流建模。此时所关注的是与系统进行协作的参与者所观察到的活动。工作流常常位于软件系统的边缘，用于可视化、详述、构造和文档化开发系统所涉及的业务过程。在活动图的这种用法中，对对象流的建模是特别重要的。
|
|
|
|
（2）对操作建模。此时是把活动图作为流程图使用，对一个计算的细节部分建模。在活动图的这种用法中，对分文、分叉和汇合状态的建模是特别重要的。用于这种方式的活动图语境包括该操作的参数和它的局部对象。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
结构化设计方法中使用结构图来描述系统的体系结构，指出一个系统由哪些模块组成，以及模块之间的调用关系。结构图的基本成分有：模块、调用和数据。
|
|
|
|
|
|
在结构化设计中，模块指具有一定功能并可以用模块名调用的一组程序语句，如函数、子程序等，它们是组成程序的基本单元。
|
|
|
|
一个模块具有外部特征和内部特征。模块的外部特征包括：模块的接口（模块名、输入／输出参数、返回值等）和模块功能。模块的内部特征包括：模块的内部数据和完成其功能的程序代码。
|
|
|
|
在结构图中，模块用矩形表示，并用名字标识该模块，名字应体现该模块的功能。
|
|
|
|
|
|
结构图中模块之间的调用关系用从一个模块指向另一个模块的箭头来表示，其含义是前者调用了后者。
|
|
|
|
|
|
模块间还经常用带注释的短箭头表示模块调用过程中来回传递的信息。箭头尾部带空心圆的表示传递的是数据，带实心圆的表示传递的是控制信息，如下图所示。
|
|
|
|
|
|
|
|
可以在结构图上添加一些辅助符号进一步描述模块间的调用关系。如果一个模块是否调用一个从属模块决定于调用模块内部的判断条件，则该调用模块间的判断调用采用菱形符号表示；如果一个模块通过其内部循环的功能来循环调用一个或多个从属模块，则该调用称为循环调用，用弧形箭头表示。判断调用和循环调用的表示方法如下图所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
类图（class diagram）展现了一组对象、接口、协作和它们之间的关系。在面向对象系统的建模中所建立的最常见的图就是类图。类图给出系统的静态设计视图。包含主动类的类图给出了系统的静态进程视图。
|
|
|
|
类图中通常包括下述内容：类；接口；协作；依赖、泛化和关联关系，如下图所示。
|
|
|
|
|
|
|
|
类图中也可以包含注解和约束。类图还可以含有包或子系统，二者都用于把模型元素聚集成更大的组块。
|
|
|
|
类图用于对系统的静态设计视图建模。这种视图主要支持系统的功能需求，即系统要提供给最终用户的服务。当对系统的静态设计视图建模时，通常以下述三种方式之一使用类图。
|
|
|
|
|
|
对系统的词汇建模涉及做出这样的决定：哪些抽象是考虑中的系统的一部分，哪些抽象处于系统边界之外。用类图详细描述这些抽象和它们的职责。
|
|
|
|
|
|
协作是一些共同工作的类、接口和其他元素的群体，该群体提供的一些合作行为强于所有这些元素的行为之和。例如当对分布式系统的事务语义建模时，不能仅仅盯着一个单独的类来推断要发生什么，而要有相互协作的一组类来实现这些语义。用类图对这组类以及它们之间的关系进行可视化和详述。
|
|
|
|
|
|
将模式看作为数据库的概念设计的蓝图。在很多领域中，要在关系数据库或面向对象数据库中存储永久信息。可以用类图对这些数据库的模式建模。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
随着嵌入式技术的发展，特别是在后PC时代，嵌入式软件系统得到了极大的丰富和发展，形成了一个完整的软件体系。如下图所示，这个体系自底向上由3部分组成，分别是嵌入式操作系统、支撑软件和应用软件。
|
|
|
|
|
|
|
|
嵌入式操作系统（Embedded Operating System, EOS）由操作系统内核、应用程序接口、设备驱动程序接口等几部分组成。嵌入式操作一般采用微内核结构。操作系统只负责进程的调度、进程间的通信、内存分配及异常与中断管理最基本的任务，其他大部分的功能则由支撑软件完成。
|
|
|
|
嵌入式系统中的支撑软件由窗口系统、网络系统、数据库管理系统及Java虚拟机等几部分组成。对于嵌入式系统来讲，软件的开发环境大部分在通用台式计算机和工作站上运行，但从逻辑上讲，它仍然被认为是嵌入式系统支撑软件的一部分。支撑软件一般用于一些浅度嵌入的系统中，如智能手机、个人数字助理等。
|
|
|
|
嵌入式系统中的应用软件是系统整体功能的集中体现。系统的能力总是通过应用软件表现出来的。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
RPR的体系结构如下图所示。RPR采用了双环结构，由内层的环1和外层的环0组成，每个环都是单方向传送。相邻工作站之间的跨距包含传送方向相反的两条链路。RPR支持多达255个工作站，最大环周长为2000km。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
状态图（statechart diagram）展现了一个状态机，它由状态、转换、事件和活动组成。状态图关注系统的动态视图，它对于接口、类和协作的行为建模尤为重要，它强调对象行为的事件顺序。状态图通常包括：简单状态和组合状态、转换（事件和动作）。如下图所示。
|
|
|
|
|
|
|
|
可以用状态图对系统的动态方面建模。这些动态方面可以包括出现在系统体系结构的任何视图中的任何一种对象的按事件排序的行为，这些对象包括类（各主动类）、接口、构件和节点。当对系统、类或用例的动态方面建模时，通常是对反应型对象建模。一个反应型或事件驱动的对象是这样一个对象，其行为通常是由对来自语境外部的事件做出反应来刻画的。反应型对象在接收到一个事件之前通常处于空闲状态。当它接收到一个事件时，它的反应常常依赖于以前的事件。在这个对象对事件做出反应后，它就又变成闲状态，等待下一个事件。对于这种对象，将着眼于对象的稳定状态、能够触发从状态到状态的转换的事件，以及当每个状态改变时所发生的动作。
|
|
|
|
|
|
|
|
|
|
|
|
|
