新软件建模技术.docx
- 文档编号:4634694
- 上传时间:2022-12-07
- 格式:DOCX
- 页数:13
- 大小:24.76KB
新软件建模技术.docx
《新软件建模技术.docx》由会员分享,可在线阅读,更多相关《新软件建模技术.docx(13页珍藏版)》请在冰豆网上搜索。
新软件建模技术
1.面向对象分析和设计
对创建对象系统来说,了解面向对象语言是必要的,单不是首先要做的。
了解“对象思想”才是关键所在。
UML和对象思想
UML是标准的图形化表示法,并不是OOA/D,没有掌握如何创建优秀的面向对象设计,或者如何评估和改进现有设计,那么学习UML或者UMLCASE工具是毫无意义的。
对象思想才是重点和难点。
OOD的原则和模式
系统设计中的关键问题:
应该如何为对象分配职责(Responsibility)?
对象之间应该如何写作?
什么样的类应该做什么样的事?
模式:
某些针对设计问题的,经过反复验证的解决方案可以(和已经)被表示为最佳时间的原则、起始或模式(pattern),即问题-解决方案公式,这些公式是系统化的、典范的设计原则。
用例
OOD(以及所有软件设计)与作为其先决活动的需求分析(requirementsanalysis)具有紧密联系,而在需求分析中通常包含用例的编写。
什么是分析和设计
分析(analysis)强调的是对问题和需求的调查和研究,而不是解决方案。
需求分析:
对需求的调查研究。
面向对象分析:
对领域对象的调查研究。
设计(design):
强调的是满足需求的概念(逻辑)上的解决方案(在软件和硬件方面),而不是实现。
例如,对数据库方案和软件对象的描述。
设计细想通常排斥底层或“显而易见”的细节。
最终,设计可以实现,而实现(入如代码)则表达了真实而完整的设计。
什么是面向对象分析和设计
在面向对象分析过程中,强调的是在问题领域内发现和描述对象(或概念)。
例如,在航班信息系统中包含飞机、航班、和飞行员
在面向对象设计过程中,强调的是定义软件对象以及如何写作以实现需求。
例如,软件对象Plane可以有tailNumber属性和getFlightHistory方法。
最后,在实现或面向对象程序设计过程中,会实现设计出来的对象,入Java中的Plane类。
面向对象的分析与设计例子
一个简单的例子—“掷骰子游戏”(dicegame),在这个游戏中游戏者掷出两个骰子。
如果总点数为7就赢了,否则就输了。
定义用例
需求分析可能包括人们如何使用应用的情节或场景,这些情节或场景可以被编写为用例(UseCase)。
用例不是面向对象制品,而只是对情节的记录。
但用例是需求分析中的一种常用工具。
骰子游戏:
定义领域模型
面向对象分析关注从对象的角度创建领域描述,需要鉴别重要的概念、属性和关联。
结果可以表示为领域模型(domainmodel)(展示重要的领域概念或对象)。
领域模型不是对软件对象的描述,而是真是世界领域中的概念和想象的可视化。
因此也被称为概念对象模型(conceptualobjectmodel)。
分配对象职责并绘制交互图
定义设计类图
有效表示类定义的静态视图(描述类的属性和方法)。
领域模型表示的真是世界的类,设计类图表示的是软件类。
OO设计和语言能够缩小软件构件和所设想的领域模型之间的差距,即实现低表示差距(lowerrepresentationalgap)。
2.迭代、进化和敏捷
迭代开发是OOA/D成为最佳实践的核心。
敏捷实践是有效应用UML的关键。
UP是相对流行的、示范性的迭代方法。
相对于顺序或“瀑布”(waterfall)生命周期,迭代和进化式开发对部分系统及早地引入了编程和测试,并重复这一循环。
这种方式通常会在还没有详细定义所有需求的情况下开始开发,同时使用反馈来明确和改进演化中的规格说明。
依赖于短时快速的开发步骤、反馈和改写来不断明确需求和设计。
2.1UP
软件开发过程:
描述了构造、部署以及维护软件的方式。
统一过程已经成为一中流行的构造面向对象系统的迭代软件开发过程。
UP把普遍认可的最佳实践结合起来,成为联系紧密并具有良好文档的过程描述。
2.2迭代和进化史开发
迭代开发(iterativedevelopment)是UP和大多数其他现代方法中的关键实践。
在这种生命周期法中,开发被组织成一系列国定的短期小项目,称为迭代(iteration);每次迭代都产生经过测试、集成并可执行的局部系统。
每次迭代都具有各自的需求分析、设计、实现和测试活动。
迭代生命周期基于对经过多次迭代的系统进行持续扩展和精化,并以循环反馈和调整为核心驱动力,使之最终成为适当的系统。
随着时间和一次又一次迭代的递进,系统增量式地发展完善,因此这一方法也被称为迭代增量式开发。
因为反馈和调整使规格说明和设计不断进化,所以这种方法也被称为迭代和进化式开发。
优点:
减少项目失败的可能性,提高生产率,降低缺陷率。
在早期缓解高风险
早期可见的进展
早期反馈、用户参与和调整,会产生更接近涉众真是需求的精化系统。
可控复杂性:
团队不会被“分析瘫痪”或长期且复杂的步骤所淹没。
一次迭代中的经验可以被系统地用于改进开发过程本身,并如此反复进行下去。
一次迭代持续的时间
在每个开发周期中有一个实用的策略,那就是为这个开发周期加上一个“时间盒”—即一段固定的时间。
在这个开发周期中所有的工作都应在这个时间内完成。
一般来说,两周到两个月是比较合适的时间盒值,如果时间再短一点,将很难完成任务;如果时间再长一些,一个开发周期中遇到的各种问题的复杂性将难以处理,并且得到反馈信息的时间将拖后。
要成功实施“时间盒”调度,必须仔细选择所要处理的需求,并确保开发小组对所做出的选择负责。
瀑布生命周期
在瀑布(或顺序)生命周期中,试图在编程之前(详细)定义所有或大部分需求。
而通常于编程之前创建出完整的设计(或模型集)。
同样,试图在开始前定义“可控的”计划或时间表。
单常常是“事与愿违”
如何进行迭代和进化式分析和设计
1)在第1次迭代之前,召开第一个时间定量需求工作会议。
2)在第1次迭代之前,召开迭代计划会议,(选择用例(或子集),在特定的时间内完成)。
3)在3-4周内完成第1次迭代。
4)在第1次迭代即将结束是,召开第2次需求工作会议,对上一次会议的所有材料进行复杂和精化。
5)于周五上午,举行下一迭代计划会议。
6)以相同步骤进行第2次迭代。
7)反复进行4次迭代和5次需求工作会,这样在第4次迭代结束时,可能已经详细记录了约80-90%的需求,但只实现了系统的10%。
8)带该推进了整个项目的20%。
在UP术语中,这是细化阶段(elaborationphase)的结束。
9)此后,一般不需要再召开需求工作会议;需求已经稳定了,接下来是一系列为期3周的迭代,在最有一个周五召开的迭代计划会议上选择适宜的下一步工作,每次迭代都要反复询问:
“就我么现在所知,下一个3周应该完成的、最关键的技术和业务特性是什么”
UP的其他关键实践
在早期的迭代中解决高风险和高价值的问题
不断让用户参与评估、反馈和需求
在早期迭代中建立内聚的核心架构
不断验证质量:
提早、经常和实际的测试
进行一些可视化建模
认真管理需求
实行变更请求和配置管理
UP阶段
初始(Inception):
大体上的构想、业务案例、范围和模糊评估。
细化(Elaboration):
已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数的需求以及进行更为实际的评估。
构造(Construction):
对遗留下来的风险较低和比较简单的元素进行迭代实现,准备部署。
移交(Transition):
进行beta测试和部署。
第二部分
1.初始阶段
初始阶段是建立项目共同设想和基本范围的比较简短的起始步骤。
为了在随后的细化阶段哪能够开始编程,它将包括对10%的用例进行分析、关键的非功能需求的分析、业务案例创建和开发环境的准备。
在该阶段考虑以下几类问题:
项目的设想和业务案例是什么?
是否可行?
购买还是开发?
初略估算一下成本
项目应该继续下去还是停止?
2.进化式需求
2.1定义需求
需求(requirement)就是系统(更广义的说法是项目)必须提供的能力和必须遵从的条件。
在变更不可避免,涉众意愿不明朗的情况下,UP更推崇“一种系统的方法来寻找、记录、组织和跟踪系统不断变更的需求”。
通过迭代巧妙地进行需求分析,而非草率和随意为之。
需求分析最大的挑战是寻找、沟通和记住什么是真正的需求,并能够清楚地讲解给客户和开发团队。
2.2进化式需求与瀑布式需求
2.3寻找需求可以采用的方法
与客户一同编写用例
开发者与客户共同参加需求讨论会
请客户代理参加焦点小组
向客户演示每次迭代的成果以及求得反馈。
2.4需求的类型和种类
需求按照“FURPS+”模型进行分类:
功能性(Functional):
特性、功能、安全性
可用性(Usability):
人性化因素、帮助、文档
性能(Performance):
响应时间、吞吐量、准确性、有效性、资源利用率。
可支持性(Supportability):
适应性、可维护性、国际化、可配置性。
“+”是指一些辅助性的和次要的因素:
实现(Implementation):
资源限制、语言和工具、硬件等。
接口(Interface):
强加于外部系统接口之上的约束。
操作(Operation):
对其操作设置的系统管理。
包装(Packaging):
授权(Legal):
许可证或其他方式。
在进行架构分析的时候,质量属性对系统架构具有极大影响。
功能性需求和非功能性需求
2.5UP制品如何组织需求
用例模型:
一组使用系统的典型场景。
主要用于功能(行为)需求
补充性规格说明:
用例之外的所有内容。
词汇表:
重要的术语。
设想:
概括了高阶需求,这些需求在用例模型和补充性规格说明中进行细化。
也概括了项目的业务案例。
帮助快速了解项目的主要思想。
业务规则:
描述凌驾于某一软件项目的需求或政策。
3用例
用例是文本形式的情节描述,用以说明某参与者使用系统以实现某些目标。
广泛应用于需求的发现和记录中。
不是图形,而是文本。
通过编写使用系统实现用户目标的情节来发现和记录功能性需求,也就是使用的案例。
3.1定义:
参与者、场景和用例
参与者(actor)是某些具有行为的事物,可以是人(由角色标识)、计算机系统或组织。
场景(scenario)是参与者和系统之间的一系列特定的活动和交互,也称用例实例(Usecaseinstance)。
是使用系统的一个特定情节或用例的一条执行路径。
用例(Usecase)就是一组相关的成功和失败场景的集合,用来描述参与者如何使用系统来实现其目标。
3.2用例和用例模型
用例模型是所有书面用例的集合,是系统功能性和环境的模型。
用例是文本文档,而非图形;用例建模主要是编写文本的活动,而非制图。
用例模型可以包含UML的用例图,以显示用例和参与者的名称及其关系。
UML用例图可以为系统及其环境提供良好的语境图(contextdiagram:
显示了领域内的广义应用(或者是目标系统)和与之通信的其他实体或抽象物之间的数据流。
),也为按名称列出用例提供了快捷方式。
不是面向对象所特有的。
3.3为什么使用用例
缺少用户参与用户参与是项目失败的主要原因之一,所以任何有利于用户参与的方法是绝度值得的。
用例是一中优秀的方法,使领域专家或需求提供者自己编写(或参与编写)用例称为可能,并使这项工作难度降低。
用例的另一个价值是强调了用户的目标和观点。
“谁使用系统,他们使用的典型场景是什么?
他们的目的是什么?
”(以客户为中心)。
用例被推荐作为发现和定义需求的核心机制。
3.4参与者的三种类型
主要参与者(primaryactor):
具有用户目标,并通过使用系统的服务实现。
(发现驱动用例的用户目标)
协助参与者(supportingactor):
为系统提供服务。
(为了明确外部接口和协议)
幕后参与者(offstageactor):
在用例行为中具有影响或利益。
()为了确保满足所有的重要事物
3.5表示法:
用例的三中常用形式
摘要:
简洁的一段式概要,常用于主成功场景。
使用时机:
在早期需求分析中,为快速了解主题和范围。
非正式:
非正式的段落式。
用几个段落覆盖不同场景。
使用时机:
在早期需求分析中,为快速稍微详细了解主题和范围。
详述:
详细描述所有步骤及各种变化,同时具有补充部分,如前置条件和成功保证。
使用时机:
确定并以摘要形式编写了大量用例后,在第一次需求讨论会中,详细编写其中少量具有重要架构意义和高价值的用例。
(教材P49-55)
3.6发现用例
1)选择系统边界。
2)确定主要参与者;
3)确定每个主要参与者的目标;
4)定义满足用户目标的用例,根据其目标对用例命名。
通常,用户目标级的用例和用户目标是一一对应的。
3.7测试有用的用例
老板测试:
EBP(基本业务过程)测试:
一个人于某个时刻在一个地点所执行的任务,用以响应业务事件。
该任务能增加可量化的业务价值,并以持久状态留下数据。
用例不是单独的一小步;如:
删除一条记录
用例主成功场景应该是5-10步骤;
用例不能持续数日或多个会话过程;
3.8活动图
活动图:
UML包含一种有助于使工作流和业务过程可视化的图
用例涵盖过程和工作流分析,所以活动图能够称为编写用例文本的有用的辅助措施。
3.9在迭代过程中如何使用用例
用例驱动开发:
功能需求首先记录在用例;
用例是迭代计划的重要部分。
迭代工作是通过选择一些用例场景或整个用例来定义的。
用例实现驱动设计:
设计协作对象和子系统是为了执行或实现用例;
用例通常会影响用户手册的组织;
为重要用例的最常用场景创建UI“向导”或快捷方式可以方便执行常用任务。
4迭代1—领域模型
领域模型是OO分析中最重要的和经典的模型。
确定一组概念类是OO分析的核心。
阐述了领域中的重要概念;
可以作为设计某些软件对象的灵感来源;
领域模型的范围限定于当前迭代所开发的用例场景;
能够不断演进用以展示相关的重要概念。
4.1什么是领域模型
对领域内的概念类或现实世界中的对象可视化表示。
也称概念模型、领域对象模型和分析对象模型。
UML表示法,领域模型被描述为一组没有定义操作(方法的特征标记)的类图,它可以展示:
领域对象或概念类
概念类之间的关联
概念类的属性。
领域模型是可是化字典,表示领域的重要概念、领域词汇和领域的内容信息。
领域模型不是软件对象。
领域模型不是数据模型:
不会排除需求中没有明确要求记录其相关信息的类;
不会排除没有属性的类;(充当纯行为角色的概念类)
4.2概念类
概念类(conceptualclass)是思想、事物或对象,可以从符号、内涵和外延来考虑。
符号:
表示概念类的词语或图形;
内涵:
概念类的定义;
外延:
概念类所适用的一组示例;
4.3为什么要创建领域模型
降低与OO建模之间的表示差异:
领域层软件类的名称要源于领域模型中的名称,以使对象具有源于领域的信息和职责。
4.4如何创建领域模型
以当前迭代中所要设计的需求为界:
寻找概念类
将其绘制为UML类图中的类;
添加关联和属性。
4.5如何找到概念类
重用或修改现有模型;
使用分类列表;(P104-105)
确定名词短语。
(P105-106)
4.6准则:
报表对象—模型中是否要包括“票据”
票据是POS领域的重要术语,但也许它只是销售和支付数据的报表,因此是一种信息的重复。
是否应该将票据包含在(当前迭代周期)领域模型中?
4.7使用领域术语
P108
4.8属性与类
P109
在创建领域模型常犯的错误:
把应该是概念类的事物表示为属性。
准则:
任务某概念类X不是现实世界中的数字或文本,那么X可能是概念类而不是属性。
比如:
Store(商店是否作为Sale的一个属性)?
Destination(目的机场)是否应作为Flight(航班)的一个属性?
4.9“描述”概念类
描述类:
包含描述其他事物的信息。
为什么要使用描述类?
在以下情况下需要增加描述类:
需要有关商品或服务的描述独立于任何商品或服务的实例。
删除其所描述事物的实例后,导致信息丢失,而这些信息是需要维护的,但是被错误地与所删除的事物关联起来。
减少冗余或重复信息。
销售点终端问题域中的后选概念
⏹POST
⏹ITEM
⏹Store
⏹Sale
⏹Payment
⏹ProductCatalog
⏹ProductSpecification
⏹SalesLineItem
⏹Cashier
⏹Customer
⏹Manager
4.10关联
关联(association)是类(类的实例)之间的联系,表示有意义和值得关注的连接。
关联能够满足当前所开发场景的信息需求,并且有助于理解领域。
UML中,关联被定义为“两个或多个类元之间的语义联系,涉及这些类元实例之间的连接”。
4.11何时需要关联
由于领域模型是从概念角度出发的,所以是否需要记录关联,要基于现实世界的需要,而不是基于软件的需要(尽管在实现过程中,会有出现大量对关联的需要)。
如:
收银员与产品描述。
准则:
在领域模型中要考虑如下关联:
如存在需要保持一段时间的关系,将这种语义表示为关联(“需要记住”的关联);
从常见关联类表中派生出的关联。
准则:
应该避免加入大量关联。
关联不是关于数据流、数据库外键联系、实例变量或软件中的对象连接语句;关联声明的是针对现实领域从纯概念的角度看有意义的关系。
这些关系大部分将作为(设计模型和数据模型中的)导航和可见性路径在软件中加以实现。
领域模型不是数据模型;
添加关联是为了突出对重要关系的理解,而非记录对象或数据结构。
4.12关联表示法
关联被表示为类之间的连线。
多重性:
表示在特定时刻(而不是在一段时间之内)有效关系的实例数量。
关联的末端可以包含多重性表达式:
指明类实例之间的数量关系。
命名:
“类名-动词短语-类名”
角色:
关联的每一端称为角色
4.13属性
属性是对象的逻辑数据值。
确定概念类的属性能够满足当前所开发场景的信息需求。
当需求建议或暗示需要记住信息时,引入属性。
4.14属性类型
领域模型中的属性通常应该是简单数据类型。
简单数据类型指的是一组值,而这组值的标识本身不具有任何意义。
4.15何时定义新的数据类型
在领域模型里,把最初被认为是数字或字符串的数据类型表示为新的数据类型:
由不同的小节组成;
具有与之相关的操作;
具有其他属性;
单位数量;
具有以上性质的一个或多个类型的抽象。
4.16任何属性都不表示为外部键
领域模型里的属性不应该用于表示概念类的关系。
应使用关联而不是属性来表示类型关联。
4.17对数量和单位建模
大部分用数字表示的数量不应该表示为纯数字。
比如:
具有价格或重量的数量。
一般做法:
把数量表示为一个单独的Quantity(数量类),并且将该类关联到Unit(单位类)。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 建模 技术
![提示](https://static.bdocx.com/images/bang_tan.gif)