第5章 需求建模方法与技术

合集下载

第五章结构化分析与建模

第五章结构化分析与建模

结构化分析模型

系统模型从以下不同的角度表述系统:


从外部来看,它是对系统分析上下文或系统环境建模; 从行为上看,它是对系统行为建模; 从结构上看,它是对系统的体系结构和系统处理的数 据结构建模。
系统行为模型:


结构化的需求分析模型有:

数据流模型,用来描述系统中的数据处理过程。 状态转换模型,用来描述系统如何对事件做出响应。

数据流图举例
假设我们要开发一个学生管理系统。 其中开发小组通过进行进一步的需求调查,明 确了该系统的主要功能是进行学籍管理,包括 学生报到、入学、毕业的管理,学生上课情况 的管理。 通过详细的信息流程分析和数据收集后,生成 了该子系统的数据流图。
将0层 DFD中的加工“1.0报到”分解成1层DFD中的3个子 加工:“ 1.1 核对录取通知书”、“ 1.2 核对体检结果”和 “1.3同意入学”。保留0顶层DFD加工边界中的7个数据流。 随着加工的分解,新增两个数据流“已核对的录取通知书” 和“已核对的体检结果”。


数据流图举例:飞机机票预订系统:旅行社把预订机票的旅客信 息输入机票预订系统。系统为旅客安排航班,打印出取票通知单 (附应交的帐款)。旅客在飞机起飞的前一天凭取票通知等交款 取票,系统检验无误,输出机票给旅客。
旅行社
订票单 分类并检查
有效订票单 订票
航班 取票单 有效取 票单 记账文件 机票准备 账单 记账 取票通知单 航班目录
旅客
机票
机票文件
旅行社
数据流图举例(分层)


设一个工厂采购部每天需要一张定货报表。定货 的零件数据有:零件编号、名称、数量、价格、 供应者等。零件的入库、出库事务通过计算机终 端输入给定货系统。当某零件的库存数少于给定 的库存量临界值时,就应该再次定货。 数据流分析:

软件工程复习资料

软件工程复习资料

第一章绪论什么是软件工程?软件=程序+数据+文档什么是软件危机?软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件,从而导致软件开发与维护过程中出现一系列严重问题的现象。

什么是软件工程?采用工程化的原理和方法对软件进行计划开发和维护。

软件工程三范型:1.过程式编程范型2.面向对象编程范型3.基于构件技术的编程范型软件工程的发展时期:(1)传统软件工程或者经典软件工程:开发过程:结构化分析一>结构化设计一>面向过程的编码一>软件测试(2)面向对象软件工程开发过程:OO分析与对象抽取一》对象详细设计一》面向对象编码与测试(3)基于构件的软件工程:以软件复用为目标、领域工程为基础,其开发过程一般包括包括以下阶段:领域分析和测试计划定制一一》领域设计一一》建立可复用构件库一一》按“构件集成模型,,查找与集成构件第二章生存周期什么是软件生存周期?计划阶段:需求分析,软件分析开发阶段:软件设计,编码(测试)软件测试维护阶段:运行维护模型特点和使用场合可行性研究1.经济可行性2.技术可行性3.运行可行性4.法律可行性第三章结构化分析与设计结构化程序设计的特点以及论述(1)整个程序的模块化(2)每个模块只有一个入口和出口(3)每个模块都应能单独执行,且无死循环(4)采用自顶向下,逐步细化的方法SA结构化分析设计(结构化)从内容分:1.系统结构设计2.接口设计3.数据设计4.过程设计按照步骤分:1.概要设计2.详细设计第四章OO与面向对象+UML OO的特征1.抽象2.封装3.继承4.多态为什么用面向对象1.符合人类习惯的思维方式2.提高软件系统的可复用性3.提高软件系统的可扩展性4.提高软件系统的可维护性UML相关知识静态图1.用例图:描述系统功能2.类图:描述系统的静态结构3.对象图:描述系统在某个时期的静态结构4.构件图:描述实现系统的元素的组织5.部署图:描述系统环境元素的配置动态图1.状态图:描述系统元素的状态条件和相应2.时序图:按照时间顺序描述系统元素间的交互3.协作图:按照连接关系描述系统元素间的交互4.活动图:描述系统元素的活动流程第五章需求建模需求分析的步骤1.需求获取2.需求建模3.需求描述4.需求验证面向对象需求建模1.画用例图2.写用例规约3.描述补充规约4.编写术语表第六章需求分析面向对象的需求分析1.边界类:边界类提供了对参与者或外部系统交互协议的接口。

面向数据流的分析方法

面向数据流的分析方法

