软件开发方法述评

合集下载

本人专业技术工作述评精选3篇

本人专业技术工作述评精选3篇

本人专业技术工作述评精选第一篇:《某某工程师2019年度专业技术工作述评》我是某某工程师,从事计算机软件开发工作已有十年时间。

在过去一年里,我积极投入工作,主要完成了以下几项工作:1. 完成某高校教务管理系统的升级开发工作我负责某高校教务管理系统的升级工作,主要包括将原有系统的数据迁移到新的数据库平台上,并在此基础上进行新功能开发和优化。

我与团队成员合作,共同完成了此项任务,并在规定的时间内成功上线,为高校的教务管理工作提供了更高效、稳定的支持。

2. 参与开发某电商平台新功能我参与了某电商平台的新功能开发工作,主要负责与其他业务系统的对接,保障各系统的同步和同步速度。

我深入了解了业务需求,并通过技术手段实现了各系统之间的无缝协作,确保了新功能的正常使用和业务效果。

3. 维护某企业内部OA系统我在过去一年中也参与了某大型企业内部OA系统的维护工作,保障了系统的稳定运行和数据安全。

我通过加强系统监控和优化数据库配置等手段,有效地降低了系统故障率和数据泄露风险。

通过这些工作,我不仅取得了业绩,还不断提高了自己的专业技能。

在接下来的工作中,我会继续加强自己的技术学习,在实际工作中不断探索和创新,提供更好的技术支持和服务。

第二篇:《某某产品经理2020年度专业技术工作述评》我是某某产品经理,从事互联网产品运营工作已有五年时间。

在过去一年里,我主要完成了以下几项工作:1. 完成某医疗就诊预约APP的改版升级我带领团队完成了某医疗就诊预约APP的改版升级工作,主要通过优化UI界面、增加在线咨询及就诊记录等功能,改善了用户使用体验和操作流畅度。

同时,我们也针对原有系统的安全性进行了加强,有效避免了一些安全漏洞的出现。

2. 推出某生活服务类APP,取得较好的用户反馈我参与了某生活服务类APP的研发及上线工作,主要针对用户的日常生活需求,提供包括物业服务、家政服务、清洁服务、餐饮服务、活动推荐等服务内容,受到用户的高度关注和赞赏。

个人技术水平述评

个人技术水平述评

个人技术水平述评一、技术背景作为一名资深软件工程师,我从事软件开发行业已有十年的工作经验。

在过去的十年里,我积累了丰富的算法和编程经验,掌握了多项主流编程语言和开发工具,包括Java、Python、C++、Git、Docker等。

我还具有丰富的项目管理经验,能够独立完成软件项目的开发、测试和部署工作。

二、技术能力1. 编程能力我在多年的编程实践中,积累了丰富的编程经验,能够熟练运用Java、Python、C++等编程语言进行软件开发。

在项目中,我能够根据需求设计合理的程序架构,编写出高效、健壮、易维护的代码。

我对面向对象编程(OOP)、函数式编程(FP)等编程范式有深入的理解,并能够根据具体情况选择合适的编程方式。

2. 算法和数据结构在算法和数据结构领域,我具有扎实的基础,能够灵活运用各种算法解决实际问题。

我熟悉常见的排序算法、查找算法、图算法等,并能够根据问题特点选择合适的算法。

我对常见的数据结构(链表、树、图等)有深入的理解,并能够灵活运用。

3. 架构设计我具有丰富的架构设计经验,能够根据项目需求设计合理的软件架构。

我熟悉常见的架构模式(MVC、MVVM、微服务架构等),并根据项目规模和复杂度选择合适的架构方案。

在具体实践中,我能够按照架构设计编写高质量的代码,保证系统的性能和可维护性。

4. 项目管理在项目管理方面,我具有丰富的经验,能够独立完成软件项目的开发、测试和部署工作。

我擅长使用Git进行版本控制,并能够合理管理代码库和协作开发。

我熟悉Docker等容器化技术,能够进行持续集成和持续部署(CI/CD)工作。

三、技术追求在工作中,我一直保持着对新技术的学习和追求。

我关注业界最新的技术动态,积极参与技术社区和开源项目,不断探索前沿的技术领域。

我相信只有保持学习和进步,才能在日新月异的科技领域立于不败之地。

四、技术总结我在编程能力、算法和数据结构、架构设计、项目管理等方面都具有丰富的经验和能力。

