第5章--需求建模
第五章结构化分析与建模
![第五章结构化分析与建模](https://img.taocdn.com/s3/m/b69af4c2ce2f0066f53322b6.png)
结构化分析模型
系统模型从以下不同的角度表述系统:
从外部来看,它是对系统分析上下文或系统环境建模; 从行为上看,它是对系统行为建模; 从结构上看,它是对系统的体系结构和系统处理的数 据结构建模。
系统行为模型:
结构化的需求分析模型有:
数据流模型,用来描述系统中的数据处理过程。 状态转换模型,用来描述系统如何对事件做出响应。
数据流图举例
假设我们要开发一个学生管理系统。 其中开发小组通过进行进一步的需求调查,明 确了该系统的主要功能是进行学籍管理,包括 学生报到、入学、毕业的管理,学生上课情况 的管理。 通过详细的信息流程分析和数据收集后,生成 了该子系统的数据流图。
将0层 DFD中的加工“1.0报到”分解成1层DFD中的3个子 加工:“ 1.1 核对录取通知书”、“ 1.2 核对体检结果”和 “1.3同意入学”。保留0顶层DFD加工边界中的7个数据流。 随着加工的分解,新增两个数据流“已核对的录取通知书” 和“已核对的体检结果”。
数据流图举例:飞机机票预订系统:旅行社把预订机票的旅客信 息输入机票预订系统。系统为旅客安排航班,打印出取票通知单 (附应交的帐款)。旅客在飞机起飞的前一天凭取票通知等交款 取票,系统检验无误,输出机票给旅客。
旅行社
订票单 分类并检查
有效订票单 订票
航班 取票单 有效取 票单 记账文件 机票准备 账单 记账 取票通知单 航班目录
旅客
机票
机票文件
旅行社
数据流图举例(分层)
设一个工厂采购部每天需要一张定货报表。定货 的零件数据有:零件编号、名称、数量、价格、 供应者等。零件的入库、出库事务通过计算机终 端输入给定货系统。当某零件的库存数少于给定 的库存量临界值时,就应该再次定货。 数据流分析:
潘加宇-软件方法
![潘加宇-软件方法](https://img.taocdn.com/s3/m/799fd89a51e79b89680226e9.png)
自序
光阴匆匆似流水,它一去不再回。 《浪子归》 ;词:黄小茂,曲:崔健,唱:崔健;1986 1999 年还是一名程序员时,我创建了 UMLChina,从那时开始关注软件工程各方面的进展。2001 年 12 月,阿里 巴巴的吴泳铭来 email 询问是否有 UML 方面的训练,我开始准备训练材料。2002 年 3 月,我去杭州给阿里巴巴做了这 个训练。虽然与后来我给阿里集团各公司做的许多次训练相比,这第一次讲课从内容和形式都算是糟透了,但是我现 在还记得当时的心情――迈出自己事业第一步的心情。 目前(2011 年 6 月)为止,我已经上门为已经超过 150 家的软件组织提供需求和设计技能的训练和咨询服务。训 练结束后,学员们常会问: “潘老师,上完课后我们应该看什么书?”我总是回答: “先不用看杂七杂八的书,还是要 复习我们留下的资料,那些幻灯片、练习题、模型就已经是最好的书了,按照改进指南先用一点点在具体项目上,带 着出现的具体困惑来和我讨论。 ”虽然一再这样强调了,有的学员还是经常情不自禁地拿着一本《***UML***》之类的 书来问我问题,不管书上说得对不对。看来写在正式出版物上的效果就是不一样啊。 其实现在出书也不难,UMLChina 一直在和出版社合作推介国外优秀的软件工程书籍,目前已经有三十多本软件工 程书籍上有 UMLChina 的标记了。不过我一直没有自己写一本书,主要原因还是觉得自己的积累不够,思考的深度也不 够,对软件开发的认识还在不断变化。如果没有自己成型的东西,不能站在别人的肩膀上看得更远,只是摘抄别人的 观点,这样的书有什么意义呢? 另外一个原因是,UMLChina 后来开始采取了“隐形、关门”的策略,秉持“内外有别”的原则。我关闭了已经有 4 万多人的 Smiling 电子小组(也是为了降低某些风险) ,网站不再有公开的社区,在网站上也找不到“客户名单” ,所 有更细致的服务以非公开的方式对会员提供。在这种情况下,出一本书也不是那么迫切。 现在距离第一次提供服务已经将近十年,也有了一些积累,所以硬着头皮也要开始写书了。在这些年的服务过程 中,和开发团队谈到改进时,我发现一个有趣的现象:很多开发团队(不是每个团队)或多或少都会有人(不是每个 人)或明或暗地表达出这样的观点――自己团队的难处与众不同,奇特的困难降临在他们身上,偏偏别人得以幸免。 尽管 UMLChina 一直强调自己的服务是“聚焦最后一公里” ,坚信每一个开发团队都会在细节上和其他团队有所不 同,而且也应该有所不同。但很多时候,我还是感觉到,开发团队还是高估了自己的“个性” ,低估了“共性” 。本书 就是归纳这样一些“共性” ,作为我的一家之言,供大家参考。感谢曾经选择过我的服务的伙伴们。他们一次次地给我 机会来实践、发展和锤炼技艺,才有了这本书。 目前还没有和任何出版社商议出纸书事宜。本书先以电子版方式公布,不定期更新版本,您可以到
软件工程 第5章--UML
![软件工程 第5章--UML](https://img.taocdn.com/s3/m/9ee741ed81c758f5f61f673c.png)
UML的定义
UML定义有两个主要组成部分:语义和表示法。 语义用自然语言描述,表示法定义了UML的可 视化标准表示符号,这决定了UML是一种可视 化的建模语言。 在语义上,模型是元模型的实例。UML定义给 出了语法结构的精确定义。 使用UML时,要从不同的角度观察系统,为此 定义了概念“视图(View)‖。视图是对系统的模 型在某方面的投影,注重于系统的某个方面。
独立于过程
系统建模语言,独立于开发过程。
9
容易掌握使用 概念明确,建模表示法简洁明了,图形结 构清晰,容易掌握使用。 着重学习三个方面的主要内容: (1) UML的基本模型元素 (2) 组织模型元素的规则 (3) UML语言的公共机制 与程序设计语言的关系 用Java,C++ 等编程语言可实现一个系统。 一些CASE工具可以根据 UML所建立的系 统模型来产生Java、C++ 等代码框架。
31
UML事物 — 注释事物
11) Note(注释)
依附于一个元素或一组元素之上,对其进
行约束或解释的简单符号。没有语义影响。
See policy8-5-96.doc for details about these algorithms.
CashAccount presentValue()
32
15
UML定义 9 种图,表达UML中的 5 种视图,各 视图在静态和动态方面表示系统模型。
结构 视图 静态 方面
动态 方面
行为 视图 同左
实现 视图 构件图
环境 视图 部署图
同左
用例 视图 用例图
同左
类图 对象图
顺序图 同左 顺序图 合作图 (注重 合作图 状态图 进程、 状态图 活动图 线程) 活动图
软件工程方法论教案-章程
![软件工程方法论教案-章程](https://img.taocdn.com/s3/m/9c7931b1f111f18582d05a43.png)
(二)细化阶段
(三)构建阶段
(四)转换阶段
(五)生产阶段
归
纳
总
结
通过本章的学习,掌握通用过程模型,掌握惯用的过程模型。
第三次课程教学方案
周次
3
课时数
2
教学章节,阐述软件工程中敏捷理念的四个关键问题:自我组织团队对所开展工作具有控制力的重要性;团队成员之间以及开发参与者与客户之间的交流与合作;对“变更代表机遇”的认识;强调快速软件交付以让客户满意。并对最广泛应用的敏捷过程极限编程(XP)做出讲解。掌握用敏捷开发的方法以适应现代软件工程的需求。
□ CAI课件 □ IP课件 □ 其他资源:
课后作业
P15:1.5、1.8
板
书
设
计
教学课件《第1章软件和软件工程》
第一次教学活动设计
教学
环节
内容设计与手段
导
入
新
课
1.全面地介绍《软件工程方法论》的课程内容、课程目的和课程要求
2.提问:软件和软件工程的区别和联系;什么是方法论?
3.导入第一章的课程内容
确定一套解决需求问题的初步方案
4.4开发用例
一组用户场景,描述系统的线程使用
从“参与者”的点-视角来描述每一个场景——人或设备以某种方式与软件交互
4.5构建需求模型
分析模型的元素
基于场景的元素
功能说明——处理软件功能的描述
用例——描述“参与者”和系统之间的交互作用
基于类的元素
由场景暗示
行为元素
状态图
讲
授
内
容
5.1需求分析
–确定软件的操作特性
–指明软件和其他系统元素的接口
(完整版)软件工程 第五章 面向对象的需求分析
![(完整版)软件工程 第五章 面向对象的需求分析](https://img.taocdn.com/s3/m/5b338639af45b307e8719771.png)
第五章面向对象的需求分析面向对象的需求分析方法的核心是利用面向对象的概念和方法为软件需求建造模型。
它包含面向对象风格的图形语言机制和用于指导需求分析的面向对象方法学。
面向对象的思想最初起源于 20世纪 60年代中期的仿真程序设计语言Simula67。
20世纪80年代初出现的Smalltalk 语言及其程序设计环境对面向对象技术的推广应用起到了显著的促进作用。
20世纪90年代中后期诞生并迅速成熟的UML(Unified Modeling Language,统一建模语言)是面向对象技术发展的一个重要里程碑。
UML 统一了面向对象建模的基本概念、术语和表示方法,不仅为面向对象的软件开发过程提供了丰富的表达手段,而且也为软件开发人员提供了互相交流、分享经验的共用语言。
本章首先介绍面向对象的主要概念和思想。
在概述了UML的全貌之后,以“家庭保安系统”为实例,介绍与需求分析相关的部分 UML语言机制以及基于UML的面向对象的需求分析方法和过程。
第一节面向对象的概念与思想一、面向对象的概念关于“面向对象”,有许多不同的看法。
Coad和 Yourdon给出了一个定义:“面向对象 = 对象 + 类 + 继承 + 消息通信”。
如果一个软件系统是使用这样4个概念设计和实现的,则认为这个软件系统是面向对象的。
一个面向对象的程序的每一成分应是对象,计算是通过新的对象的建立和对象之间的消息通信来执行的。
1.对象(object)一般意义来讲,对象是现实世界中存在的一个事物。
可以是物理的,如一个家具或桌子,如图 5-1-1所示,可以是概念上的,如一个开发项目。
对象是构成现实世界的一个独立的单位,具有自己的静态特征(用数据描述)和动态特征(行为或具有的功能)。
例如:人的特征:姓名、性别、年龄等,行为:衣、食、住、行等。
图 5-1-1 对象的定义(1)对象、属性、操作、消息定义对象可以定义为系统中用来描述客观事物的一个实体,它是构成系统的一个基本单位,由一组属性和一组对属性进行操作的服务组成。
作业二___结构化需求建模(第5章)
![作业二___结构化需求建模(第5章)](https://img.taocdn.com/s3/m/2e455bd39ec3d5bbfd0a7453.png)
作业二结构化需求建模(第5章)2-1、简答业务流程图与数据流程图的作用、含义和区别2-2、目前住院病人主要由护士护理,这样做不仅需要大量护士,而且由于不能随时观察危重病人的病情变化,还会延误抢救时机。
某医院打算开发一个以计算机为中心的患者监护系统,请分层次地画出描述本系统功能的数据流图。
医院对患者监护系统的基本要求是随时接收每个病人的生理信号(脉搏、体温、血压、心电图等),定时记录病人情况以形成患者日志,当某个病人的生理信号超出医生规定的安全范围时向值班护士发出警告信息,此外,护士在需要时还可以要求系统印出某个指定病人的病情报告。
2-3、银行计算机储蓄系统的工作过程大致如下:储户填写的存款单或取款单由业务员键入系统,如果是存款则系统记录存款人姓名、住址(或电话号码)、身份证号码、存款类型、存款日期、到期日期、利率及密码(可选)等信息,并印出存单给储户;如果是取款而且存款时留有密码,则系统首先核对储户密码,若密码正确或存款时未留密码,则系统计算利息并印出利息清单给储户。
请用数据流图描绘本系统的功能,并用实体-联系图描绘系统中的数据对象。
2-4、为了方便旅客,某航空公司拟开发一个机票预定系统。
旅行社把预定机票的旅客信息(姓名、性别、工作单位、身份证号码、旅行时间、旅行目的地等)输入该系统,系统为旅客安排航班,旅客在飞机起飞前一天凭取票通知和账单交款取票,系统核对无误即印出机票给顾客。
请画出描述本系统功能的数据流图。
2-5、复印机的工作过程大致如下:未接到复印命令时处于闲置状态,一旦接到复印命令则进入复印状态,完成一个复印命令规定的工作后又回到闲置状态,等待下一个复印命令;如果执行复印命令时发现没纸,则进入缺纸状态,发出警告,等待装纸,装满纸后进入闲置状态,准备接收复印命令;如果复印时发生卡纸故障,则进入卡纸状态,发出警告等待维修人员来排除故障,故障排除后回到闲置状态。
请用状态转换图描绘复印机的行为。
软件工程中的需求分析与建模
![软件工程中的需求分析与建模](https://img.taocdn.com/s3/m/c71ed17bf011f18583d049649b6648d7c1c708a5.png)
● 03
第3章 需求建模技术
需求建模概述
需求建模是软件工程中的一个重要环节,通过对需求 进行建模,可以更清晰地理解和定义系统需求。需求 建模的目的是为了准确地捕获用户需求,确保软件开 发过程中不会遗漏任何重要需求。同时,需求建模还 可以帮助团队更好地沟通和协作,提高项目的成功率。
用例建模
用例是描述系统功能的一种有效方式。通过用 例建模,可以清晰地定义系统的功能和用户与 系统之间的交互。用例图可以直观地展示系统 的功能和不同用户角色之间的交互关系。用例 描述则详细描述了每个用例的具体行为和步骤。
意度。
需求变更频繁
导致开发过程混乱
需求不明确
影响产品质量
沟通不畅
导致需求误解
面临的挑战
可能的改进方向
采用敏捷开发模式
迭代开发 持续集成 快速反馈
加强需求管理
建立需求数据库 制定明确需求文档 实施变更控制
提高沟通效率
定期沟通会议 使用协同工具 建立需求反馈渠道
展望未来
未来在软件工程领域,人工智能技术的发展将为需求 分析带来更多可能性,大数据技术的应用将提升需求 建模的精度,需求管理工具的不断创新将提高团队效 率。
测试
单元测试 集成测试
软件工程发展历程
软件工程的发展经历了多个阶段,从最初的混沌时期 到逐渐建立起规范的软件开发流程和方法。随着科技 的不断进步,软件工程也在不断演变和完善。
● 02
第二章 需求分析基础
需求分析概述
需求分析是软件工程中至关重要的一部分,它 涉及定义、识别和规范软件开发项目中的需求。 通过需求分析,可以确保开发团队在项目开始 阶段清晰了解客户的需求,明确目标和方向。 需要对需求进行系统性的分析,以确保最终的
《软件工程实用教程》第5_章_面向对象的需求分析
![《软件工程实用教程》第5_章_面向对象的需求分析](https://img.taocdn.com/s3/m/657f2c7ef242336c1eb95e61.png)
第5 章 面向對象的需求分析
5.2.2 封裝、繼承和多態
1.封裝 封裝是指把對象的外部特徵與內部實現細節分開,使 得一個對象的外部特徵對其他對象來說是可訪問的, 而它的內部細節對其他對象是隱蔽的。 對象具有封裝性的條件如下: (1) 有一個清楚的邊界,所有私有數據和操作的代碼都被 封裝在這個邊界內,從外面看不見更不能訪問; (2) 有確定的介面,這些介面描述這個對象和其他的對象 之間相互的作用; (3) 受保護的內部實現,這個實現給出了由軟體對象提供 的功能的細節,實現細節能在定義這個對象的類的外 面訪問。
第5 章面向對象的需求分析
通過在不同程度上運用抽象原則(忽略事物 之間的一些差異),可以得到較一般的類和 較特殊的類。特殊類繼承一般類的屬性和操 作,面向對象方法支持這種繼承關係的描述 與實現,從而簡化系統的構造過程及其文檔; 複雜對象可以用簡單的對象作為其構成部分 (稱為聚合); 對象之間通過消息進行通信,以實現對象之 間的動態聯繫; 通過關聯表達對象之間的靜態關係。
第5 章面向對象的需求分析
5.1.3 面向對象方法的優點 1. 與人們習慣的思維方法一致 2. 可使軟體系統結構更加穩定 3. 軟體具有更好的可複用性 4. 軟體更加便於維護與擴充
第5 章面向對象的需求分析
5.1.4 面向對象建模
用例模型:包含所有用例及其與用戶之間的關係; 對象模型:包含問題域涉及的類及其屬性和關係,其 作用是更詳細地提煉用例,將系統的行為初步分 配給提供行為的一組對象; 設計模型:將系統的靜態結構定義為子系統、類和介 面,並定義由子系統、類和介面之間的協作來實 現的用例; 實現模型:包含構件和類到構件的映射; 配置模型:定義電腦的物理節點和構件到這些節點的 映射; 測試模型:描述用於驗證用例的測試用例。
第5章几何建模与特征建模
![第5章几何建模与特征建模](https://img.taocdn.com/s3/m/c5c70944b307e87101f696ed.png)
二.数据结构(边界表示法数据结构)
实体建模采用表结构存储数据,其中棱线表和面表与曲面 造型有很大不同,从表中可以看出,棱线表记录的内容更加丰 富,可以从面表找到构成面的棱线,从棱线表中可以找到两个 构成的棱线的面。与曲面建模相比,实体模型不仅记录了全部 几何信息,而且记录了全部点、线、面、体的信息。
二.数据结构
三维线框模型采用表结构,在计算机内部存储物体的顶 点及棱线信息,请实体的几何信息和拓扑信息层次清楚的记 录在以边表、顶点表中。如下图所示的物体在计算机内部是 用18条边,12个顶点来表示的。
三.特点
1、优点 这种描述方法信息量少,计算速度快,对硬件要求低。数 据结构简单,所占的存储空间少,数据处理容易,绘图显示速 度快。 2、缺点 1)存在二异性,即使用一种数据表示的一种图形,有时也 可能看成另外一种图形。 2)由于没有面的信息,不能解决两个平面的交线问题。 3)由于缺少面的信息,不能消除隐藏线和隐藏面 4)由于没有面和体的信息,不能对立体图进行着色和特征 处理,不能进行物性计算。 5)构造的物体表面是无效的,没有方向性,不能进行数控 编程。
3)三维实体扫描体素: 实体扫描法是用 一个三维实体作为扫 描体,让它作为基体 在空间运动,运动可 以是沿某个曲线移 动,也可以是绕某个 轴的转动,或绕某一 个点的摆动。运动的 方式不同产生的结果 也就不同。
四.三维实体建模的计算机内部表示
1.边界表示法(B-Rep Boundary Representation
3)集合的交、并、差运算
4) 特点 (1)数据结构非常简单,每个基本体素不必再分,而是将 体素直接存储在数据结构中。 (2)对于物体结构的修改非常方便,只需要修改拼合的过 程或编辑基本体素。 (3)能够记录物体结构生成的过程。也便于修改 (4)记录的信息不是很详细,无法存储物体最终的详细信 息,如边界、顶点的信息等。 5)应用: 可以方便地实现对实体的局部修改 ,如下图
数学建模:第五章 运筹与优化模型
![数学建模:第五章 运筹与优化模型](https://img.taocdn.com/s3/m/9325a40503d8ce2f006623b6.png)
max c j x j
n
s.t aij x j bi
j 1
n
j 1
i 1.2 m
xj 0
j 1.2 n
8
二、整数规划模型
n min f c j x j j 1 n aij x j bi j 1 x j 0
对于线性规划:
22
二、货机装运
问题 某架货机有三个货舱:前仓、中仓、后仓。三个 货舱所能装载的货物的最大重量和体积都有限制,如表 3所示。并且,为了保持飞机的平衡,三个货舱中实际 装载货物的重量必须与其最大容许重量成比例。
重量限制 (吨)
前仓 中仓 后仓 10 16 8 6800 8700 5300
体积限制 (米3)
5
解:设x ij 表示 Ai (i=1.2)煤厂提供给 B j (j=1.2.3)居民区的煤量; f表示总运输费 此问题归结为:
min f 10 x11 5 x12 6 x13
s.t
x11 x12 x13 60 x21 x22 x23 100 x11 x21 50
s.t gi ( X ) 0
hi ( X ) 0
(1)
(2)
(3)
i 1,2,, m .
j 1,2,, l .
X D
其中X ( x1 , x2 ,, xn )T , D R n为可行集
f(X)为目标函数,(2)、(3)为约束条件, (2)为不等式约束,(3)为等式约束; 若只有(1)称为无约束问题。
max f x1 x2 15 x1 12 x2 85 如 5 x1 11 x , x 0 1 2 x1 , x2 为整数
第5章 用例图
![第5章 用例图](https://img.taocdn.com/s3/m/b1de0fe95ef7ba0d4a733b51.png)
5.3 用例(Use Case)
描述用例 8.假设[可选]:假设描述的是系统在使用用例之前必须 满足的状态,这些条件并没有经过用例的检测,用 例只是假设它们为真。 9.基本操作流程:参与者在用例中所遵循的主要逻辑 路径。操作流程描述了用户和执行用例之间交互的 每一步。 10.可选操作流程:包括用例中很少使用的逻辑路径, 那些在变更工作方式、出现异常或发生错误的情况 下所遵循的路径。 11.修改历史记录[可选]:主要记录的是关于用例的修 改时间、修改原因和修改人的详细信息。
扩展关系也是一种依赖关系。 它指定了一个用例可以增强另一个用例的功 能,通过项基本用例添加动作来扩展该用例。 一个用例被定义为基本用例的增量扩展,这 称作扩展关系。 在扩展关系中,基本用例可以是独立的。在 一定条件下,基本用例的动作可由另外一个 用例扩展而来。基本用例提供了若干“扩展 点”,扩展用例只能在这些扩展点上增加一 个或多个新的动作。也就是说,扩展用例只 能发生在基本用例序列中的某个特定的点上。
用例的表示
在UML语言中,用例用一个椭圆来表示,并
且每个用例必须有一个名字。 在用例命名时用例的名字一般用字符串来表 示,可分为简单名和路径名。其中,路径名 引入了包的概念,在用例名前加上该用例所 属包的名字,两个名字之间用两个冒号分开。
AddBook
Libraian::LoanBook
5.3 用例(Use Case)
5.3 用例(Use Case)
描述用例 5.频率:记录参与者使用该用例的频率。 6.前置条件:前置条件以一个条件列表的形式进行记 录,用来描述执行用例之前系统所必须满足的条件。 这些条件必须在使用用例之前得到满足。前置条件 在使用之前,已经由用例进行过测试。如果条件不 满足,则用例不会被执行。 7.后置条件:后置条件将在用例成功完成以后得到满 足,它提供了系统的部分描述。即在前置条件满足 后,用例做了什么?以及用例结束时,系统处于什 么状态?
第5章 用例图
![第5章 用例图](https://img.taocdn.com/s3/m/45995e280066f5335a81214d.png)
特定参与者希望系统提供什么功能; 系统是否存贮和检索信息,如果是,由哪个参与者触发; 当系统改变状态时,是否通知参与者; 是否存在影响系统的外部事件; 哪个参与者通知系统这些事件。
-11-
made by cnHexu
第5章 用例图
5.1.3 用例
3.用例与事件流 用例分析处于系统需求分析阶段,需要更加具体的细节, 这些细节写在事件流文件中。 事件流的目的:
第5章 用例图
5.1.2 参与者
2 .确定参与者 对参与者建模的过程中需要注意的问题
参与者对系统而言总是外部; 参与者可以直接或间接地同系统交互,或使用系统提供的服务 以完成某件事务; 参与者表示人和事物与系统交互时所扮演的角色,而不是特定 的人或特定的事物; 一个人或事物在与系统发生交互时,可以同时或不同时扮演多 个角色; 每一个参与者需要一个具有业务一样的名字; 每个参与者必须有简短的描述; 参与者可以具有表示参与者的属性和可以接受的事件。
-3-
made by cnHexu
第5章 用例图
5.1.2 参与者
1.参与者的概念 参与者是系统外部的一个实体,以某种形式参与用例的执行过程。 参与者通过向系统输入或请求系统输入某些事件来触发系统的执 行。 每个参与者可以参与一个或多个用例 表示:
人形图
-4-
made by cnHexu
2.确定参与者 如何寻找系统的参与者
谁将使用系统的主要功能; 谁将需要该系统的支持以完成其工作; 谁将需要维护、管理该系统,以保持该系统处于工作状态; 系统需要处理哪些硬件设备; 与该系统交互的是什么系统; 谁或什么系统对本系统产生的结果有兴趣。
第五章 Subdivision(细分曲面)建模
![第五章 Subdivision(细分曲面)建模](https://img.taocdn.com/s3/m/5bc94e384b73f242336c5fc1.png)
第六节 Subdiv Surfaces(细分曲面)的编辑工 具
Subdivision物体的编辑 方式可以使用多变形代 理的编辑模式,因此可 以使用多边形的编辑工 具进行编辑。但是针对 一些细分物体的特殊性 Maya软件在Subdiv Surface菜单中补充了一 组针对细分物体的编辑 工具,
第七节 创建“卡通玩具”模型
第二节
细分建模简介
细分表面是结合了NURBS建模和多边形建模很 多优点的混合表面。我们在制作中可以通过两 种途径得到细分曲面物体,创建后的物体能在 标准模式和多边形替代物模式之间切换编辑。 细分曲面的最大优点就是其分层级管理,能够 创建不断提高的细节层次,并且在建模的过程 中可以在高低级别见自由的切换。我们所学的 三种建模方式各有优缺点,我们可以通过掌握 其各自的特性来取长补短。
第四节 Subdiv Surfaces(细分曲面) 原始物体的创建
创建Subdiv Surfces(细分表面)物体可以通过 两种途径创建:一种是从菜单栏内Create(创建) >Subdiv Primtives(细分基本几何体)中创建细 分表面的基本物体。另外一种是用polygon或 NURBS物体创建基本形状,再使用菜单栏内 modify(修改)>convert(转换)>polygons to Subdiv或NURBS to Subdiv转成细分物体,转换 后可以对物体继续进行编辑。
第三节 Subdiv Surfaces(细分曲面)的特点
在 Maya 中细分曲面建模代表了一种全新的建模方式,同时具备NURBS 和多边形建 模的优势。细分曲面建模提供如下优于传统的 NURBS 或多边形建模的功能特点: 1.细分曲面可以象NURBS表面一样的光滑,实际上,Maya 的细分曲面与3 度均匀 的B-spline 曲线表面一样平滑(NURBS 表面的一个子集)。细分曲面与多边形表面不同,当用 户近距离观察时,细分面看上去没有细小面。 2、细分曲面可以是一个整体,不用象NURBS建模一样,使用面片缝合等技术,不 用担心表面的连续性和接缝等问题。 3、细分曲面可以象Polygon一样任意的拓扑,可以任意连线。不象NURBS表面一样 一定要四边形。它产生自一个任意拓扑的Polygon网格。这个Polygon网格就是它的 Base Mesh(基本网格),控制着细分表面的大型,在Maya里,你可以在使用任意 的Polygon建模工具对这个基本网格进行编辑。 4、细分曲面建模速度快。用户可以很快地设计一个粗略的多边形形式,将此形式转 换到一个平滑细分面,然后对所要求细节进行操作,而不必担心缝合和连续性。 5、细分曲面可以只在需要细节的部位执行细分操作增加顶点,以便编辑更多的细节。 这样可以让模型尽量减少不必要的顶点,即减轻了系统的运算负担,又保证了模型 的精细度。
第5章 对象建模
![第5章 对象建模](https://img.taocdn.com/s3/m/8b84f1d3ce2f0066f5332297.png)
第5章 对象建模
1. 2.
3.
4. 5. 6.
7.
第5章是软件开发生命周期的系统分析阶段4章中的第3章。这一章讨论 对象建模技术,它可以帮助分析员创建逻辑模型。除了结构化分析以外, 面向对象的分析是另外一种表示和设计信息系统的方法。 学习目标 完成本章学习后,将了解以下内容: 解释如何使用面向对象分析来描述信息系统。 定义对象建模术语和概念,包括对象、属性、方法、消息、类和实例。 解释对象之间的关系和继承的概念。 绘制对象关系图。 描述统一建模语言(UML)工具和技术,包括用例、用例图、类图、顺序 图、状态转换图和活动图。 解释用CASE工具开发对象模型的优点。 阐述如何组织对象模型。
5.1.3 属性
若对象类似于名词的性质,那么属性就是类似于描述对象特征的形容词。 一个对象到底需要多少属性呢?答案取决于信息系统及其用户的业务需 求,即便是一个相对而言比较简单的对象,例如某项库存商品,也可能 需要部件编号、描述、供应商、现有数量、最低库存水平、最高库存水 平、订单时间等比较多的属性。 有些对象只需要很少的属性,而有些可能需要许多。 系统分析员在系统设计处理期间定义了对象的属性。 在面向对象的系统中,一个对象可以从其他对象继承或获取属性,当学 习了对象和类之间的关系之后就会了解继承是如何发生的。 对象的特定属性称作状态,对象的状态就是描述该对象当前情形的形容 词。 例如学生可能是将来的学生、当前的学生或者过去的学生,具体情况取 决于状态。 同样一个银行账户可能是已经使用的、尚未使用的或者被冻结的。
第5章-系统建模.
![第5章-系统建模.](https://img.taocdn.com/s3/m/678e369c8762caaedd33d424.png)
Actor之间的关系
执行者可以详细的泛化其他执行者:
用例模型-执行者
获取执行者(角色)
谁使用系统的主要功能(主要使用者)? 谁需要系统支持他们的日常工作? 谁来维护、管理系统使其能正常工作(辅助使用 者)? 系统需要控制哪些硬件? 系统需要与其他哪些系统交互? 对L统一建模语言
面向对象建模的标准建模语言。 活动图 用例图 时序图 类图 状态图
图形建模的用途
为讨论现有系统或提出新功能的系统提供 便利 论证现有系统 作为详细的系统描述,该描述可用来产生 系统实现
5.1 上下文模型
上下文模型用来描述一个系统的运行环境。 用它来界定系统的边界。 应该在过程的早期阶段完成这些判断,以 便限制系统成本以及分析系统需求和设计 中需要花费的时间。
5.2.1 用例模型
用例模型被用来支持需求导出。它是UML中 的模型图之一。 用例,参与者,关系
每一个用例表示一个具体的任务 参与者可能是人,也可能是其他系统
传输数据用例
A use case in the MHC-PMS
用例“传输数据”的表格描述
MHC-PMS: 传输数据 参与者 描述 分诊医生,病人记录系统 (PRS) 分诊医生会将数据从MHC-PMS系统传递给更通用的病人记录数据 库,该数据库由卫生主管部分维护。信息传递也许是更新个人信 息,也许是简短记录病人的诊断和诊治
UML是一种定义良好、易于表达、功能强大 且普遍适用的建模语言。它的作用域不限 于支持面向对象的分析与设计,还支持从 需求分析开始的软件开发的全过程。 在美国,截止1996年10月,UML获得了工业 界、科技界和应用界的广泛支持,已有700 多个公司表示支持采用UML作为建模语言。 1996年底,UML已稳占面向对象技术市场的 85%,成为可视化建模语言事实上的工业标 准。1997年11月17日,OMG采纳UML 1.1作 为基于面向对象技术的标准建模语言。
第05章 产品建模技术基础
![第05章 产品建模技术基础](https://img.taocdn.com/s3/m/3f7c236a783e0912a2162a66.png)
3.实体建模
原理
象限编 码 节点 部分有 1 2 有 4 3 无 物体 层0 层1 层2
层3
(a) 四叉树结构表示二维图形
节点 4 8 4 3 7 象 13 3 7 限 2 2 6 编 码 部分有 有 无 层0 层1 层2
物体
(b) 八叉树结构表示三维图形
特点: 易于局部修改、计算量非常小,但是存贮量非 常大。
3.实体建模
3.3.5 空间扫描表示法 A)平移扫描法
运动轨迹 (任意曲 线) 母线(封闭曲 线) 回转轴线
B)旋转扫描法
母线 (封闭曲线)
特点: 只有二维集合;
计算量与存贮量小;
3. 实体建模
3.4 CSG--构造实体几何表示法 3.4.1 CSG树 根、节点、树叶
C E A B - ∪ C A (A+B)-C B B (B-C)+A C - A D (D-E)-C E ∪ C D (D-C)-E C - - E D C -
2. 三维几何建模的模式
线框模型 wireframe model 表面模型 surface model *实体模型 solid model
2. 三维几何建模的模式
2.1 三维线框模型 wireframe model 2.1.1 原理
P12 K11 K1 P5
点和棱线
K 体
P11 K10 K1 K2 K3 K4 K5 K6 K18 边
1. 几何建模概述
1.1 交互式CAD/CAM系统的工作原理
与问题无关 任务处理 与问题有关 交互软件
计算机的内部表示
程序库与数据库
1. 几何建模概述
1.2 几何建模的概念 模型Model:数据、结构和算法的集合 计算机的内部表示 建模Modeling:描述、表达和存贮模型的过程 几何建模Geometric Modeling:将现实世界的几何实 体转化为计算机内部表示的模型。 造型技术:研究如何在计算机中建立恰当的模型表 示物体的技术。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
2020/11/1 U M L 建 模 实 例 教 程
6
5.1 用例模型概述
引入用例的目的
(1)确定系统应具备哪些功能,这些功能是否满足系统的需求(开 发者与用户协商达 成共识的东西)。
(2)为系统的功能提供清晰一致的描述,以便为后续的开发工作打 下良好的交流基础,方便开发人员传递需求的功能。
(3)为系统验证工作打下基础。通过验证最终实现的系统能够执行 的功能是否与最初需求的功能相一致,保证系统的实用性。
2020/11/1 U M L 建 模 实 例 教 程
5
5.1 用例模型概述
用例模型的基本组成
用例模型的基本组成部件是用例、参与者和系统。 用例用于描述系统的功能,也就是从外部用户的角度观察系统应具备 哪些功能,帮助分析人员理解系统的行为,它是对系统功能的宏观描 述。一个完整的系统中通常包含若干个用例,每个用例具体说明应完 成的功能,代表系统的所有基本功能(集)。 参与者是与系统进行交互的外部实体,它可以是系统用户,也可以是 其它系统或硬件设备,总之,凡是需要与系统交互的任何东西都可以 称作参与者。 系统的边界线以内的区域(即用例的活动区域)则抽象表示系统能够 实现的所有基本功能。
2020/11/1 U M L 建 模 实 例 教 程
11
5.2.1 参与者
确定WebShop参与者
确定WebShop电子商城中的参与者主要是用户,而用户又包括前台购物 用户和后台管理员两大类;后台管理员又包括普通管理员和系统管理员 两大类。
2020/11/1 U M L 建 模 实 例 教 程
12
2020/11/1 U M L 建 模 实 例 教 程
14
5.2.3 用例
什么是用例
用例是Jacobson在面象对象的软件工程中提出的,但它实际上是独立于 面象对象的。 用例代表一个系统或系统的一部分行为,是对一组动作序列的描述,系 统执行该动作序列来作为参与者产生一个可观察的结果值。 用例代表的是一个完整的功能。UML中的用例是动作步骤的集合。动作 是系统的一次执行L 建 模 实 例 教 程
10
5.2.1 参与者
确定参与者
(1)使用系统主要功能的人是谁(即主要角色)? (2)需要借助于系统完成日常工作的人是谁? (3)谁来维护和管理系统(次要角色),保证系统正常工作? (4)系统控制的硬件设备有哪些? (5)系统需要与哪些其它系统交互?其它系统包括计算机系统, 也包括该系统将要使用的计算机中的其它应用软件。其它系统也 分成二类,一类是启动该系统的系统,另一类是该系统要使用的 系统。 (6)对系统产生的结果感兴趣的人或事是哪些?
购物用户注册帐号 购物用户登录系统 购物用户查看个人资料 购物用户查看历史订单 购物用户查看当前订单 购物用户关闭帐号 系统管理员删除用户
9
5.2.1 参与者
参与者概述
(1)系统用户 (2)其他系统 (3)一些可以运行的进程
参与者(Actor)是与系统交互的人 或事。所谓“与系统交互”指的是 参与者向系统发送消息,从系统中 接收消息,或是在系统中交换信息。 UML中用一个小人形图形表示角色 类,小人的下方书写角色名字。
2020/11/1 U M L 建 模 实 例 教 程
7
任务2
任务目标 确定WebShop电子商城系统中的参与者、系统边界。
教学方法
分组教学法 SDSPR教学法 案例教学法
2020/11/1 U M L 建 模 实 例 教 程
8
5.2 用例图组成
WebShop用例图
2020/11/1 U M L 建 模 实 例 教 程
UML建模 实例教程
第5章 需求建模
刘志成 编著
1
本章学习导航
本章学习导航
2020/11/1 U M L 建 模 实 例 教 程
2
本章学习要点
用例模型概述 用例图组成 识别和描述用例 用例间的关系
建议课时:10课时
2020/11/1 U M L 建 模 实 例 教 程
3
任务1
任务目标 了解用例模型的基本功能和基本组成 。
2020/11/1 U M L 建 模 实 例 教 程
13
5.2.2 系统
用例模型中的系统
系统是用例模型的一个组成部分,代表的是一部机器或一个商务 活动等,而并不是真正实现的软件系统。系统的边界用来说明构建 的用例模型的应用范围。 先识别出系统的基本功能(集),然后以此为基础定义一个稳定 的、精确定义的系统架构,以后再不断地扩充系统功能,逐步完善。 这样做的好处在于避免了一开始系统太大,需求分析不易明确,从 而导致浪费大量的开发时间。 用例图中的系统用一个长方框表示,系统的名字写在方框上或方 框里面,方框内部还可以包含该系统中的用符号表示的用例。
2020/11/1 U M L 建 模 实 例 教 程
15
5.2.3 用例
用例的特征
用例总是由参与者初始化 用例为参与者提供值 用例具有完全性
【提示】 用例表示的也是一个类(如搜索图书),而不是某个具体的实例(搜 索名称为“Java程序设计”的图书)。 用例描述了它代表的功能的各个方面,也就是包含了用例执行期间可 能发生的种种情况。
教学方法
分组教学法 资料查询法 案例教学法
2020/11/1 U M L 建 模 实 例 教 程
4
5.1 用例模型概述
用例模型的功能
用例模型是把应满足用户需求的基本功能(集)聚合起来表示 的强大工具。 对于正在构造的新系统,用例描述该系统应该作什么;对于已 构造完毕的系统,用例则反映了系统能够完成什么样的功能。 构建用例模型是通过系统开发者与系统的客户(或最终使用者) 共同协商完成的,他们要反复讨论需求的规格说明,达成共识, 明确系统的基本功能,为后阶段的工作打下基础。
5.2.1 参与者
参与者说明
参与者对于系统而言总是外部的,它们可以处于人的控制之外; 参与者可以直接或间接地同系统交互,或使用系统提供的服务以 完成某件事务; 参与者表示人或事物与系统发生交互时所扮演的角色,而不是特 定的人或者特定的事物; 一个人或事物在与系统发生交互时,可以扮演多个角色; 每一个参与者需要一个具有业务一样的名字,并且必须有简短的 描述(从业务角度描述参与者是什么); 参与者可以具有属性和事件,但使用不能太频繁。