⾯向数据流的分析⽅法外部实体位于软件系统边界之外的信息⽣产者或消费者转换变换数据流的处理过程,⼜称泡(bubble )为⼀个或多个转换提供数据源或数据存储服务的缓冲区、⽂件或数据库数据存储在转换之间定向流动的数据项或数据项集合第5章⾯向数据流的分析⽅法⾯向数据流的分析⽅法(dataflow-oriented analysis method )与⾯向对象、⾯向数据的分析⽅法,都是需求建模⽅法。

它们均有⼀组规范的语⾔表达机制,需求分析⼈员⽤来表达⽤户需求、构造软件系统模型。

此外,它们还含有⼀些规则和经验知识,指导分析⼈员提取需求信息,促进⽤户需求精确化、完全化和⼀致化。

⾯向数据流的分析⽅法是结构化分析⽅法系列中的⼀⽀,具有明显的结构化特征。

结构化分析⽅法的雏形出现于20世纪60年代后期。

但是,直到1979年才由DeMarco 将其作为⼀种需求分析⽅法正式提出。

由此,结构化分析⽅法得到了迅速发展和⼴泛应⽤。

本章主要介绍⼴为使⽤的⾯向数据流的分析⽅法及其需求分析CASE ⼯具。

5.1 数据流图与数据字典⼀个基于计算机的信息处理系统就是对数据流进⾏⼀系列加⼯的处理过程,⽽这些加⼯将输⼊数据流变换为输出数据流。

数据流图就是⽤来刻画数据流和加⼯的信息系统建模技术。

数据字典是与数据流图配套使⽤的,⽤来定义系统中数据元素的有机集合体。

5.1.1 数据流图数据流图(Data Flow Diagram ,DFD )描述输⼊数据流到输出数据流的转换(即加⼯),⽤于对系统的功能建模。

1.数据流图的基本图形元素数据流图中的基本图形元素包括:数据流、转换、数据存储以及外部实体,如图5-1所⽰。

数据流、转换、数据存储⽤于构建软件系统内部的数据处理模型;外部实体表⽰存在于系统边界之外的对象,⽤来帮助我们理解软件系统数据的来源和去向。

图5-1 数据流图的基本图形元素需要说明的是,DFD 图形元素还可以⽤其他描述符号来表⽰,如⽤圆⾓矩形表⽰转换,⽤开放箭头表⽰数据流等。

软件工程 第5章--UML

软件工程 第5章--UML
10
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 种视图,各 视图在静态和动态方面表示系统模型。
结构 视图 静态 方面
动态 方面
行为 视图 同左
实现 视图 构件图
环境 视图 部署图
同左
用例 视图 用例图
同左
类图 对象图
顺序图 同左 顺序图 合作图 (注重 合作图 状态图 进程、 状态图 活动图 线程) 活动图

(完整版)软件工程 第五章 面向对象的需求分析

(完整版)软件工程 第五章 面向对象的需求分析

第五章面向对象的需求分析面向对象的需求分析方法的核心是利用面向对象的概念和方法为软件需求建造模型。

它包含面向对象风格的图形语言机制和用于指导需求分析的面向对象方法学。

面向对象的思想最初起源于 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章)

作业二结构化需求建模(第5章)2-1、简答业务流程图与数据流程图的作用、含义和区别2-2、目前住院病人主要由护士护理,这样做不仅需要大量护士,而且由于不能随时观察危重病人的病情变化,还会延误抢救时机。

某医院打算开发一个以计算机为中心的患者监护系统,请分层次地画出描述本系统功能的数据流图。

医院对患者监护系统的基本要求是随时接收每个病人的生理信号(脉搏、体温、血压、心电图等),定时记录病人情况以形成患者日志,当某个病人的生理信号超出医生规定的安全范围时向值班护士发出警告信息,此外,护士在需要时还可以要求系统印出某个指定病人的病情报告。

2-3、银行计算机储蓄系统的工作过程大致如下:储户填写的存款单或取款单由业务员键入系统,如果是存款则系统记录存款人姓名、住址(或电话号码)、身份证号码、存款类型、存款日期、到期日期、利率及密码(可选)等信息,并印出存单给储户;如果是取款而且存款时留有密码,则系统首先核对储户密码,若密码正确或存款时未留密码,则系统计算利息并印出利息清单给储户。

请用数据流图描绘本系统的功能,并用实体-联系图描绘系统中的数据对象。

2-4、为了方便旅客,某航空公司拟开发一个机票预定系统。

旅行社把预定机票的旅客信息(姓名、性别、工作单位、身份证号码、旅行时间、旅行目的地等)输入该系统,系统为旅客安排航班,旅客在飞机起飞前一天凭取票通知和账单交款取票,系统核对无误即印出机票给顾客。

请画出描述本系统功能的数据流图。