软件设计与体系结构 第四章 面向对象的软件设计方法

软件设计与体系结构 第四章 面向对象的软件设计方法

用户界面设计
用户界面是对于用户的直接表现,直接影响到用
户对软件易用性、友好性的感觉。用户界面包含 两方面内容:
首先要完整地包括用户在使用软件过程中所需的各种 元素,例如窗口、菜单、按钮、输入文本框、选择列 表、提示信息等,缺乏这些元素中的某些将会导致软 件功能无法被用户正常完成; 其次要求具有良好的外观和布局,例如背景颜色、按 钮等元素的位置、选择列表中条目的顺序等,这些因 素的不足可能不会影响软件功能的正确使用,但会给 用户带来不便、迷惑甚至反感。
ATM系统在提供以上服务的过程中,必须满足以下要求 一个顾客可以在最终确认前放弃一项交易 ATM在执行交易过程中将与银行系统进行通信,对是否 允许交易进行验证 ATM为每次成功的交易提供一个打印回执
ATM需要维护一个内部日志,对每次交易进行记录
用例的分析与设计
确定用例—确定场景
从业务需求出发获取参与者(Actor)和场景,对场景进行汇总、分 类、抽象,形成用例 场景是用户与系统之间进行交互的一组具体的动作 获取场景 目标软件有哪些参与者
用例的分析与设计
Startup用例的顺序图描述
用例的分析与设计
Session用例的顺序图描述
用例的分析与设计
Transaction用例的顺序图描述
用例的分析与设计
Withdrawal用例的顺序图描述
概念模型和顶层架构设计
概念模型的设计 标识领域概念模型 分析类:直接服务于用户功能性需求的概念层面的类, 与具体技术没有关系 顶层架构的设计
件进行交互的功能与特性进行封装,使目标软件系统的其余部分
尽右能独立于环境软件。
概念模型和顶层架构设计
ATM系统的概念模型——分析模型图

软件开发范文

软件开发范文

软件开发范文
随着信息技术的快速发展,软件开发行业也呈现出蓬勃的发展
态势。

作为一个软件开发工程师,我深知软件开发的重要性和挑战。

在这篇文章中,我将分享我对软件开发的理解和体会。

首先,软件开发是一个复杂而严谨的过程。

在软件开发的过程中,我们需要充分了解客户的需求,设计出合理的软件架构,并且
编写高质量的代码。

这需要我们具备扎实的编程技能和丰富的开发
经验。

同时,我们还需要与团队成员紧密合作,共同解决各种技术
难题和沟通问题。

只有通过不懈的努力和团队合作,我们才能开发
出满足客户需求的优质软件产品。

其次,软件开发是一个不断学习和创新的过程。

随着技术的不
断更新和发展,我们需要不断学习新的技术和工具,以适应市场的
需求。

同时,我们也需要不断创新,不断改进我们的开发方法和流程,以提高软件的质量和效率。

只有不断学习和创新,我们才能在
激烈的市场竞争中立于不败之地。

最后,软件开发是一个充满挑战和成就感的过程。

在软件开发
的过程中,我们会遇到各种技术难题和挑战,需要不断克服各种困
难。

但是,当我们克服了困难,开发出了优质的软件产品,我们会获得巨大的成就感和满足感。

这种成就感会激励我们不断前行,不断追求更高的目标。

总之,软件开发是一个复杂而充满挑战的过程,但是只要我们不断学习和创新,不断努力和团队合作,我们就一定能够开发出优质的软件产品,为客户创造更大的价值。

希望通过我们的努力,能够为软件开发行业的发展做出更大的贡献。

软件设计与体系结构-第四章-面向对象的软件设计方法课件

软件设计与体系结构-第四章-面向对象的软件设计方法课件

