系统建模分析期末重点.docx
- 文档编号:723380
- 上传时间:2022-10-12
- 格式:DOCX
- 页数:10
- 大小:85.58KB
系统建模分析期末重点.docx
《系统建模分析期末重点.docx》由会员分享,可在线阅读,更多相关《系统建模分析期末重点.docx(10页珍藏版)》请在冰豆网上搜索。
系统建模分析期末重点
1.建模/MDA/MDD的根本概念。
2、实时系统的根本概念〔硬实时、软实时、固实时〕。
3、RM/EDF调度算法。
4、ROPES设计方法的描述。
5、建模设计中的正向工程与逆向工程。
6、实时系统建模分析中的外部事件定义及时间等约束。
6、用例与场景的区别、用例图、时序图、类图。
7、识别对象的根本方法及对象间的关系。
8、用例图、类图的画法。
9.用例、协作、机制的定义和作用域
10.设计模式模板如何定义
11.详细设计主要解决哪些问题
12.字节对齐与存分配问题
14.智能指针模式的构造方法
15.单点失效、共模失效概念,故障分析树画法
16.可靠性设计模式中冗余通道的分类及构造方法
17.门禁模式的定义、时序图和分类
18.类图的UML语法
19.状态图画法,以实验3Dishwasher为例
20.实验局部:
状态机、时间自动机〔timedautomata/uppaal使用〕
1.建模/MDA/MDD的根本概念
建模是对现实世界的一个简化。
因为不能完整地理解一个复杂的系统,所以要对它建模。
建模是为了更好的理解我们正在开发的系统。
建模的目的:
模型帮助按照实际情况后按照所需的样式对系统进展可视化
模型允许详细说明系统的构造或行为
模型给出了一个知道构造系统的模板
模型对做出的决策进展文档化
建模的原那么:
选择要创立什么模型对如何动手解决问题和如何形成解决方案有着意义深远的影响
每一种模型可以在不同的精度级别上显示
最好的模型是与现实相联系的
单个模型是不充分的,对每个重要的系统最好用一组几乎独立的模型去处理
模型驱动架构(MDA)〔moudledriverarchitecture〕
OMG(ObjectManagementGroups)定义模型驱动架构是一个软件开发框架
建模,建模语言在MDA方法里面起到了至关重要的作用
开发阶段产生形式化模型,可被计算机理解的模型
OMG提出MDA方法的三个主要目标:
轻便性,互操作性和可重用性
具体解决以下问题:
扭转以代码为中心的软件开发方法
解决不同平台、不同技术路线之间的集成和互操作问题
便于适应将来出现的新技术和新平台
MDA的核心概念均是OMG系列的一系列标准:
统模语言UML,元对象设计MOF,XML元数据交换XMI,公共数据仓库元模型CWM。
MDA的各种核心标准组成了创立模型驱动的一致性纲要的根底。
MDA定义了三种模型:
•计算独立模型〔CIM〕
•平台独立模型〔PIM〕
•平台特定模型〔PSM〕
模型驱动开发〔MDD〕moudledriverdevelopment
MDD是一种抽象的软件开发设计流程
主要包括以下特点:
1、抽象〔提高层次〕,封装和信息隐藏
通过模型的多个层次〔横向和纵向〕来隐藏和展示信息,从而使模型更容易被理解
2、以模型为中心:
开发过程始终以模型为工作中心
3、不依赖于任何一种特定的实现:
模型独立于运行平台的实现细节,这局部往往是最容易变化的
2、实时系统的根本概念〔硬实时、软实时、固实时〕
任何必须在有限/指定的周期对外部发生的输入鼓励做出响应的信息处理活动或系统。
另:
实时系统是指在确定的时间完成规定功能,并能对外部异步事件作出正确响应的计算机系统。
正确性不仅取决于计算的逻辑结果,也取决于产生结果所花费的时间的系统。
实时系统具有及时性与正确性的双重特性。
实时系统的正确性不仅依赖于计算的合理结果,还依赖于产生这个结果的时间。
硬实时:
硬实时系统是那些在规定的时限前做出响应是绝对强制性要求的系统。
UNIX系统可以被看做一个实时系统,当用户输入一个命令,会期待在几秒得到响应
软实时:
软实时系统是响应时间虽然重要,但如果偶尔错过时限系统依然正常运行的系统。
〔同交互式系统的区别:
对后者而言无明显的时限。
〕
•软实时并不是指一种单一的需求,它伴随着一些不同的性质:
1)可以偶尔错过时限〔通常有一个在确定的时间间隔的错过次数上限〕。
2)可以偶尔推迟提供效劳〔同样,有一个延迟次数的上限〕
固实时:
3、RM/EDF调度算法
速率单调RM调度算法〔经典的静态实时调度算法〕
图:
第二章:
实时系统根本概念-----实时操作系统ppt14
RM算法是一种静态分配优先级算法,它根据任务的周期来分配优先级,周期越小,任务的优先级越高。
最正确的单处理机静态优先调度算法:
系统任务序列的周期、截止时限、执行时间、CPU利用率等时间特性参数都是己知的
不可调度:
指某一个任务在周期无法完成任务,即:
任务的执行完毕时间>任务的截止期
根底:
所有任务都是周期任务;
每个人物执行截止期等于该任务的周期;
每个任务在周期中,执行时间固定,保持常量;
最早截止时间优先即EDFEDF(EarliestDeadlineFirst)算法
图:
第二章实时系统根本概念pptp22
根据任务的开场截止时间确定任务的优先级,开场截止时间越早,优先级越高。
如果当前有其他较低优先级作业正在执行,那么较低优先级作业被抢占,让位给具有最高优先级的作业执行那个,直至就绪队列中没有高于改作业优先级的作业时,该作业恢复执行。
4、ROPES设计方法的描述
ROPES(rapidobjectprocessforembeddedsystem)嵌入式系统快速对象处理
第四章:
pptp6
•需求设计
–需求分析〔requirementsanalysis〕
–系统分析〔systemanalysis〕
–对象分析〔objectanalysis〕
•设计阶段
–架构设计〔architecturedesign〕:
部署视图、并发视图
–机制设计〔mechanisticdesign〕:
对象集合的协作
–详细设计〔detaileddesign〕:
类构造、部组织
•转换
•整合与测试
ROPES过程是基于迭代式生命周期,并使用标准UML元模型作为其语义框架和符号。
整体过程如:
1〕需求分析:
从客户获取需求。
客户是有责任定义系统该做什么的任何人。
通常是功能视图,并不给出对象和类。
消息:
这些信息通常在用例,对象上下文,顺序图,状态图,或外部消息队列中给出。
2〕系统分析:
系统分析是大规模复杂嵌入式系统的重要阶段,按功能进展分解架构
3〕对象分析:
对象分析给出重要的对象和类,以及他们的主要属性。
包括构造对象分析和行为对象分析。
设计阶段:
哪些对象是主动的
应用程序任务调度策略
对象和类在可部署组件中的组织
处理器间通信的媒介和协议
软件组件在节点间的分析情况
软件组件在节点间的分布情况
关系实现策略
错误处理策略
存管理策略
分析-设计-转化-测试
5、建模设计中的正向工程和逆向工程
正向工程〔forwardengineering〕:
是通过到一个实现语言的映射,把一个模型转换为代码的过程。
用例图可通过正向工程,形成对它所应用的元素的测试。
用例图中每一个用例是一个事件流,进展测试。
用例图描述系统功能而不是功能如何实现,因此不能进展正向工程和逆向工程
逆向工程〔reverseengineering〕:
是把代码转换为模型的过程。
通常会丧失信息。
代码—>功能转换。
6、实时系统建模分析中的外部事件定义及时间等约束。
外部事件分为同步和异步
对外部事件的响应包括:
当事件发生时可以识别,在给定的时间约束必须输出结果。
时间约束包括:
完成时间或开场时间和持续时间等。
外部事件:
周期性消息具有一定的周期特征,消息按照一定的周期到达,并可以有一定的抖动,抖动是消息实际到达时间与周期点间的偏离,抖动在建模的过程常被视为一个均匀随机过程,但其值总是在指定的时间间隔。
7、用例与场景的区别、用例图、时序图、类图。
用例描述的是系统的一项聚的功能块。
该功能块以黑盒形式对系统外部可见。
用例完全是对行为的描述,不会定义或者隐含对象或类的集合。
一个用例是外部可见的,说明系统的该项行为要和系统外部的对象相互作用。
这些系统外部的对象就是参与者〔actor〕。
用例图描述系统功能而不是功能如何实现,因此不能进展正向工程和逆向工程。
用例的实例是执行该行为的一条特定路径,这样的路径称作场景。
场景由一个对象集合和在对象间交换的一个有序的消息列表组成。
Ascenarioisaninstanceofausecase
Scenarioscanbedescribedintext,butmoreoftenthannot,theyarecapturedusingsequencediagrams.
用例〔usecase)是对系统主要、次要功能的描述。
经过一个用例的特定路径,称为一个场景〔scenario)
时序图:
第五章〔三〕ppt57
8、识别对象的根本方法及对象之间的关系
在名词下划线〔值得注意的,不值得注意的,对象属性〕
识别因果代理
识别聚性效劳
识别现实世界的元素
识别物理设备
识别域的根本抽象
识别事务
识别持久性信息
识别可视化元素识别控制元素执行对象模型中的场景
对象之间的关系:
泛化关系〔类之间的一种分类关系〕
依赖关系
关联
聚合
组合
9、用例图/类图的画法
第一章:
uml统模语言介绍pptp25第五章〔二〕pptp40marte_10pdf53(****)
类图由假设干类关联在一起,反映系统或者子系统组成构造的静态图。
类图的建模贯穿工程的分析和设计阶段的始终,通常从商务伙伴能够理解的类开场建模,最终往往成为挚友开发小组才能够完全理解的类。
类〔Class〕:
是具有共同构造特征,行为特征,联系和语义的对象集合的抽象形式
关联〔Association〕:
表示类与类之间的关系
类在UML常以实线矩形框表示,矩形框中含有假设干分隔框,分别包含类的名字,属性,操作,约束以及其他成分。
在类图中,根据建模的不同景象,类图标中不一定列出全部的容。
类的关系:
关联、依赖、聚合和泛化
如何建模类图
创立类图需两个反复执行的步骤:
1、确定类及其关联。
2、确定属性和操作。
开场创立类图的好起点就是用例图。
用例图(UseCaseDiagram)是由软件需求分析到最终实现的第一步,它描述人们如何使用一个系统。
用例视图显示谁是相关的用户、用户希望系统提供什么样的效劳,以及用户需要为系统提供的效劳,以便使系统的用户更容易理解这些元素的用途,也便于软件开发人员最终实现这些元素。
用例图在各种开发活动中被广泛的应用,但是它最常用来描述系统及子系统。
当用例视图在外部用户出现以前出现时,它捕获到系统、子系统或类的行为。
它将系统功能划分成对参与者〔即系统的理想用户〕有用的需求。
而交互局部被称作用例。
用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。
用例图包含六个元素,分别是:
参与者(Actor)、用例(UseCase)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
10、用例、协作、机制的定义和作用域〔marte_10pdf39pdf3〕
用例:
协作:
对象在一起形成有凝聚力的组件称为协作,协作是指定特定的类产生大规模的行为和交互的功能
协作工作,实现系统级的行为称为用例,通过他们的行为和操作
机制:
机制是一种模式,他受限在一些类的围,但在许多情况下适用
11、设计模式模板如何定义marte_10pdf3
设计优化问题的解决方法在不同的具体语境常是广义的和可重用的。
这种重用设计解决方案被称为设计模式
12、详细
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统 建模 分析 期末 重点