2-5、复印机的工作过程大致如下:未接到复印命令时处于闲置状态,一旦接到复印命令则进入复印状态,完成一个复印命令规定的工作后又回到闲置状态,等待下一个复印命令;如果执行复印命令时发现没纸,则进入缺纸状态,发出警告,等待装纸,装满纸后进入闲置状态,准备接收复印命令;如果复印时发生卡纸故障,则进入卡纸状态,发出警告等待维修人员来排除故障,故障排除后回到闲置状态。

请用状态转换图描绘复印机的行为。

软件工程中的需求分析与建模

软件工程中的需求分析与建模

● 03
第3章 需求建模技术
需求建模概述
需求建模是软件工程中的一个重要环节,通过对需求 进行建模,可以更清晰地理解和定义系统需求。需求 建模的目的是为了准确地捕获用户需求,确保软件开 发过程中不会遗漏任何重要需求。同时,需求建模还 可以帮助团队更好地沟通和协作,提高项目的成功率。
用例建模
用例是描述系统功能的一种有效方式。通过用 例建模,可以清晰地定义系统的功能和用户与 系统之间的交互。用例图可以直观地展示系统 的功能和不同用户角色之间的交互关系。用例 描述则详细描述了每个用例的具体行为和步骤。
意度。
需求变更频繁
导致开发过程混乱
需求不明确
影响产品质量
沟通不畅
导致需求误解
面临的挑战
可能的改进方向
采用敏捷开发模式
迭代开发 持续集成 快速反馈
加强需求管理
建立需求数据库 制定明确需求文档 实施变更控制
提高沟通效率
定期沟通会议 使用协同工具 建立需求反馈渠道
展望未来
未来在软件工程领域,人工智能技术的发展将为需求 分析带来更多可能性,大数据技术的应用将提升需求 建模的精度,需求管理工具的不断创新将提高团队效 率。
测试
单元测试 集成测试
软件工程发展历程
软件工程的发展经历了多个阶段,从最初的混沌时期 到逐渐建立起规范的软件开发流程和方法。随着科技 的不断进步,软件工程也在不断演变和完善。
● 02
第二章 需求分析基础
需求分析概述
需求分析是软件工程中至关重要的一部分,它 涉及定义、识别和规范软件开发项目中的需求。 通过需求分析,可以确保开发团队在项目开始 阶段清晰了解客户的需求,明确目标和方向。 需要对需求进行系统性的分析,以确保最终的

《软件工程实用教程》第5_章_面向对象的需求分析

《软件工程实用教程》第5_章_面向对象的需求分析

第5 章 面向對象的需求分析
5.2.2 封裝、繼承和多態
1.封裝 封裝是指把對象的外部特徵與內部實現細節分開,使 得一個對象的外部特徵對其他對象來說是可訪問的, 而它的內部細節對其他對象是隱蔽的。 對象具有封裝性的條件如下: (1) 有一個清楚的邊界,所有私有數據和操作的代碼都被 封裝在這個邊界內,從外面看不見更不能訪問; (2) 有確定的介面,這些介面描述這個對象和其他的對象 之間相互的作用; (3) 受保護的內部實現,這個實現給出了由軟體對象提供 的功能的細節,實現細節能在定義這個對象的類的外 面訪問。
第5 章面向對象的需求分析
通過在不同程度上運用抽象原則(忽略事物 之間的一些差異),可以得到較一般的類和 較特殊的類。特殊類繼承一般類的屬性和操 作,面向對象方法支持這種繼承關係的描述 與實現,從而簡化系統的構造過程及其文檔; 複雜對象可以用簡單的對象作為其構成部分 (稱為聚合); 對象之間通過消息進行通信,以實現對象之 間的動態聯繫; 通過關聯表達對象之間的靜態關係。
第5 章面向對象的需求分析
5.1.3 面向對象方法的優點 1. 與人們習慣的思維方法一致 2. 可使軟體系統結構更加穩定 3. 軟體具有更好的可複用性 4. 軟體更加便於維護與擴充
第5 章面向對象的需求分析
5.1.4 面向對象建模
用例模型:包含所有用例及其與用戶之間的關係; 對象模型:包含問題域涉及的類及其屬性和關係,其 作用是更詳細地提煉用例,將系統的行為初步分 配給提供行為的一組對象; 設計模型:將系統的靜態結構定義為子系統、類和介 面,並定義由子系統、類和介面之間的協作來實 現的用例; 實現模型:包含構件和類到構件的映射; 配置模型:定義電腦的物理節點和構件到這些節點的 映射; 測試模型:描述用於驗證用例的測試用例。

05 用例视图