l 概念模型与顶层架构设计:
l 在用户需求和相关的业务领域中,概念及概念关系的抽取
l 用户界面设计:
l 设计每个界面中的所有界面元素,确定初步的界面布局,定义用户界面动作对软件系统中设计元
素的要求
l 数据模型的设计:
l 确定设计模型中需要持久保存的类的对象及其属性,定义持久持久存储数据之间的组织方式,并
.
26
概念模型和顶层架构设计
l 边界类: 其职责包括: l 边界控制: l 包括定义数据的格式及内容转换,输出结果的呈现,软件运行过程中界
面的变化与切换等。 l 外部接口: l 实现目标软件系统与外部系统或外部设备之间的信息交流和互操作,主
要关注跨越目标软件系统边界的通信协议 l 环境隔离: l 对目标软件系统与操作系统、数据库管理系统、中间件等环境软件进行
事件流中步骤(1)
l (3)如果账户余额小于取款金额,则显示信息“账户余额不足,请重新输入”,并返回主事件流
中步骤(1)
l (4)顾客在确认取款金额前右以选择取消交易。
l 后置条件: 如果取款成功,系统从账户余额中减去相应数额,并返回等待状态;如果顾客取消交易,
则返回等待状态
.
19
用例的分析与设计
体技术没有关系 l 顶层架构的设计 l 目的: 为后续的分析和设计活动建立一种结构和划分
.
24
概念模型和顶层架构设计
l 关键概念来源: l 为建立以UML类图表示的领域概念模型,首先必须标识关键概念。关键
概念的来源包括: l (1)业务需求描述、用例说明; l (2)业务领域中的相关规范、标准、术语定义。 l (3)反映业务领域知识的既往经验。 l 业务需求描述 l 业务领域中的相关规范、标准、述评呼定义 l 反映业务领域知识的既往经验

软件项目绩效评价研究述评

