苏州科技学院软件建模与分析期末复习整理Word格式文档下载.docx
《苏州科技学院软件建模与分析期末复习整理Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《苏州科技学院软件建模与分析期末复习整理Word格式文档下载.docx（23页珍藏版）》请在冰点文库上搜索。
系统是否存储和检索信息，如果是，这个行为有哪个Actor触发
当系统改变状态时，通知参与者吗
存在影响系统的外部时间吗
4．关系
参与者与用例之间：
关联关系
用例与用例之间：
包含关系（include）、延伸关系（extend）、泛化关系（generalization）
参与者与参与者之间：
泛化关系（generalization）
第2讲统一建模语言
2．1掌握UML特点
UML的主要特点：
统一的标准、面向对象、可视化、表达能力强（概念明确）、独立于过程
2．2基本图标元素的表示符
关联：
连接（connect）模型元素及链接（link）实例。
依赖：
表示一个元素以某种方式依赖于另一种元素。
泛化：
表示一般与特殊的关系，即“一般”元素是“特殊”关系的泛化。
聚合：
表示整体与部分的关系。
2．3UML软件系统体系结构的五种视图和九种基本图
UML模型系统体系结构：
UML
模型元素
事物
结构事物
用例、类、接口、协作、主动类、组件、节点
行为事物
交互机、状态机
分组事物
包
辅助事物
注释
关系
关联关系、依赖关系、泛化关系、实现关系、聚合关系
通用机制
修饰、注解、规格说明、通用划分、扩展机制
视图
用例视图
用例图
逻辑视图
类、对象图
进程视图
时序图、协作图、状态图、活动图
构件视图
构件图
配置视图
配置图
五种视图：
1．用例视图
●描述系统的功能需求，找出用例和执行者；
●客户、分析者、设计者、开发者和测试者；
●描述用图：
用例图和活动图；
●重要性：
系统的中心，它决定了其他视图的开发，用于确认和最终验证系统。
2．逻辑视图
●描述如何实现系统内部的功能；
●分析者、设计者、开发者；
●类图和对象图、状态图、顺序图、合作图和活动图；
描述了系统的静态结构和因发送消息而出现的动态协作关系。
静态结构:
类图、对象图
动态行为：
状态图、活动图、时序图、协作图
3．进程视图
●描述系统代码构件组织和实现模块，及它们之间的依赖关系；
●设计者、开发者；
●构件图；
●描述系统如何划分软件构件，如何进行编程。
4．构件视图
●描述系统的并发性，并处理这些线程间的通信和同步；
●开发者和系统集成者；
●状态图、顺序图、合作图、活动图、构件图和配置图；
●将系统分割成并发执行的控制线程及处理这些线程的通信和同步。
5．配置视图
●描述系统的物理设备配置；
●开发者、系统集成者和测试者；
●配置图；
●描述硬件设备的连接和哪个程序或对象驻留在哪台计算机上执行。
2．4UML简单建模
UML的建模原则：
名字、作用域、可见性、完整性、运行属性。
第3讲用例模型视图
3．1用例图的概念
用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。
用例图最常用来描述系统以及子系统。
1．包含的元素6个：
参与者、用例、关联关系、包含关系、扩展关系、泛化关系。
（1）参与者：
系统外部的一个实体。
参与用例的执行过程。
通过向系统输入或请求系统输入某些事件来触发系统的执行。
由参与用例时所担当的角色来表示。
每个参与者可以参与一个或多个用例。
种类：
系统用户、与所建造的系统交互的其他系统、一些可以运行的进程。
（2）用例：
外部可见的系统功能单元。
在不揭示系统内部构造的前提下定义连贯的行为。
不是需求或功能的规格说明，但是也展示和体现其所描述的过程中的需求情况。
（3）关联关系：
表示参与者用例之间进行通信。
不同的参与者可以访问相同的用例。
（4）包含关系：
客户用例可以简单地包含提供者用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。
（5）扩展关系：
扩展用例被定义为基础用例的增量扩展。
基础用例提供扩展点以添加新的行为。
扩展用例提供插入片段以插入到基础用例的扩展点上。
（6）泛化关系：
父用例也可以被特别列举为一个或多个子用例。
子用例表示父用例的特殊形式。
子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变继承的行为。
3．2用例图建模技术
1．对语境建模
识别系统外部的参与者。
将类似参与者组织成泛化的结构层次。
在需要加深理解的地方，为每个参与者提供一个构造型。
将参与者放入到用例图中，并说明参与者与用例之间的通信路径。
2．对需求建模
识别系统的外部参与者来建立系统的语境。
考虑每一个参与者期望的行为或需要系统提供的行为。
把这些公共的行为命名为用例。
确定提供者用例和扩展用例。
对这些用例、参与者和它们之间的关系建模。
用注释修饰用例。
第4讲需求用例分析
1．太极建模
由外而内，层次分明；
动静结合，逐步求精。
2．需求的定义
系统的一个期望特性、属性或行为。
需求所需要的人：
用户、业务分析员、需求员、项目经理、测试员、程序员、架构师。
3．高质量的需要（目标）
完整性
正确性
可行性
必要性
分级性
无多义性/准确性
可验证性
一致性
可扩展性
可跟踪性
可管理性
稳定性
4.用户需要
业务需要、工作任务、业务需求
5．什么是用例？
针对某个特定的外部用例，系统通过与其交互而执行的，能够产生可观测的、有价值的结果的一个动作序列。
组成条件：
名称、简述、用例与参与者、层次、范围、后置条件、后置条件、触发事件、基本流、扩展流、扩展点、用例图、业务规则、约束、UI说明、变化点。
6．用例的价值
以用户为中心、最重要的需求（功能）
图文并茂、繁简结合、形式灵活
全面的字段和信息
规范的模版
清晰的层次结构
第5讲UML静态建模
5．1分析类的
1．概念
在分析模型中，分析类是概念层次上的内容，用于描述系统中较高层次的对象。
分析直接与应用逻辑相关，而不关注于技术实现的问题。
2．分析类的类型
实体类：
表示系统存储和管理的永久信息。
边界类：
表示参与者与系统之间的交互。
控制类：
表示系统在运行过程中业务控制逻辑。
3．实体类
描述必须存贮的信息及其相关行为，通常对应现实世界中的“事物”。
实体类的UML表：
4．边界类
描述外部的参与者与系统之间的交互，类型：
用户界面、系统接口、设备接口。
5．控制类
描述一个用例所具有的事件流控制行为，实现对用例行为的封装，将用例的执行逻辑与边界和实体进行隔离。
6．用例的实现
用例实现使用设计模型中的元素描述一个用例是如何实现和执行的，它是从分析和设计追溯到需求的一种方法。
从设计的视角表示用例的内容：
动态的：
直接对应用例事件序列的交互图。
静态的：
反映参与者用例事件序列的类及其关系的类图
5．2分析模型的处理
理解用例模型、识别分析类、定义交互行为、建立分析类图、检查分析模型。
1．识别边界类
通常，一个参与者与一个用例之间交互或通信关联对应一个边界类。
2．识别控制类
控制类负责协调边界类和实体类，通常在现实世界中没有对应的事物。
一般来说，一个用例对应一个控制类。
3．识别实体类
实体类通常是用例中的参与对象，参应着现实世界中的“事物”
4．创建分析类图
定义关系：
找出分析类之间的关联关系，并通过泛化实现复用。
定义属性：
按照一般常识、认真研究问题域、根据系统责任的要求、考虑对象需要系统保存的信息，等找出对象的某些属性；
对象为了在服务中实现其功能，需要增设一些属性；
识别对象需要区别的状态，考虑是否需要增加一个属性来区分别这些状态；
确定属性表示整体与部分结构和实例连接。
5．检查分析模式
需要检查的项目：
正确性、完整性、一致性、可行性。
第6讲动态建模-UML动态视图
6．1系统建模
系统建模：
一个完整的系统模型必须描述系统的静态和动态两个方面。
分为静态建模、动态建模。
静态建模：
描述系统中对象，每个对象包含的数据，以及它们之间存在的链接。
产生静态模型。
动态建模：
描述系统运行时的动态行为。
产生动态模型。
对象通过通信来协作的方式，以及对象在系统的生命周期中改变状态的方式是系统的动态行为。
6．2动态视图
1．顺序图（序列图）
2．协作图
描述协作对象间的交互和链接，侧重于空间的协作
链接显示对象之间是如何联系在一起的
协作图显示对象间的链接以及链接对象间如何发送消息
协作图从初始化整个交互或协作的消息开始
协作图没有显示的返回消息表示，是为了简化协作图。
从消息返回的数据可以放在消息名前面，中间用“:
=“隔开。
3．状态图
（1）状态
状态图描述对象在生命周期中可能的状态s以及每一种状态的重要行为；
描述它所检测到的事件以及什么样的事件引起对象状态发生改变。
状态的重要特征：
一个对象有若干个可能的状态，并且在任何给定时间恰好处于这些状态中的一个；
对象可以改变状态；
不同时间，一个对象可能依赖其状态对同一刺激做出不同的响应。
区分状态原则：
处于一个特定状态的对象对至少一个事件的响应和它处于其他状态时对该事件的响应不同。
（2）事件（event）：
当某些事情发生时，对象的状态发生改变，称改变对象状态的事情为“事件”。
表现为发送给对象的消息。
（3）迁移（Transition）：
检测到一个事件可能导致对象从一个状态移动到另一个状态，这样的移动成为迁移或转换。
状态迁移用连接两个状态的箭头表示。
箭头必须标注一个事件的名字。
箭头的含义：
如果对象在处于箭头尾的状态时接收到事件，对象将迁移到箭头所指向的状态。
（4）动作和活动的理解
动作和活动都是一种过程，都由对象中的方法来实现，但动作与迁移关联，处理较快且不会被中断；
活动与状态关联，处理时间较长且可以被事件中断。
●特殊状态--初始状态和终止状态
初始状态：
一个黑色小圆点表示。
从初始状态出发的迁移表示创建或初始化对象时进入的状态。
从初始状态出发的转换不写任何事件。
终止状态：
用大圆圈中加一个黑色小圆点表示。
终止状态代表对象在响应撤
●特殊状态---组合状态
允许一个状态包含若干子状态。
这些子状态都具有一些共有的特性。
这些特性组合成一组放入一个状态中，这个状态即是组合状态。
4．活动图
捕获动态行为（面向活动的），目的是给商业工作流建模、给操作建模。
要素：
泳道、信号
1．泳道
活动图告诉你发生了什么，但没有告诉你该项活动由谁来完成。
在程序设计中，这意味着活动图没有描述出各个活动由哪个类来完成。
泳道解决了这一问题。
它将活动图的逻辑描述与序列图的责任描述结合起来。
泳道用矩形框来表示，属于某个泳道的活动放在该矩形框内，将对象名放在矩形框的顶部，表示泳道中的活动由该对象负责。
2．信号
在活动图中可以表示信号的发送与接收，分别用发送和接收标志来表示。
发送和接收标志也可与对象相连，用于表示消息的发送者和接收者。
第7讲UML顺序图
1．使用顺序图建模
顺序图是两种类型的交互图之一。
顺序图用来建模以时间顺序安排的对象交互，并且把用例行为分配给类。
它是用来显示参与者如何采用若干顺序步骤与系统对象交互的模型。
2．为什么要建模顺序图
建模顺序图有许多理由，顺序图与活动图具有类似的作用。
其中重要的理由就是实现用例。
任何用例都可以使用顺序图进一步阐明和实现。
3．顺序图的标记符
顺序图有两个主要的标记符：
活动对象和这些活动对象之间的通信消息。
活动对象可以是任何在系统中扮演角色的对象，不管它是对象实例还是参与者，如下图所示。
活动对象之间发送的消息是顺序图的关键。
消息说明了对象之间的控制流，对象是如何交互的，以及什么条件会改变控制流。
（1）活动对象
活动对象可以是系统的参与者或者任何有效的系统对象。
对象是类的实例，它使用包围名称的矩形框来标记。
（2）消息用来说明顺序图中不同活动对象之间的通信。
它可在一个对象需要取消不同对象的进程时或者需要向另一个对象提供服务时，使用消息。
消息从活动对象生命线到接收对象生命线的箭头表示。
箭头上面标记要发送的消息。
4．如何使用消息进行通信
消息是顺序图活动对象之间通信的惟一方式。
UML中的消息使用了一些简洁的标记符。
消息可以包含条件以便限制它们只在满足条件时才能发送。
条件显示在消息名称上面的方括号中。
5．顺序图的其他技术
学习如何在创建顺序图的过程中创建对象。
与活动图一样，可以在顺序图中设置拥有控制权的对象状态。
另外一点和活动图相似的是，可以通过使用分支和从属控制流来以多种方式修改顺序图的控制流。
（1）创建对象
创建对象的标记符如下图中的示例所示。
有一个主要步骤用来把“create”消息发送给对象实例。
对象创建之后就会具有生命线，可以使用该对象发送和接收消息。
在处理新创建的对象，或者处理顺序图中的任何其他对象时，都可以发送“destroys”消息来删除对象。
若要想说明某个对象被销毁，需要在被销毁对象的生命线上放一个X字符。
（2）分支和从属流
有两种方式来修改顺序图的控制流：
使用分支和使用从属流。
这两种方式很相似，各自的标记符略微不同。
控制流的改变是由于不同的条件导致控制流走向不同的道路。
6．学习如何建模顺序图
创建顺序图包含4项任务：
1）确定需要建模的工作流。
2）从左到右布置对象。
3）添加消息和条件以便创建每一个工作流。
4）绘制总图以便连接各个分图。
第8讲UML协作图
1．概述
与顺序图一样，协作图也展示对象之间的交互关系。
它绘制出对象与对象之间的消息连接。
顺序图与协作图很相似，实际上这两种图表达的是同一种信息，并且可以将顺序图转换为等价的协作图，反之亦然。
顺序图和协作图虽然都可以表示各对象间的交互关系，但它们的侧重点不同。
顺序图强调的是交互的时间顺序。
协作图强调的是交互的语境与参与交互的对象的整体组织。
2．协作图在UML中的表示方法
对象图展示出对象和对象之间的静态关系。
协作图是对象的扩展。
协作图除了展示出对象之间的关联，还显示出对象之间的消息传递。
通常在协作图中省略掉关联的名字，因为表示出关联的名字会使图变得混乱。
关联线附近的箭头线表示对象之间传递的消息，箭头指向消息接收对象。
消息名称和消息序号附在箭头线附近。
消息的一般含义是触发接收消息的对象执行它的一个操作。
箭头的含义和顺序图中的一样。
3．其他概念
（1）发送给多对象的消息
一个对象可能会向同一个类的多个对象同时发送一个消息。
例如老师会让多个学生同时交作业。
在协作图中，多对象（multipleobject）用“一叠向后延伸的多个对象图标”来表示。
在多对象前面可以加上用方括号括起来的条件，前面加一个星号，用来说明消息发送给多个对象。
（2）返回结果
消息可能是要求某个对象进行计算并返回结果的值。
例如一个顾客对象可能请求一个计算器（calculator）对象计算某项商品的总价，包括该项商品的价格和税款。
UML提供了返回值的表示法。
返回值的名字在最左，后跟赋值号“：
=”.接着是操作名和操作参数。
对计算商品价格这个例子，可以表示成：
totalPrice:
=compute（itemPrice,salesTax）。
下图说明了在协作图中返回值的表示法。
表达式中赋值号的右边部分被称为消息构型（messagesignature）.
（3）主动对象
在一些交互中，控制流是由一个特定的对象控制的。
这样的对象叫做主动对象（activeobject）。
一个主动对象可以向被动对象发送消息也可以与其他主动对象交互。
（4）同步
有时遇到的另一种情况是一个对象只能等到其他一些对象发送了消息（可能是不连续的发送消息）后才能发送消息。
也就是说，这个对象必须要“同步“自己发送的消息与其他对象发送的消息。
第9讲UML状态图
状态图的标记符与活动图的标记符非常相似，有时会让人混淆。
其实，状态图用来表示单个对象的行为如何改变其状态。
而活动图是用来建模不同区域的工作如何彼此交互。
1．定义状态图
状态图用来建模对象是如何改变其状态以响应事件和展示对象从创建到删除的生命周期。
状态定义为对象行为在某一个时刻的快照或者转折点。
2．为什么要建模状态图
状态图除了可以用于描述对象接收事件触发时的行为状态外，它还可以用于许多其他情况。
例如，状态图可以用来说明基于用户输入的屏幕状态改变，也可以用来说明复杂用例的状态进展情况。
在一般系统中，不需对每个类创建状态图。
当一个类实例（对象）有多种状态，每种状态中的行为表现又不相同，则可创建状态图。
3．状态图的标记符
状态图由状态、转移和事件组成。
状态图中共有3种独立的状态标记符，如下图所示：
状态细节是指当对象处于特定状态时，可能要进行一些活动，例如生成报表、进行计算或向另一对象发送事件。
为了进一步描述对象在特定状态下的一些活动，可加入细节活动、进入、退出、事件和状态历史信息。
（2）转移
转移用来显示从一个状态到另一个状态的处理流。
转移使用从一个状态到另一个状态的开放箭头来标记，如下图所示。
（3）决策点
决策点在建模状态图时提供了方便，因为它通过在中心位置分组转移到各自的方向，从而提高了状态图的可视性，如下图所示。
状态图中使用同步是为了说明并发工作流的分岔与联合。
下图所示为同步条的标记符。
4．转移的事件、条件和动作
条件用来描述状态转移的前提。
事件用来指示什么触发了转移，动作用来说明当转移发生时会产生什么情况。
事件、条件和动作是转移的三个选项，其定义格式见下图所示。
5．学习如何建模状态图
（1）标识出需要进一步建模的实体。
（2）标识出每一个实体的开始状态和结束状态。
（3）确定与每一个实体相关的事件。
第11讲UML活动图
活动图是状态机的一个变体，用来描述执行算法的工作流程中涉及的活动。
活动状态代表了一个活动：
一个工作流步骤或一个操作的执行。
活动图描述了一组顺序的或并发的活动。
2．活动图在UML中的表示方法
活动图包括一些方便的速记符号，这些符号实际上可以用于任何状态图，尽管活动图和状态图的混合表示法多数时候都很难看。
活动状态表示成带有圆形边线的矩形，它含有活动的描述（普通的状态盒为直边圆角）。
简单的完成转换用箭头表示。
和状态图相似，活动图也有起点和终点符号，表示法和状态图一样。
（1）判定
一个活动序列几乎总是要到达某一点，在这一点处要做出判定。
一组条件引发一条执行路径，另一组条件则引发另一条执行路径，并且这两条执行条件是互斥的。
两种方法表示：
一种方式是从一个活动直接引出可能的路径。
另一种方式是将活动的转移引到一个小的菱形图标，然后从这个菱形的图标中再引出可能的路径。
（2）并发路径
在对活动建模时，往往要将一个转移划分成两个单独的同时（并发）执行的路径，而后它们再合并在一起。
要表示这种活动路径的划分，可以用一个与路径垂直的黑色粗实线条表示，并发的路径从这个实线条引出。
而并发路径的合并也使用另一个粗实线条表示。
（3）对象流
活动图能表示对象的值流和控制流。
对象流状态表示活动中输入或输出的对象。
对输出值而言，虚线箭头从活动指向对象流状态。
对输入值而言，虚线箭头从对象流状态指向活动。
如果活动有多个输出值或后继控制流，那么箭头背向分叉符号。
同样，多输入箭头指向结合符号。
（4）泳道
将模型中的活动按照职责组织起来通常很有用。
例如，可以将一个商业组织处理的所有活动组织起来。
这种分配可以通过将活动组织成用线分开的不同区域来表示。
由于它们的外观的缘故，这些区域被称作泳道。
升级会员 