05 用例视图
<<uses>>
Remove Reservation
即可
不管是C、R、U、D,都是为了完成“管理”目标
甚至很多种的基本数据管理都可以用一个用例表示
管理员
管理用户
要点5:用例粒度

灵活处理CRUD
<<extend>>
管理员
管理用户
增加用户
可以把包含复杂交互的路径独立出去形成用例
用例与事件流

用例分析是处于系统的需求分析阶段,这 个阶段应该尽量的避免去考虑系统实现的 细节问题。也就是说,用例描述的是一个 系统做什么,而不是怎么做。
所有业务最终对会成为 CRUD? CRUD能为Actor提供价 值? CRUD掩盖业务,锐变成 关系数据库的建模:

增加用户
修改用户

管理员
“系统就是数据的增 删改查” 关心数据的存储和维 护,反而忽略了用户 的目的
查询用户
删除用户

要点5:用例粒度

如果确实是CRUD?
如果CRUD不涉及复杂的交互,一个用例“管理××”
Actor
题外话:小人与圣小猪

参与者虽然用人形图符表示,但参与者不 局限于表示人

如果我开发一个猪圈自动供食供水系统, 猪的前蹄触发一个开关系统就供食或供水。 显然,这里的Actor 是小猪。
Pig
Turn on the switch
题外话:小人与圣小猪

如果在use case 图里用小猪代替原来的小人?
实例—图书馆管理系统中的用例 视图

确定系统涉及的内容
书籍的借阅、读者的统一管理等

确定系统的参与者

软件需求工程

软件需求工程
所谓面向对象就是应用对象类继承封装消息对象或类之间的关系等面向对象的概念对问题进行分析和求解的软件开发技术或者说是以对象类为数据中心对象之间的动态行为模式作为运行机制的一种问题求解方法
软件需求工程
第1章 软件需求工程概述 IEEE 关于软件需求的定义 1) 用户解决问题或达到目标所需的条件或能力;(用户的角度 ) 2) 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条 ቤተ መጻሕፍቲ ባይዱ或能力。(软件系统的角度 ) 软件需求的分类 1) 目标需求; 2) 业务需求; 3) 功能需求; 4) 性能需求; 5) 约束与限制。 6) 软件需求间的层次关系
复杂的软件系统的描述方法
?当前系统:已经存在的人工系统 ?目标系统:待开发的计算机系统 SA方法的分析步骤如下: 1)理解和分析当前的现实环境,以获得当前系统的具体模型。具体模型必须忠 实地反映人工系统的实际情况,软件开发人员在获得需求信息的基础上,利用DFD将现实环境中的人工系统表达出来。 2)建立当前系统的逻辑模型。从系统的具体模型中抽象出当前系统的逻辑模 型,当前系统的逻辑模型应反映当前系统必须满足的性质。 3)建立目标系统的逻辑模型。主要是分析目标系统与当前系统在逻辑系统的差 别,并建立目标系统的逻辑模型。 4)进一步完善目标系统的逻辑模型,完善的工作大致为: ①至今尚未说明的处理细节,如出错处理 ②某些需要的输入/输出格式或用户界面的说明 ③增加性能需求和其它一些约束限制等 状态转换图 P60-图5-18、P61-图5-19 第6章需求定义 需求规格说明的作用 需求规格说明的作用主要体现在: 1)需求规格说明是软件设计和实现的基础 2)需求规格说明是测试和用户验收软件系统的重要依据 3)需求规格说明能为软件维护提供重要的信息 一个软件系统能否满足用户需求,主要是用户的需求能否全部反映在需求规格说明中。因此,需求规格说明作为需求工程的最 终成果必须具有综合性,必须包括所有的需求,开发人员与客户不能做任何假设。 除了设计和实现的限制,需求规格说明不应包括假设、构造或维护阶段的细节; 需求规格说明=技术合同,是软件开发方与用户达成的一致性文档,是基准的规格说明。

第五章 IDEF方法