软件项目绩效评价研究述评
维普资讯
第3卷 第 1 0 期 20 年2月 08
武 汉 理 工 大 学 学 报 ・信 息 与 管 理 工 程 版 JU N LO T IF R A IN&M N G M N N IE RN 1 O R A FWU (N O M TO A A E E TE GN E IG
的不同相关人和不同的研究人员 , 其定义也不同。 文献 [ ] 为软 件项 目绩 效包 括 产 品 绩效 和 过 程 5认 绩效 。产 品绩 效是 指在 项 目开 发过程 中所 开 发 的
系 统是 否成 功 , 7个 指 标 项 测 度 产 品绩 效 ( 用 应
收稿 日期 :0 7— 8— 2 20 0 2 . 作者简介: 于本海 (9 8一) 男 , 16 , 内蒙赤 峰人 , 中科技大学管理学院博士研究生. 华
整 个组 织控 制 、 沟通 和学 习知识 能力 的评价 , 包 也 括 行为 活 动 成果 ( 件 产 品 ) 软 的测 量 与评 价 。经 过 多年 的研 究实 践 , 件 项 目绩 效 评 价在 质 量 管 软 理 、 程管 理和 软 件 项 目管 理 等 方 面 形成 了不 同 过 的研 究体 系 。笔者 界定 了软 件 项 目绩效 的 内涵 , 并对 软件 项 目绩效 评价 的研 究现状 进 行评述 。
(. 中科技大学 管理学 院, 1华 湖北 武汉 407 ;. 3042 山东工商学院 , 数学与信息科学学院 , 山东 烟 台 240 ) 605

要: 界定 了软件项 目绩效评价 的范 围和内涵 , 以软件项 目绩效评价为主线 , 从软件项 目管理 、 质量控制项 目绩效评 价的研 究作 以述评 ; 对 认为 当前软件绩 效评价 的研究仅 限于 相关因素的分析 , 对项 目过程管理 的研究仅关注过程改进模型 的认证 ; 得出了完善评 价指标体系 、 建立综合评 价模型应是软件项 目绩效评价研究主要方 向的结论 , 对加强我 国软件项 目管理具有指 导意义。

面向资源的Web开发方法

面向资源的Web开发方法

Ke wo d : r s u c — re td we ; e eo me t y rs eo reo ne ; b d v lp n i
随着 Itre 的发 展 ,网站 数量 不 断增 加 ,We nen t b 应用 逐 渐增 多 。We b具 有 内容动 态变 化 、多种 媒 体
转 化 ,计 算是 资源 到 资源 表 示转 化 的 过程 .资 源表
示 是 不 可 改 变 的 ,从 一 个 资 源 表 示 到 另 一 个 资 源 表
形式 、用 户多 且 差异 大 、内 容驱 动 等 特点 ] 。这 使
得 We b开 发 与 一 般 软 件 的 开 发 有 很 大 差 异 。 在 总 结 We b成 功 原 因 的 基 础 上 , 人 们 提 出 了 面 向 资 源 计 算

( eo reO i t o uigR C 、面 向资 源 架 构 R suc r ne C mp t .O ) e d n
( s u c . ine c i cu e ROA) ES 风 格 Re o reOr tdArh t tr , e e 、R T
Ap . 01 r2 1
面 向资源 的 We b开发 方 法
吴 胜 . 苏 琴
(. 南 财 经 政 法 大 学武 汉 学 院信 息 系 ,湖 北 1巾 武汉 4 0 7 ; 2徐 州 师 范 大 学 计 财 处 , 江 苏 309 . 徐州 2 l 6) 21 1

摘 要 : 先 对 软 件 开 发 方 法 、 W e 工 程 、 敏 捷 软 件 开 发 方 法 、 面 向 资 源 架 构 、 面 向 资 源 计 算 等 相 关 W e 开 发 方 法 b b
Re o r e Ore t dW e v l p e t eh d s u c . in e b De e o m n M t o

美国软件成本研究述评

美国软件成本研究述评
( h e t sac ntueo eeo T eT nhReerhIstt f lcmmu iai s e h ooy Xi n7 0 6 , hn i T nct n c nlg , " 10 1 C ia o T a
摘 要 : 国作 为世 界 上 最 大软件 产 品生 产和 消 费 国, 美 其软件 成 本研 究一直世 界 领 先地位 。F S ( 国准 则委 员会 ) 在 17 A B美 早 94年就 发 S ( ;9 5 A B发 F S6  ̄售 、 ( 出租 或 以其 它方 式上 市 的计 算机 软件 成本 会 计》 随着软 件 产 品的 演进 , 。 在管 理工程 领 域 出现 了几个 比较 有影 响 的软件 成本 估算模 型 :B IM模 型 (9 7 、u a 型 (9 8 、O O O 8 (9 1C C M —I 型 (00 。 17 )P t m模 n 17 )C C M 一 118 ) O O O I模 20 )
后发 生的费用归集为生产 费用并应 当资本化 为软件生产成本 , 同时 世界上第一台 电子计 算机和微型 电子计算机均诞 生于 美国。同 按 收入百 分比法和直线法孰 大的数额予 以摊销 从生产 完毕 到交付 时, 美国也是最早 广泛应用 电子计算机 的国家。随着 电子计算机在 顾客前之 间的费用 归集 为存货费用 , 存货费用按产品 资本 化 , 货 销 美 国 的普 及 ,软 件业 务从 1 4 在 美 国 起 步 到 世 界 第 一 家 独 立 软 时结 转 销 售 成 本 付 顾 客 后 的 费用 归入 其 他 费 用 , 接 费 用 化。资 9 9年 交 直 件 公 司(u ) 1 5 c c于 9 5年 3月 2 日由埃 米 尔 ・  ̄ (l e u i 和 乔 产负债表 中的资本化软件摊 余成 本 ,按成本与市价 孰低法列示t 8 库 LEm r be K ) 2 ] 。 治 ・ 尔 登 ( h hlo ) 美 国创 立 ,软 件 ” 期 的 发 展 几 乎都 是 19 谢 J nS e n在 o d “ 初 9 8年 A S C 美 国证 监 会) 布 S P 8 1开 发 或 取 得 内部 使 用 的 cE ( 发 O 9— 《 在 美国完成。随后 的十年 美国 出现 了四十 多家规模较大 的软件 公 软件成本会计》 。至此 , 美国实务界 用了 2 0多年的时间构建了一个 司。 在 美 国 政 府 的 大 力支 持 下 , 国 现 在 是 世 界 上 最 大 软 件 产 品 生 比较 完 善 的软 件 成 本核 算体 系。S A 2 S A 8 美 F S 、 F S 6以及 S P 8 1 定 O 9— 制 产和 消费国 , 在技 术上处于领 先地位 , 对全球软件 行业起着 引导的 思 想 的 演 进 ,也 能 反 映 出整 个 发 达 国 家 软 件 成 本理 论 发 展 大 体 脉 作用 , 断着 全球超过 8 %的系统软件 、 垄 0 支撑软件和 网络应用软件 络 , 本 是 沿着 将 软 件 成 本 模 糊 地 分 为 费 用 化 费 用 和 资 本 化 费用 到 基 市 场 [ 1 】 。 比较清晰 的界定费用化和 资本化 的划 分点 , 再到按照线性时间划 分 1 美 国 软 件行 业 的 发 展 成 本 阶段 , 到 资 本 化 成 本 价 值 的反 映 , 至 到 自用 软 件 产 品 成 本 再 直 美 国在软件 行业的特殊地位 导致欧洲和世 界其他地 区的软 件 确 认 的轨 迹 。 成 本 研 究 一 直 落 后 于 美 国 。 国 的会 计 研 究 者 和软 件 工 程 师一 直 引 美 当F S A B不断完 善其软件产 品成本核算准则体 系的同时 , 国 美 领着软件成本研究的先进水平 。 美国会计实务界 ,A B 美国准则 在 F S( 管理 工 程 和 管 理 会 计 领 域 也 一 直 在 积 极 推 动 着 软 件 产 品 成 本 研 究 委员会) 早在 17 9 4年就发 S A 2 研究和开发成本 会计 》 但未能清 F S{ , 的前 进并且建树颇丰。这 两个领域 也 已经成为软件 产品成本研究 楚地界定软件成本的资本化和 费用化 的界 限问题 ;9 5年 F S 18 A B发 创 新 的主 要 方 向 。伴 随着 软 件 技 术 的发 展 , 多重 要 的软 件 工 程 管 许 布 s A 8《 F S6 出售 、 出租或 以其 它方式上市 的计 算机软件成 本会计》 理 思想和成本估算技术 不断推 陈出新 ,并成为推动 着软件成本研 将 软 件 成 本 分 为 四部 分 : 究 与开 发 费 用 、 研 生产 费 用 、 货 费 用 、 存 其 究 的 发 展 和 软 件 成 本 管 理 水 平 提 高 的 积 极 因素 。 美 国 早 期 的 软 件 他费用。SA 8 F S 6界定 自软 件 开 发 之 日至 获 得 技 术 可 行 日止 的 费 用 成本 管理 发源于一些 电子信 息产 品提供 商 ,在生产 实践中软件提 均 归入 研 究 与 开 发 费 用 并按 照 S A 2费 用 化 ;获 得 技 术 可 行 日之 FS 供 商们 已经感觉到传统 的成 本方法不能使他们得到 想要知道的软 从 为 作者简介 : 张路 (9 8 , , 17 一)男 河北 遵化人 , 会计硕士 , 研究方向为管理 会计。 件 成 本 信 息 , 而 影 响 了其 管 理 决 策 。 另 一 方 面 , 了 便 于 软 件 成
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

软件开发方法述评发信人:Joaquin(maverick),信区:SoftEng标题:软件开发方法评述发信站:BBS水木清华站(TueNov1821:18:341997)60年代中期开始爆发了众所周知的软件危机。

为了克服这一危机,在1968、1969年连续召开的两次著名的NATO会议上提出了软件工程这一术语,并在以后不断发展、完善。

与此同时,软件研究人员也在不断探索新的软件开发方法。

至今已形成八类软件开发方法。

一、Parnas方法最早的软件开发方法是由D.Parnas在1972年提出的。

由于当时软件在可维护性和可靠性方面存在着严重问题,因此Parnas提出的方法是针对这两个问题的。

首先,Parnas提出了信息隐蔽原则:在概要设计时列出将来可能发生变化的因素,并在模块划分时将这些因素放到个别模块的内部。

这样,在将来由于这些因素变化而需修改软件时,只需修改这些个别的模块,其它模块不受影响。

信息隐蔽技术不仅提高了软件的可维护性,而且也避免了错误的蔓延,改善了软件的可靠性。

现在信息隐蔽原则已成为软件工程学中的一条重要原则。

Parnas提出的第二条原则是在软件设计时应对可能发生的种种意外故障采取措施。

软件是很脆弱的,很可能因为一个微小的错误而引发严重的事故,所以必须加强防范。

如在分配使用设备前,应该取设备状态字,检查设备是否正常。

此外,模块之间也要加强检查,防止错误蔓延。

Parnas对软件开发提出了深刻的见解。

遗憾的是,他没有给出明确的工作流程。

所以这一方法不能独立使用,只能作为其它方法的补充。

二、 SASA方法1978年,E.Yourdon和L.L.Constantine提出了结构化方法,即SASD方法,也可称为面向功能的软件开发方法或面向数据流的软件开发方法。

1979年TomDeMarco对此方法作了进一步的完善。

Yourdon方法是80年代使用最广泛的软件开发方法。

它首先用结构化分析(SA)对软件进行需求分析,然后用结构化设计(SD)方法进行总体设计,最后是结构化编程(SP)。

这一方法不仅开发步骤明确,SA、SD、SP相辅相成,一气呵成,而且给出了两类典型的软件结构(变换型和事务型),便于参照,使软件开发的成功率大大提高,从而深受软件开发人员的青睐。

三、面向数据结构的软件开发方法Jackson方法1975年,M.A.Jackson提出了一类至今仍广泛使用的软件开发方法。

这一方法从目标系统的输入、输出数据结构入手,导出程序框架结构,再补充其它细节,就可得到完整的程序结构图。

这一方法对输入、输出数据结构明确的中小型系统特别有效,如商业应用中的文件表格处理。

该方法也可与其它方法结合,用于模块的详细设计。

Jackson方法有时也称为面向数据结构的软件设计方法。

Warnier方法1974年,J.D.Warnier提出的软件开发方法与Jackson方法类似。

差别有三点:一是它们使用的图形工具不同,分别使用Warnier图和Jackson图;另一个差别是使用的伪码不同;最主要的差别是在构造程序框架时,Warnier方法仅考虑输入数据结构,而Jackson方法不仅考虑输入数据结构,而且还考虑输出数据结构。

四、问题分析法PAM问题分析法。

PAM(ProblemAnalysisMethod)是80年代末由日立公司提出的一种软件开发方法。

PAM方法希望能兼顾Yourdon方法、Jackson方法和自底向上的软件开发方法的优点,而避免它们的缺陷。

它的基本思想是:考虑到输入、输出数据结构,指导系统的分解,在系统分析指导下逐步综合。

这一方法的具体步骤是:从输入、输出数据结构导出基本处理框;分析这些处理框之间的先后关系;按先后关系逐步综合处理框,直到画出整个系统的PAD图。

从上述步骤中可以看出,这一方法本质上是综合的自底向上的方法,但在逐步综合之前已进行了有目的的分解,这个目的就是充分考虑系统的输入、输出数据结构。

PAM方法的另一个优点是使用PAD图。

这是一种二维树形结构图,是到目前为止最好的详细设计表示方法之一,远远优于NS图和PDL语言。

这一方法在日本较为流行,软件开发的成功率也很高。

由于在输入、输出数据结构与整个系统之间同样存在着鸿沟,这一方法仍只适用于中小型问题。

五、面向对象的软件开发方法面向对象技术是软件技术的一次革命,在软件开发史上具有里程碑的意义。

随着OOP(面向对象编程)向OOD(面向对象设计)和OOA(面向对象分析)的发展,最终形成面向对象的软件开发方法OMT(LbjectModellingTechnique)。

这是一种自底向上和自顶向下相结合的方法,而且它以对象建模为基础,从而不仅考虑了输入、输出数据结构,实际上也包含了所有对象的数据结构。

所以OMT彻底实现了PAM没有完全实现的目标。

不仅如此,OO技术在需求分析、可维护性和可靠性这三个软件开发的关键环节和质量指标上有了实质性的突破,彻底地解决了在这些方面存在的严重问题,从而宣告了软件危机末日的来临。

自底向上的归纳OMT的第一步是从问题的陈述入手,构造系统模型。

从真实系统导出类的体系,即对象模型包括类的属性,与子类、父类的继承关系,以及类之间的关联。

类是具有相似属性和行为的一组具体实例(客观对象)的抽象,父类是若干子类的归纳。

因此这是一种自底向上的归纳过程。

在自底向上的归纳过程中,为使子类能更合理地继承父类的属性和行为,可能需要自顶向下的修改,从而使整个类体系更加合理。

由于这种类体系的构造是从具体到抽象,再从抽象到具体,符合人类的思维规律,因此能更快、更方便地完成任务。

这与自顶向下的Yourdon方法构成鲜明的对照。

在Yourdon方法中构造系统模型是最困难的一步,因为自顶向下的“顶”是一个空中楼阁,缺乏坚实的基础,而且功能分解有相当大的任意性,因此需要开发人员有丰富的软件开发经验。

而在OMT中这一工作可由一般开发人员较快地完成。

在对象模型建立后,很容易在这一基础上再导出动态模型和功能模型。

这三个模型一起构成要求解的系统模型。

自顶向下的分解系统模型建立后的工作就是分解。

与Yourdon方法按功能分解不同,在OMT中通常按服务(Service)来分解。

服务是具有共同目标的相关功能的集合,如I/O处理、图形处理等。

这一步的分解通常很明确,而这些子系统的进一步分解因有较具体的系统模型为依据,也相对容易。

所以OMT也具有自顶向下方法的优点,即能有效地控制模块的复杂性,同时避免了Yourdon方法中功能分解的困难和不确定性。

OMT的基础是对象模型每个对象类由数据结构(属性)和操作(行为)组成,有关的所有数据结构(包括输入、输出数据结构)都成了软件开发的依据。

因此Jackson方法和PAM中输入、输出数据结构与整个系统之间的鸿沟在OMT中不再存在。

OMT不仅具有Jackson方法和PAM的优点,而且可以应用于大型系统。

更重要的是,在Jackson方法和PAM方法中,当它们的出发点——输入、输出数据结构(即系统的边界)发生变化时,整个软件必须推倒重来。

但在OMT 中系统边界的改变只是增加或减少一些对象而已,整个系统改动极小。

需求分析彻底需求分析不彻底是软件失败的主要原因之一。

即使在目前,这一危险依然存在。

传统的软件开发方法不允许在开发过程中用户的需求发生变化,从而导致种种问题。

正是由于这一原因,人们提出了原型化方法,推出探索原型、实验原型和进化原型,积极鼓励用户改进需求。

在每次改进需求后又形成新的进化原型供用户试用,直到用户基本满意,大大提高了软件的成功率。

但是它要求软件开发人员能迅速生成这些原型,这就要求有自动生成代码的工具的支持。

OMT彻底解决了这一问题。

因为需求分析过程已与系统模型的形成过程一致,开发人员与用户的讨论是从用户熟悉的具体实例(实体)开始的。

开发人员必须搞清现实系统才能导出系统模型,这就使用户与开发人员之间有了共同的语言,避免了传统需求分析中可能产生的种种问题。

可维护性大大改善在OMT之前的软件开发方法都是基于功能分解的。

尽管软件工程学在可维护方面作出了极大的努力,使软件的可维护性有较大的改进。

但从本质上讲,基于功能分解的软件是不易维护的。

因为功能一旦有变化都会使开发的软件系统产生较大的变化,甚至推倒重来。

更严重的是,在这种软件系统中,修改是困难的。

由于种种原因,即使是微小的修改也可能引入新的错误。

所以传统开发方法很可能会引起软件成本增长失控、软件质量得不到保证等一系列严重问题。

正是OMT才使软件的可维护性有了质的改善。

OMT的基础是目标系统的对象模型,而不是功能的分解。

功能是对象的使用,它依赖于应用的细节,并在开发过程中不断变化。

由于对象是客观存在的,因此当需求变化时对象的性质要比对象的使用更为稳定,从而使建立在对象结构上的软件系统也更为稳定。

更重要的是OMT彻底解决了软件的可维护性。

在OO语言中,子类不仅可以继承父类的属性和行为,而且也可以重载父类的某个行为(虚函数)。

利用这一特点,我们可以方便地进行功能修改:引入某类的一个子类,对要修改的一些行为(即虚函数或虚方法)进行重载,也就是对它们重新定义。

由于不再在原来的程序模块中引入修改,所以彻底解决了软件的可修改性,从而也彻底解决了软件的可维护性。

OO技术还提高了软件的可靠性和健壮性。

六、可视化开发方法可视化开发是90年代软件界最大的两个热点之一。

随着图形用户界面的兴起,用户界面在软件系统中所占的比例也越来越大,有的甚至高达60~70%。

产生这一问题的原因是图形界面元素的生成很不方便。

为此Windows提供了应用程序设计接口API(Application Programming Interface),它包含了600多个函数,极大地方便了图形用户界面的开发。

但是在这批函数中,大量的函数参数和使用数量更多的有关常量,使基于Windows API的开发变得相当困难。

为此Borland C++推出了Object Windows编程。

它将API的各部分用对象类进行封装,提供了大量预定义的类,并为这些定义了许多成员函数。

利用子类对父类的继承性,以及实例对类的函数的引用,应用程序的开发可以省却大量类的定义,省却大量成员函数的定义或只需作少量修改以定义子类。

Object Windows还提供了许多标准的缺省处理,大大减少了应用程序开发的工作量。

但要掌握它们,对非专业人员来说仍是一个沉重的负担。

为此人们利用Windows API或Borland C++的Object Windows开发了一批可视开发工具。

可视化开发就是在可视开发工具提供的图形用户界面上,通过操作界面元素,诸如菜单、按钮、对话框、编辑框、单选框、复选框、列表框和滚动条等,由可视开发工具自动生成应用软件。

相关文档
最新文档