名称 | 注解 |
范型(paradigm) | 做事情的整体策略和观点,范型是一套特定的思想集. |
类(class) | 对象创建(实例化)时所使用的模板.相似对象的一种通用表示. |
对象空间(object space) | 包含所有可访问的永久存储的内存空间.对象存在于其中并可以进行交互. |
对象(object) | 对现实世界的一种抽象,知道一些东西(资料),可以完成一些事情(功能). |
面向对象范型(object-oriented paradigm) | 一种基于以下概念的开发策略:即从被称为对象的可重用组件来构建系统的. |
OO(面向对象) | object-oriented or object-orientation. |
统一建模语言(Unified Modeling Language,UML) | 用于面向对象软件的一种标准建模语言定义,包括定义一种建模符号的语义. |
全生命同期面向对象测试 (Full Lifecycle Object-Oriented Testing,FLOOT) |
面向对象开发中的一种测试方法,它提供方法来验证你的程序在开发的每个阶段都能正常工作. |
继承(inheritance) | 表示两个类之间是"is a","is like"或"is kind of"的关系. |
项目成功(project success) | 如果一个项目按时,按预算完成并达到用户的要求,我们认为它是成功的. |
应用积压(application backlog) | 系统部门启动系统开发时从项目第一次被构思开始所花费的平均时间. |
维护负荷(maintenance burden) | 需要软件组织出资来支持,运行并完善已有硬件的基本需求. |
两千年危机(year 2000 crisis,Y2K危机) | 指的是软件组织需要在20世纪90年代末期更新和(或)替代那些使用两位数而不是四位来存储年份的软件. |
内聚(cohesion) | 被封装单元(例如组件或类)的紧密程度;大体上说,最好拥有高内聚. |
耦合 (coupling) | 两个项目之间相互依赖的程度,大体上说,最好是尽可能减少耦合. |
空白区(whitespace) | 空白 , 例如空白行或空格 . |
软件移植(software port) | 软件从一个平台迁移到另一个平台. |
叠代开发(iterative development) | 一种非顺序的开发方法,你可以在任意一天做需求定义,建模,编程或者测试工作. |
质量保证(quality assurance) | 检验某个东西是否以正确的方法构建. |
回归测试(regression testing) | 检验以前的软件改动后仍能正常工作. |
测试(testing) | 检验事件是否正确构建. |
公共对象请求代理体系结构 (Common Object Request Broker Architecture,CORBA) |
由对象管理组织制定的支持分布式对象的一种标准结构. |
企业JavaBeans(Enterprise JavaBeans,EJB) | 一种组件体系结构,由Sun公司制定,用于开发和部署基于组件的分布式业务应用程序. |
对象数据库管理组 (Object Database Management Group,ODMG) |
负责面向对象数据库标准定义以及对象查询语言的一个标准化实体. |
对象管理组 (Object Management Group,OMG) |
一个工业认可的标准化实体,负责统一建模语言(UML)和CORBA这样的标准. |
面向对象软件过程 (Object-Oriented Software Process,OOSP) |
组织在一起的一系列过程模式,用来描述整个开发,维护及支持过程.OOSP基于下面的概念: 大型的关键性业务开发在Internet时代总体上是顺序进行的,局部则以提交增量版本进行. |
过程模式(process pattern) | 一系列通用技术,行为与活动,用于特定的软件过程问题. |
统一过程(unified process) | 面向对象和基于组件软件的一种开发过程. |
参与者(actor) | 一个人,机构或外部系统. |
行为需求(behavioral requirement) | 系统必须支持的功能性任务. |
业务规则(business rule) | 机构运作的原则和策略. |
变例(change case) | 描述你的系统将来需要支持的潜在需求. |
变例模型(change-case model) | 适用于你的系统的变例的集合. |
类图(class diagram) | 展示系统的类与类之间的联系. |
类模型(class model) | 类图以及与它相关的文档. |
类职责协作(CRC)卡 (Class Responsibility Collaborator card) |
一种被划分为三部分的标准索引卡:一部分指出卡片的类名,另一部分列出类的职责, 第三部分列出与此类一起协作履行职责的类名. |
类职责协作(CRC)模型 (Class Responsibility Collaborator model) |
一组CRC卡片,它们对系统的整体或部分建模. |
约束(constraint) | 对于你在解决问题的过程中所拥有的自由度限制. |
领域模型(domain model) | 表示适用你的系统的业务/领域概念及其相互关系.领域模型有助于为项目建立词汇表. |
本质用况模型(essential use case) | 一个简化的,抽象的,通用的用况,以一种独立于技术和实现的方式捕获用户的意图. |
本质用户接口原型(essential user interface prototype) | 一种低可信度的系统用户接口原型,用以对用户接口本质的,抽象的特性建模. |
非功能性需求 (nonfunctional requirement) | 系统必须遵守的标准,规章和合同.它们是对系统的确认;是对系统和必须与之打交道的外部系统的界面的 描述;性能的需求;设计和实现的约束;以及你的系统必须遵守的质量约束. |
原型 (prototype) | 项目的仿真,例如用户界面或系统体系结构,使用它的目的是当投入大量资源之前把你的方法告知他人. |
需求模型 (reqirements model) | 制品的集合,包括用况模型,领域模型,用户界面模型,变例模型和描述系统需求的补充规范. |
主题信息专家(subject-matter expert,SME) | 通过个人知识或研究所得,负责提供问题和/或技术领域相关信息的人. |
补充规范(supplementary specification) | 对适用于系统的的业务规则,结束,非功能性需求的定义. |
系统用况(system use case) | 细化的用况,用于描述系统如何实现对应的本质用况的需求.通常涉及到与实现相关的特性, 例如用户界面的外观. |
系统用况模型(system use case model) | 由系统用况组成的模型. |
用况(use case) | 一系列动作,它们提供给参与者可测量的值. |
用况图(use case diagram) | 显示用况,参与者以及它们之间的相互关系的UML图. |
用况模型(use case model) | 由用况图,用况定义以及参与者定义组成的模型,用况模型被用来对系统行为需求进行建文件. |
用户界面(user interface ,UI) | 软件的用户界面是与用户直接交互的部分,包括屏幕显示,报表,文文件以及软件支持(通过电话,电子邮件等) |
用户界面流程图(user interface-flow diagram) | 对系统界面对象以及它们之间的关系进行建模的图.也称做界面流图(interface-flow diagram), 窗口导航图(windows navigation diagram)或界面导航图(interface navigation diagram) |
用户界面模型(user interface model) | 由系统用户界面原型,用户界面流程图以及优秀任意与用户界面相关的文文件组成的模型. |
本质模型(essential model) | 通过与技术无关的,理想化的和抽象的描述捕获问题本质的模型. |
以应用为中心的设计(usage-centered design) | 一种建模技术,这种建模技术着重关注用户希望完成的工作, 以及系统需要通过用户界面提供哪些支持以帮助用户达到他们的目标. |
扩展关联(extend association) | 一种泛化的关系,扩展用况继续本质用况的行为. |
包含关联(include association) | 一种泛化的关系,描述一个用况在另一个用况中的包含行为. |
内聚(cohesion) | 封装单元内的相关程度. |
组件图(component diagram) | 描述组成应用,系统或企业的软件组件的图.图中描述了组件,组件之间的相互关系, 相互作用和它们的公共接口. |
活动图(activity diadram) | 一种UML图,用于对高层业务过程或类状态转移进行建模 |
协作图(collaboration diagram) | 显示类实例,它们之间的相互关系以及它们之间的消息流的UML图. |