第五章  IDEF方法
度(或立场)来分析,会有完 全不同的需求与结果。所谓观点问题就是要明确从哪一角度去观察问 题或者站在什么人的立场上米分析问题。 一般来说,建议站在全局负责人的立场上来建模。比如对一个企
业的CIM系统,必须有明确的站在厂长(或经理)的位置上建模的观点,
所有不同层次的作者都要以全局的观点来进行建模工作,或者说就是 为厂长而建模。这样才能保证足从全企业的高度来揭示各部分之间的 相互联系和相互制约关系,而不会偏向某个部门的局部需求。
只有清楚了上述问题,才能说对所要理解或描述的某种活动或功能 足够了,IDEF0方法正是采用简单的图形符号和简洁的文字说明描述系统 在不同层次上的上述问题的。在该方法中,将系统功能称为活动,将表 示系统功能的图形称为活动图形,在活动图形中,用方框和箭头表示系 统的各种活动及其相互之间的关系。
IDEF0 方法是用结构化分析方法建立的图形模型。其基本图形是用 盒子(box)代表功能活动,用与之相连的箭头表示与活动关联的各种事物。
5.2.3 画法和做法的若干规定 5.2.3.1 箭头画法 箭头代表活动所关联的事物,它有两大类:一类称内部箭头,它的 两端分别连到图形内两个盒子上;另一类称边界箭头,它的两端中一 端是开的,表示由图形以外的活动所产生,或由图形以外的活动所使
用。在各种不同的工作情况下箭头可有下列各种画法:
(1)箭头代表的是事物或数据,因此可以“汇流”、“分流”或“共 用”。
其编号次序是i和o从上到下c和m从左524idef实例53ideflx方法的概述用idef方法建立的系统功能模型只反映了系统功能或处理的详细内容及其逻辑关系并没有详细说明系统内部所有信息的组织结构和相互关系而cimsmis是企业的集成化管理信息系统其处理的核心是企业内部的各种信息
第5章

逆向建模与产品创新设计第5章逆向建模曲线构建技术

逆向建模与产品创新设计第5章逆向建模曲线构建技术
这种方法利用图像处理和计算机视觉技术,通过分析多视角 下的图像信息,提取出物体的轮廓线或结构线,并重建出三 维曲线模型。该方法需要使用相机标定、立体视觉等技术, 对图像质量和光照条件要求较高。
基于物理模型的曲线生成
总结词
基于物理模型的曲线生成是一种基于物理规律和动力学原理来生成曲线的方法,适用于模拟和分析动 态过程。
详细描述
这种方法根据物理规律和动力学原理,建立物体运动和形变的数学模型,通过求解方程来生成描述物 体运动轨迹的曲线。该方法常用于机械运动仿真、动画制作等领域,可以模拟复杂的动态过程和形变 。
03
逆向建模曲线构建技术的实
现步骤
数据采集与预处理
数据采集
通过各种传感器和测量 工具获取原始数据 ,如激光扫描、3D 摄影等。
在生物医学工程领域,逆向建模曲线 构建技术可用于人体解剖结构的数字 化重建,为医学研究和治疗提供帮助。
文物保护
对于历史文物和艺术品,逆向建模曲 线构建技术可以用于数字化保存和修 复,为文保工作提供技术支持。
02
逆向建模曲线构建技术的方

基于点云的曲线拟合
总结词
基于点云的曲线拟合是一种通过点云数据来拟合曲线的方法,适用于复杂曲面 重构。
数据清洗
去除异常值、缺失值和重复数据,确保数据质量。
数据转换
将原始数据转换为适合建模的形式,如点云 数据。
特征提取与模型建立
特征提取
从点云数据中提取关键特征,如曲率、方向等。
模型建立
根据提取的特征,利用数学和计算几何的方法 建立曲线模型。
模型验证
通过与实际数据的比较,验证模型的准确性和可靠性。
模型优化与结果
跨学科合作与创新
逆向建模曲线构建技术的发展需要跨学科的合作与创新,如计 算机科学、工程学、数学、物理学等领域的专家共同参与研究

第5章 用例图

第5章 用例图

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章  对象建模
是的但它们之间有很大的区别在结构化分析中我们将数据和影响数据的操作处理分开来看但对象不同它同时包含数据和操作处理在面向对象的分析中我们把添加修改或更改数据这些操作处理称作方法
第5章 对象建模


1. 2.
3.
4. 5. 6.
7.
第5章是软件开发生命周期的系统分析阶段4章中的第3章。这一章讨论 对象建模技术,它可以帮助分析员创建逻辑模型。除了结构化分析以外, 面向对象的分析是另外一种表示和设计信息系统的方法。 学习目标 完成本章学习后,将了解以下内容: 解释如何使用面向对象分析来描述信息系统。 定义对象建模术语和概念,包括对象、属性、方法、消息、类和实例。 解释对象之间的关系和继承的概念。 绘制对象关系图。 描述统一建模语言(UML)工具和技术,包括用例、用例图、类图、顺序 图、状态转换图和活动图。 解释用CASE工具开发对象模型的优点。 阐述如何组织对象模型。
5.1.3 属性




