软件开发设计外文翻译--软件开发概念和设计方法_第1页
软件开发设计外文翻译--软件开发概念和设计方法_第2页
软件开发设计外文翻译--软件开发概念和设计方法_第3页
软件开发设计外文翻译--软件开发概念和设计方法_第4页
软件开发设计外文翻译--软件开发概念和设计方法_第5页
已阅读5页,还剩4页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1 中文 2780 字 外文资料原文 Software Development Concepts and Design Methodologies During the 1960s, mainframes and higher level programming languages were applied to many problems including human resource systems, reservation systems, and manufacturing systems. Comp uters and software were seen as the cure all for many business issues were sometimes applied blindly. Systems sometimes failed to solve the problem for which they were designed for many reasons including: Inability to sufficiently understand complex problems Not sufficiently taking into account end-user needs, the organizational environment, and performance tradeoffs Inability to accurately estimate development time and operational costs Lack of framework for consistent and regular customer communicatio ns At this time, the concept of structured programming, top -down design, stepwise refinement, and modularity emerged. Structured programming is still the most dominant approach to software engineering and is still evolving. These failures led to the concept of software engineering based upon the idea that an engineering-like discipline could be applied to software design and development. Software design is a process where the software designer applies techniques and principles to produce a conceptual model that describes and defines a solution to a problem. In the beginning, this design process has not been well structured and the model does not always accurately represent the problem of software development. However, design methodologies have been evolving to accommodate changes in technology coupled with our increased understanding of development processes. Whereas early design methods addressed specific aspects of the development process, current methods attempt to address the entire scope of 2 software development. Software design methods are often classified in reference to the period in which they were introduced and the problems at that time. Driven by coding and testing problems, tools and methods were developed. Early methods focused on modularity and top-down development, and information hiding through abstraction. This led to the development of structured languages, structured analysis, and data flow analysis. In the last decade or so, the expense involved in automation has shifted from hardware to pe ople. Therefore, the software engineering community has been focused on object oriented (O -O) design and the concept of re -usable code in order to reduce the human cost component. Inefficient designs and development methodologies have been addressed with C omputer Aided Software Engineering (CASE) tools, and fourth generation design languages. This has been done in an attempt replace the traditional waterfall life cycle process model under which most existing software has been developed. 一、 Software Design Fundamentals Software design methods all aim to provide the software designer with a system blueprint. This blueprint usually has three aspects: data, architectural, and procedural. Data design refers to the datas organization, relatio nships, access and processing methods. Architectural design defines the components of the system and their relationships. Procedural design builds on the data and architectural design phases to describe the processing details of the system. Even though there are numerous design methodologies, their basic concepts are very similar-All software design methods partition the problem and software into smaller pieces in order to reduce complexity. They all strive to identify data structures and functions, and p rovide measurements for software quality. Some of the common principles in software design include: stepwise refinement, software architecture, program structure, data structure, 3 software procedures, mod u la r i t y, ab s tr ac t io n, and in fo r ma t io n h i di ng. 二、 M o d e r n D e s i g n M e t h o d o l o g i e s C on ve n t ion a l so f t wa r e d e ve l op me nt p ra c t ic es ca n gen e ra l l y be map pe d o n to t he tr ad i t io na l l i f e -c yc l e p h a s e s o f a n a l ys i s , f u n c t i o na l s p e c i f i c a t i o n , d e s i g n, i mp l e me n t a t i o n , t e s t i n g , an d m a i n t e n a n c e . T h i s t h o u g h t p r o c e s s i s i n a d e q u a t e f o r t o d a y s c o m p l e x i n f o r m a t i o n s y s t e m s . As the demand for software is growing much faster than the number of developers, adhering to conventional techniques such as the waterfall method requires too much time, too many people, and is difficult to manage. H ence, many new software development technologies have arisen. N ewl y de veloped p ractice s and mode ls do not a tte mp t to separa te phases of softwa re development, such as specification and implementation, but instead focus on the concept of program transformation through stepwise refinement and iteration. 1 、 O b j e c t - O r i e n t e d Te c h n o l o g y Object-Oriented (O-O) software design technology is fundamentally different from the traditional methods described above. With traditional methods, each module is recognized a major step in the overall process and the process goes from one step to the next. On the other hand, O-O design is structured around a model of objects and the functions they perform. O-O programming can be traced to the simulation language SIMULA, a high level language developed in the late 60s that intro duced object classes as a method to encapsulate data. Later, in the 1970s, Smalltalk was introduced as a complete grapgh design and coding as detail is added to the design. This provides a common language throughout each stage in development. O -O is best applied with specifically designed O-O development tools, but it is important to remember that as a methodology is it not specific to any programming language. Many different programming languages can be used to implement 0-0 technology and design methodolo gies. Instead of procedures and functions passing data back and forth, in object oriented design, the system is viewed as a collection of objects with messages 4 passed from object to object. Each object has its own set of associated operations. Object-oriented design is based on the idea of information hiding and modularization of both data and processing. It is best used when neither data structure nor processing operations are well defined ahead of time. This is quite useful in todays business environment where requirements are always changing and not very well defined. Thus, it has become quite popular! The concept of objects performing services is a natural way of thinking for both developers and customers. This facilitates understanding the problem doma in and a more natural design. In addition, there are many benefits of object -oriented development. These include: In h e r i ta n c e c a p it a liz e s o n th e c o mmo n a lt y o f a tt r ib u te s a n d s e r v i c e s a l l o w i n g c o d e a n d objects to be re-used. .I n f o r m a t i o n h i d i n g m a k e s s y s t e m s m o r e s t a b l e b y l o c a l i z i n g c h a n g e s t o o b j e c t s a n d t h e r e b y m a k i n g t h e m r e u s a b l e . .T h e o b j e c t - o r i e n t e d d e v e l o p m e n t p r o c e s s i s c o n s i s t e n t f r o m a n a l y s i s , t h r o u g h d e s i g n , t o c o d i n g . More information on Object Oriented Programming principles can be found in Chapter 4-Organization of Programming Languages and Programming Concepts. 2 、 P r o t o t yp i n g Prototyping was invented because end users participating in the development phase found it difficult to understand requirement specifications and conceptual models. How ever, when it first began being used in the 1980s, most conventional life cycle developers considered it expensive and time consuming. S i n c e t h a t t i m e , u s e r s a n d d e v e l o p e r s h a v e u s e d p r o t o t yp e s s u c c e s s f u l l y a s a communications tool to demonstrate system re quirements. After several prototype iterations, developers have a better understanding of user requirements and users have a better idea of how the system will eventually work, look, and l. T he nu mb er of t i me s th e p ro to t yp e is in c re men t a l l y r e f ine d de pe nds on 5 how we l l the u se r r eq ui re me n ts a nd un de r s t ood . It a ls o dep en ds o n th e us er s nee d to a dd req u ir e men ts o r ch an ge p r e v i o u s l y s t a t e d r e q u i r e m e n t s . A f t e r e s t a b l i s h i n g a n o ve r a l l a r c h i t e c t u r e a n d f r a me w o r k , t h e s ys t e m i s de ve l ope d and de l i ve re d in inc r e men ts . U se r s ma y e xpe r i men t w i t h a nd u se de l i ve red i n c r e me n t s w h i l e o t h e r s a r e be i n g d e v e l o p ed . Fo r i n s t a n c e , t h e f i r s t p r o t o t yp e ma y b e d e l i ve r e d t h a t i m p l e m e n t s a c e r t a i n s c r e e n w i t h o n l y s o m e a c t i v e m e n u i t e m s . W h i l e u s e r s a r e e x p e r i me n t i n g w i t h t h i s sc r e e n a nd me n u i t e ms , o t h e r s c r e en s a n d me n u i t e ms a r e c o n c u r r e n t l y b e in g de vel op ed wh i ch la t e r w il l be co mb in ed w i th th e e x is t in g p ro to t ype a s it e vo l ves . O n c e t h e u s e r i s s a t i s f i e d t h a t t h e p r o t o t y p e m e e t s r e q u i r e m e n t s , t h e p r o t o t y p e i s t ran s fo r med i n to the s ys t e m. T h i s e ffo r t d epe nd s on se ve ra l fa c to rs . It ma y i n c lu d e add i ng f u n c t i o n a l i t y t h a t w a s n t i n i t i a l l y r e c o g n i z e d a s r e q u i r e d , r e p l a c i n g i n e f f i c i e n t p a r t s o f t h e p r o t o t yp e t o me e t p e r f o r ma n c e c r i t e r i a , o r ad a p t i n g t h e p r o t o t yp e t o f i t t h e u s e r s h a r d w a r e envi ron ment. P r o t o t y p i n g c a n b e g i n v e r y e a r l y, a f t e r s o m e p r e l i m i n a r y r e q u i r e m e n t s a n a l y s i s h a s d e t e r m i n e d t h e b a s i c f u n c t i o n a l i t y, s c o p e , a n d e n v i r o n m e n t o f t h e p r o p o s e d s o f t w a r e . C o n t r a r y t o t h e t r a d i t i o n a l w a t e r f a l l me t h o d , i n t h e p r o t o t yp i n g , f u n c t i o n a l s p e c i f i c a t i o n s a r e n o t f i x e d . R a t h e r, u s e r s a r e e n c o u r a g e d t o m o d i f y t h e i r r e q u i r e m e n t s a s t h e y t h e m s e l v e s b e g i n t o u nd e r s t a n d t h e m b e t t e r. T h i s i s b e c a u s e u s e r s o f t e n d o n t r e a l l y k n o w w h a t t h e y w a n t u n t i l t h e y s e e i t o n t h e s c r e e n . T he p r o t o t yp i n g p r oc e s s o f d e mo n s t r a t i o n , r e v i e w, a nd r e f i n e me n t g e t s t h e u s e r m o r e i n v o l ve d i n t h e d e ve l o p m e n t p r o c e s s , g i v i n g t h e m a s e n s e o f o w n e r s h i p d u r i n g t h e p r o c e s s a n d a t f i n a l s ys t e m d e l i v e r y. H o w e v e r, d u e t o t h e m i n d s e t o f p r o t o t yp e , u s e r s o f t e n find i t diff icu l t to ve rif y t hat the proto t ype sa tis fies their require men ts. T here fore, guidel ines must b e e st ab l i she d t o d e te r m in e wh en t o s top i te ra t in g and the p ro to t yp e to f in a l pr oduc t . 6 外文资料译文 软件开发概念和设计方法 在 20 世纪 60 年 代 , 大 型 机 和 高 级 程 序 语 言 被 用 来 解 决 包 括 人 力 资 源 系统 、 专 有 系 统 和 制 造 系 统 等 许 多 问 题 。 计 算 机 和 软 件 被 视 为 解 决 所 有 商 业 问题 的 万 能 药 , 有 时 候 甚 至 被 盲 目 的 应 用 。 因 为 很 多 设 计 上 的 原 因 , 这 些 系 统并 不 是 万 能 的 。 主 要 因 素 如 下 : 1 不 能 完 全 理 解 复 杂 的 问 题 2 没 有 充 分 满 足 终 端 用 户 的 需 求 , 组 织 环 境 和 性 能 折 中 3 没 有 准 确 估 计 开 发 时 间 和 运 行 成 本 4 缺 乏 一 致 , 规 范 的 客 户 通 讯 框 架 这 个 时 候 , 结 构 化 的 编 程 , 自 上 而 下 设 计 的 概 念 出 现 了 。 对 软 件 工 程 来说 ,结 构 化 编 程 至 今 仍 是 最 重 要 的 方 法 且 不 断 发 展 。“ 软 件 工 程 ”概 念 的 出 现则 是 基 于 这 样 的 构 想 :一 个 类 似 工 程 学 的 学 科 可 以 应 用 于 软 件 的 设 计 和 开 发 。 软 件 设 计 是 一 种 方 法 , 软 件 设 计 人 员 可 以 籍 此 应 用 技 术 和 规 则 生 成 一 种描述并 定义问题解决方法的模型。最初,设计方法一直未能构建好,而且模型也不能准确地描述软件开发的问题。然而,随着我们对开发过程的深入理解,设计方法已经不断适应技术的变化了。 生命周期过程的模型下开发的,但人们开始尝试寻找这种模型的替代品。 一、 软件设计基础 软件设计方法最终的目标就是向软件设计者提供一张系统蓝图。它通常有三个方面: 数据,构架和过程。 数据设计指的是数据的组织、关系、访问和处理方法。 构架设计定义系统组件和它们之间的关系。 过程设计建立在数据和构架设计阶段之上描述系统的处理细节。 尽管设计方法众多,但它们的基本概念非常相似。为了减少复杂度,几乎所有软件设计方法都把问题和软件分割成较小的部分用于标识数据结构、功能以及度量软件品质。软件设计包括以下这些普遍原则:逐步求精、软件构架、程序结构、数据结构、软件过程、模块化、抽象和信息隐藏。 7 二、 现代设计方法 常规的软件开发实践通常能被映射到传统的生命阶段上,包括分析、功能说明、设计、实现、测试和维护。然而对软件需求的增长比软件开发者数量增长 要 快 , 遵 守 常 规 的 技 术 你 瀑 布 模 型 ) 耗 时 太 长 , 过 多 人 员 的 参 与 也 带 来 了管 理 上 的 困 难 , 显 然 常 规 的 思 考 过 程 对 于 今 天 的 复 杂 信 息 系 统 是 不 够 的 。 因此 , 产 生 了 许 多 新 的 软 件 开 发 技 术 。 最 新 发 展 出 的 实 践 和 模 型 井 不 试 图 把 软件 开 发 分 割 成 多 个 阶 段( 如 说 明 和 实 现 ),而 是 注 重 于 通 过 逐 步 求 精 和 迭 代 把概 念 转 换 成 程 序 。 1、 面 向 对 象 的 技 术 面 向 对 象 的 软 件 设 计 技 术 从 根 本 上 有 别 于 传 统 的 设 计 方 法 。传 统 方 法 中 ,每 个 模 块 被 当 作 全 局 过 程 的 一 个 主 要 步 骤 , 一 步 一 步 地 往 下 走 ; 而 面 向 对 象的 设 计 围 绕 着 对 象 模 型 和 对 象 所 执 行 的 功 能 进 行 结 构 化 。 面 向 对 象 的 编 程 可 以 追 溯 到 仿 真 语 言 SIMULA。 SIMULA 是一种 20 世纪 60年 代 后 期 的 高 级 语 言 ,引 入 了“ 对 象 类 ”作 为 封 装 数 据 的 方 法 。到 了 20 世纪70 年代, Smalltalk 被 作 为 一 种 完 全 的 图 形 用 户 界 面( GUI)面 向 对 象 的 编 程环 境 被 引 入 。甚 至 在 30 年以后, Smalltalk 仍 然 是 度 量 其 他 所 有 面 向 对 象 语言 的 标 准 。 由 于 面 向 对 象 的 概 念 日 趋 成 熟 , 最 近 十 年 这 种 软 件 开 发 方 法 已 经流 行 起 来 。 同 时 , 软 件 业 注 意 的 焦 点 己 经 从 编 码 和 结 构 化 过 程 转 移 到 通 过 设计 和 柔 韧 性 来 节 省 劳 动 力 成 本 和 时 间 。 柔 韧 性 变 得 十 分 关 键 , 因 为 系 统 随 着需 求 的 变 化 而 快 速 改 变 : 变 得 更 大 , 更 复 杂 和 更 不 稳 定 。 在 面 向 对 象 中 , 分 析 和 设 计 没 有 真 正 分 开 。 在 分 析 期 间 , 系 统 对 象 及 其特 性 和 关 系 一 起 被 确 定 。 这 些 对 象 可 以 护 , 这 样 就 给 整 个 开 发 过 程 中 的 所 有阶 段 提 供 了 一 种 公 用 的 语 言 。 采 用 面 向 对 象 方 法 最 好 是 使 用 专 门 设 计 的 面 向对 象 的 开 发 工 具 , 但 是 请 一 定 记 住 它 是 一 种 方 法 而 不 是 特 指 任 何 编 程 语 言 。许 多 不 同 的 编 程 语 言 都 可 以 用 来 实 现 面 向 对 象 技 术 和 设 计 方 法 。 和 过 程 、 功 能 往 返 传 递 数 据 的 方 式 不 同 , 在 面 向 对 象 的 设 计 中 , 系 统 被看 成 一 个 由 很 多 互 相 传 递 消 息 的 对 象 组 成 的 集 合 , 每 个 对 象 都 有 它 自 己 关 联操 作 的 集 合 。 面 向 对 象 的 设 计 基 本 构 想 是 把 数 据 和 过 程 进 行 信 息 隐 藏 和 模 块化 , 它 最 适 用 于 数 据 结 构 或 者 过 程 操 作 没 有 被 提 前 的 定 义 好 的 情 况 。 这 对 于今 天 的 商 业 环 境 中 相 当 有 用 , 毕 竟 需 求 总 是 不 断 改 变 而 不 能 很 好 的 定 义 。 这 8 也 是 面 向 对 象 的 设 计 现 在 相 当 流 行 的 重 要 原 因 。 对 象 执 行 服 务 的 概 念 是 一 种开 发 者 和 客 户 都 很 自 然 的 思 考 方 法 , 这 有 利 于 理 解 问 题 的 范 围 , 也 是 一 种 更加 自 然 的 设 计 。 此 外 , 面 向 对 象 的 开 发 还 有 许 多 优 点 。 通 过 属 性 和 服 务 的 结 合 使 用 , 继 承 可 以 重 用 代 码 和 对 象 。 信 息 隐 藏 通 过 局 限 对 象 的 变 化 使 系 统 更 加 稳 定 , 从 而 使 对 象 可 以 重 用 面 向 对 象 的 开 发 过 程 从 分 析 、 设 计 到 编 码 都 是 一 致 的 。 2、原型法 原 型 法 的 出 现 是 因 为 参 于 开 发 阶 段 的 终 端 用 户 觉 得 很 难 理 解 需 求 说 明 和概 念 模 型 。 而 当 原 型 法 在 20 世纪 80 年 代 第 一 次 被 使 用 时 , 大 部 分 常 规 的 生命 周 期 开 发 者 认 为 它 费 时 费 力 。 但 从 那 时 开 始 , 用 户 和 开 发 者 已 经 能 成 功 地应 用 原 型 作 为 通 讯 工 具 来 演 示 系 统 的 需 求 。 原 型 多 次 迭 代 后 , 开 发 者 对 用 户的 需 求 有 了 更 好 的 理 解 , 用 户 也 对 系 统 最 后 如 何 操 作 、 看 起 来 像 什 么 和 如 何感 觉 都 有 所 了 解 。原 型 法 已 经 被 证 明 是 一 种 理 解 用 户 需 求 和 问 题 的 有 效 方 法 ,它 有 效 地 消

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论