若对象类似于名词的性质,那么属性就是类似于描述对象特征的形容词。 一个对象到底需要多少属性呢?答案取决于信息系统及其用户的业务需 求,即便是一个相对而言比较简单的对象,例如某项库存商品,也可能 需要部件编号、描述、供应商、现有数量、最低库存水平、最高库存水 平、订单时间等比较多的属性。 有些对象只需要很少的属性,而有些可能需要许多。 系统分析员在系统设计处理期间定义了对象的属性。 在面向对象的系统中,一个对象可以从其他对象继承或获取属性,当学 习了对象和类之间的关系之后就会了解继承是如何发生的。 对象的特定属性称作状态,对象的状态就是描述该对象当前情形的形容 词。 例如学生可能是将来的学生、当前的学生或者过去的学生,具体情况取 决于状态。 同样一个银行账户可能是已经使用的、尚未使用的或者被冻结的。

第5章-系统建模.

第5章-系统建模.

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作 为基于面向对象技术的标准建模语言。

《软件工程概论》郑人杰版 第5章 面向对象方法与UML

《软件工程概论》郑人杰版 第5章 面向对象方法与UML
与对象进行交互; (3) 受保护的内部实现,即软件对象功能的实现细节,实现细
节不能从类外访问。
继承
• 继承。继承是一种联结类的层次模型,为类的重用提供
了方便,它提供了明确表述不同类之间共性的方法。 • 我们将公共类称为超类(superclass)、父类(father
class)、祖先(ancestor)或基类(base class),而 从其继承的类称为子类(subclasses)、后代( deslendane)或导出类(derived class)。
对象之间的交互
行为事物
(2)状态机(state machine)── 描述了一个对 象或一个交互在生存周期内响应事件所经历的状 态序列,单个类或者一组类之间协作的行为都可 以用状态机来描述。 状态机涉及到状态、变迁和活动,其中状态用圆角 矩形来表示。
对象
(2) 角色(Roles)── 一个实体的角色也可 以抽象成一个单独的对象。角色对象的操 作是由角色提供的技能。
• 例如,一个面向对象系统中通常有“管理器”对象,它履 行协调系统资源的角色。一个窗口系统中通常有“窗口管 理器”对象,它扮演协调鼠标器按钮和其他窗口操作的角 色。特别地,一个实际的物理对象可能同时承担几个角色 。
清晰,容易掌握使用。 (6)与编程语言的关系
支持UML的一些CASE工具(如Rose)可以根据 UML所建立的系统模型自动产生Java、C++ 等代 码框架。
UML的基本模型
➢ UML符号为开发者或开发工具使用这些图形符号 和文本语法为系统建模提供了标准。 ➢ 这些图形符号和文字所表达的是应用级的模型, 在语义上它是UML元模型的实例。 ➢UML模型由事物、关系和图组成 。
第5章 面向对象方法与UML

arena中文教程第5章

arena中文教程第5章

第5章详细作业建模在第四章里展示了用“基本操作”面板里的模块可以创建的模型种类。

这些模块都是一些相对高层而且容易使用的模块,但离建立足够详细的模型还有很长的距离。

有时这些高层模块对读者们来说已经足够了。

但有时还不行。

在建模获得一些经验、所建模型越来越大、越来越复杂、越来越详细时,可能会发现需要对较低层的、更详细的、或者与“基本操作”面板的模块所提供的对象不同的事物进行控制或者建模。

Arena不会让你被迫接受这些固定的建模构件,也不会强迫你为考虑模型的各个方面而不得不学习一门编程语言或编程语法。

相反地,它提供了几个不同的建模层次,从而为建立一些特殊逻辑结构的模型提供了较大灵活性。

一种好的办法就是从高层模块开始,它们能走到哪儿你就建到哪儿(可能自始至终就是一层)。

当你需要比它们更高的灵活性时,就到更低、更详细的层次中去。

这种结构允许你随意开发容易的高层建模结构,也允许你在需要的时候到低层建模。

标准的Arena提供了所有这些建模能力,你能熟练掌握它们的用法。

这一章探讨了一些(当然不是所有)在“高等操作”(Advanced Process)面板和“操作块”(Block)面板中包含的低层详细建模构件;后一种面板提供了最底层的建模逻辑,其中的模块与作为Arena基础的SIMAN仿真语言中的程序块一致。

这里我们采用的例子是一个很复杂的汽车修理与维护车间的模型。

我们也会谈到一点非平稳(时间相关)到达过程,模型调试,以及更高层的动画定制等重要问题。

5.1节中给出了这个系统的描述,5.2节讨论了如何用一些新的Arena建模概念对这个系统建模,5.3节描述了一些基本的建模策略,5.4节给出了模型逻辑,5.5节讨论了模型调试问题,5.6节给出了一些调整动画细节的方法,以得到一些非标准的效果。

在5.7和5.8节,我们对模型进一步完美化,并提出了几种新的Arena建模概念。

在5.9节,我们向你展示了如何修改原始模型,以创造出更精美的模型。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

各队成绩
GDCJ
队名+ 总分+ 1{运动员号+ 项目名+ 成 绩+ 破记录}n
2014-3-30
31
(2)汇总后的数据项
数据项名 项目名 姓名 运动员号 破记录 成绩 总分
值 字符串 字符串 1~ 4999 1|0 0 ~ 999 正整数
位数 8 4 4 1 3 4
2014-3-30
32
(3)文件条目
2014-3-30
22
5.3.2 SA方法的描述手段
① 根据报名要求查询收费标准文件,确定相应费 用。 ② 学生注册 ③ 根据选修课程登录课程统计文件 ④ 产生注册单等
最后,由所有的数据条目、文件条目和加 工条目就构成一本数据词典。
2014-3-30
23

数据字典要求对数据元素(尤其是其结构)的描述 要精确、严格和明确
2014-3-30
38
(2)建立当前系统的逻辑模型;
当前系统的逻辑模型应反映当前系统必须满足的性 质,即当前系统“做什么”。此步的作用在于除去具体模 型中非本质因素或一些“具体”因素。
2014-3-30
39
(3)建立目标系统的逻辑模型; 主要是分析目标系统与当前系统在逻辑系统的差别, 并建立目标系统的逻辑模型。 其具体步骤如下: 首先,确定当前系统逻辑模型的“改变范围” 。此步 就是沿着当前系统逻辑模型的底层DFD,逐个检查每个基本 加工。如果该加工在目标系统中不能实现或包含“具体”因 素时,则这个加工属于改变的范围。这样,当前系统的逻辑 模型变成了不需改变和需改变两个部分。当把需改变的部分 进行修改后,就可获得目标系统的逻辑模型。 其次,把“改变范围”视为一个加工,并确定此加工的 输入/出数据流,当该加工比较抽象时,可将其进行逐层分 解,然后画出各层的DFD。 另一种方法是,首先建立目标系统的顶层DFD(0层)和 第一层DFD(由若干子系统组成),然后再参照当前系统的 逻辑模型,去掉其中所有“具体”因素和细化各子系统,最 后可得到目标系统的逻辑模型。
@
**
数据存储的标识符(关键 Student=@ID+Name+... 字)
注释 Area_No=3{Number}4**区号为3到4 位数字
24
2014-3-30
5.3.3 实例说明
某学校拟开发一个运动会管理系统。有关运动会的业务 流程如下: (1)确定运动会的举办时间和地点,设臵哪些项目,报名时 间等。 (2)确定一些限制规定,如每人最多可参加几个项目,每个 项目每队最多可由多少人参加, 取前几名,打破单项比 赛记录后的处理等。 (3)由各参加队提供报名单后,需给每个运动员编号,并统 计每个项目的参加人数及名单,最后根据每个项目的参 加人数等具体情况排出比赛日程。 (4)在运动会期间不断接受各项目的比赛成绩,及时公布单 项名次,累计团体总分。 (5)比赛结束后,公布最终的团体名次。
2014-3-30
7
5.3.2 SA方法的描述手段


加工(变换) 对数据进行的操作或变换就称为加工。 加工的命名方法 最高层的加工可以是软件系统的名字; 加工的名字最好由一个谓语动词加上一个宾 语组成; 不能使用空洞或含糊的动词作为加工名; 当遇到不能合适命名的加工时,可以考虑将 加工分解。
2014-3-30
25
5.3.3 实例说明
运动会的工作人员接受各队送来的报名 单后,录入到计算机中。然后通过系统将运动 员号码单、各项成绩等输出给相关人员。系统 将报名单提供给裁判长,由裁判长将确定比赛 项目、比赛成绩等存入计算机中。此外,系统 也向公布台提供单项名次和团体名次信息。
2014-3-30
5
2014-3-30
5.3.2 SA方法的描述手段

DFD的简例
数据流 源点 数据加工 终点
文件
2014-3-30
6
5.3.2 SA方法的描述手段

数据流




数据流是由一组数据项组成的数据,通常用带用带标识 的有向孤给予表示。 例如:飞机订票单的数据流可表示为:旅客信息+日期 +航班号+目的地+金额。 数据流可以从加工流向加工,或从源点流向加工,或从 加工流向终点,或从加工流向文件,或从文件流向从加 工。 在数据流的命名中,不能使用缺乏具体含义的词如“数 据”、“信息”等当作为数据流名。 不能把控制流作为数据流。
分层的DFD 对于大型而又复杂的软件系统,如果用一张DFD 说出所有的数据流和加工,整个图就会变得相当复杂 和难以理解,而且一张纸也难以写下这样的图。为了 控制复杂性,通常可采用分层的方法。 分层DFD的组成 顶层(0层图):用于注明系统的边界,即系统的输 入/输出。0层图整个系统只有一张,实际上就是前面 所说的关联图。 中间层:描述加工的分解,其组成部分可进一步分解。 底层:由一些不能再分解的加工组成,这些加工足够 简单,亦称为基本加工。所谓基本加工是指含义明确、 功能单一的加工。
2014-3-30
17
5.3.2 SA方法的描述手段

数据词典中的条目类型
(1)数据流条目: 用于定义数据流 ,主要说明由哪些数据项组成 数据流,且数据流的定义也采用简单的形式符号 方式。 如:订票单=顾客信息+订票日期+出发日期+航 班号+目的地+…… 对于复杂的数据流,可采用向顶向下逐步细化的 方式定义数据项。 如:顾客信息= 姓名+性别+身份证号+联系电话
8
2014-3-30
5.3.2 SA方法的描述手段


文件 文件是存放数据的逻辑单位,且通常用图 形符号“ ”,“ ”和“ ”分别表示 加工要写文件,读文件和读写文件。另外,在 这个图形符号中还要给出文件名。 源点和终点 源点和终点用于表示数据的来源和最终去 向,且通常用图形方框给予表示。
9
2014-3-30
2014-3-30
3
5.3.1 SA方法的基本思想


基本思想 按照由抽象到具体、逐层分解的方法,确定 软件系统内部的数据流、变换(或加工)的关系, 并用数据流图给予表示。 复杂系统分解示例
顶层
X
中间层
底层
1 2 3.1 3.2
3 3.3
2014-3-30
4
5.3.2 SA方法的描述手段


组成 (1)一套分层的数据流图 (2)一本词典 (3)其它补充材料 数据流图(DFD:Data Flow Diagram) 描述系统内部处理流程、用于表达软件 系统需求模型的一种图形工具,亦即是描述 系统中数据流程的图形工具。
2014-3-30
21
5.3.2 SA方法的描述手段
(3)加工条目:用于说明加工 加工条目主要描述加工的处理逻辑或“做什么” 。 加工条目并不描述具体的处理过程,但可以按处 理的顺序描述加工应完成的一些功能,而且描述 加工的手段通常使用自然语言,或者结构化的人 工语言,或者使用判定表或判定树的形式。 如: 4.1节中某培训中心管理信息系统中的“处 理报名” 加工描述如下:
2014-3-30
19
5.3.2 SA方法的描述手段
当所有出现在DFD中的数据流都给予定义后,最后的 工作就是对出现在数据流中的数据项进行汇总,然以 表格的形式汇录每一数据项。 如:
2014-3-30
20
5.3.2 SA方法的描述手段
(2)文件条目:用于定义文件 文件条目除说明组成文件的所有数据项(与数据 流的说明相同)外,还可说明文件的组成方式 如:航班表文件= { 航班号+ 出发地+ 目的地+ 时间 } 组成方式= 按航班号大小排列
2014-3-30
12
5.3.2 SA方法的描述手段
PMS的主要功能为: ① 通过一个病床监视器实现本地监测,以获得 患者的生理信号。 ② 在护士办公室实现中央监测 ③ 更新和管理患者病历 ④ 产生患者情况的报告以及报警信息
2014-3-30
13
5.3.2 SA方法的描述手段

第0层数据流图
2014-3-30
26

第0层数据流图
2014-3-30
27

第1层数据流图
2014-3-30
28

第2层数据流图
比赛项目
2014-3-30
29

第2层数据流图
2014-3-30
30

数据字典说明
(1)数据流条目
数据流名 项目成绩 单项名次 单项成绩
标识符 ZMCJ DZMC DZCJ
组成 项目名+ 1{运动员号 + 成绩}n 项目名+ 1{名次+ 运动员号+ 成绩+ 破 记录} n 项目名+ 1{运动员号+ 成绩+ 破记录}n
第5章 需求建模方法与技术
1
第5章 需求建模方法与技术
需求建模 主要是根据待开发软件系统的需求利用 某种建模方法建立该系统的逻辑模型(也称需 求模型或分析模型),以帮助软件开发人员检 测软件需求的一致性、完全性、二义性和错误 等。 软件建模应具备的特点: (1)提供描述手段; (2)提供基本步骤。
2014-3-30 36
2014-3-30
37
5.3.4 SA方法的分析步骤
将现实中已存在的人工系统称为当前系统, 把待开发的计算机系统(主要是指软件系统) 称为目标统。
步骤 (1)理解和分析当前的现实环境,以获得当前系统的具体 模型; 具体模型必须忠实地反映人工系统的实际情况。软 件开发人员在获取的需求信息的基础上,利用DFD将现 实环境中的人工系统表达出来。在这样的DFD中,会有 许多“具体”的东西,如人物、地点、名称和设备等。
相关文档
最新文档