軟件開發(fā)設(shè)計(jì)外文翻譯文獻(xiàn)

1、外文資料原文 Software Development Concepts and Design Methodologies During the 1960s, ma inframes and higher level programming languages were applied to man y problems including human resource syste ms, reservation syste ms, and manufacturing syste ms. Computers and software were seen as the cure all for

2、man y bu siness issues were sometimes applied blindly. Syste ms sometimes failed to solve the problem for which the y were designed for man y reasons including: ?Inability to sufficiently understand complex problems ?Not sufficiently taking into account end -u ser needs, the organizational environ m

3、ent, and performance tradeoffs ?Inability to accurately estimate development time and operational costs ?Lack of framework for consistent and regular customer communications At this time, the concept of structured programming,top -down design, stepwise refinement ， and modularity emerged. Structured

4、 programmingis 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 disciplinecould be applied to software design and develop ment. Software design is a process where th

5、e software designer applies techniques and principles to produce a conceptual model that de scribes and defines a solution to a problem. In the beginning, this design process has not been well structured and the model does not alwa ys accurately represent the problem of software development. However

6、, design methodologies have been evolving to accommo date changes in technolog y coupled with our increased understanding of development processes. Whereas early desig n methods addressed specific aspects of the develop ment process, current methods atte mpt to address the entire scope of softwarede

7、velopment. Software design methods are often classified in reference to the period in which the y were introduced and the problems at that time. Driven by coding and testing problems, tools and methods were developed. Early methods focused on modularityand top -down development,and information hidin

8、g 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 people. Therefore, the software engineering community has been focused on object oriented

9、(O-O) design and the concept of re-usable code in order to reduce the human cost component. Inefficientdesigns and develop ment methodologies have been addressed with Comput er Aided Software Engineering (CASE) tools, and fourth generation design languages. This has been done in an attempt replace t

10、he traditional waterf all life cycle process model under which most existing software has been developed. 一 、 Software Design Fundamentals Software design meth ods all aim to provide the software designer with a syste m blueprint. This blueprint usually has three aspects: data, architectural, and pr

11、ocedural. ?Data design refers to the data s organization, relationships, access and processing methods. ?Architectural design defines the components of the sys tem and their relationships. ?Procedural design builds on the data and architectural design phases to describe the processing details of the

12、 syste m. Even though there are numerous design methodologies, their basic concepts are ver y similar -All software design methods partition the problem and software into smaller pieces in order to reduce complexity. They all strive to identif y data structures and functions, and provide measur emen

13、ts for software quality. Some of the common principles in software design include: stepwise refinement, software architecture, program structure, data structure, software procedures, modularity, abstraction, and information hiding. 二、 Modern Design Methodologies Conven ti o nal sof twa r e developme

14、 nt pract ic es can gen eral ly be ma pped onto the tr ad i ti onal l if e-cy cl e p hases of an al ys i s, fun cti onal speci f icati on, d esi g n, impleme ntatio n, t est ing, and maintenan ce. This t houg ht p rocess i s in ad eq u ate f or t od ays complex i nf ormati on s y st em s. As the dem

15、a nd for software is grow ing much faster tha n the nu mber of developers, adheri ng to conven ti onal tech niq ues such as the waterfall method requires too much time, too many people,and is difficult to man age. Hence, many new software developme nt tech no logies have arise n.N ewl y deve lo ped

16、pr actic es and mo dels do not atte mp t to separate phases of softwa re development, such as specificatio n and impleme ntati on, but in stead focus on the con cept ofprogram tran sformati on through stepwise refineme nt and iterati on. 1、Object- Or i e nted Te c h no logy Object-Orie nted (O -O) s

17、oftware desig n tech no logy is fun dame ntally differe nt from the traditi onal methods described above. With traditi onal methods, each module is recog ni zed amajor step in the overall process and the process goes from one step to the n ext. On the otherhand, O-O desig n is structured around a mo

18、del of objects and the functions they perform. O-O programming can be traced to the simulation Ianguage SIMULA, a high level Ianguage developed in the late 60s that introducedobject classes as a method to encapsulate data. Later, in the 1970s, Smalltalkwas introducedas a complete grapgh desig n and

19、codi ng as detail is added to the desig n. This provides a com mon Ian guage throughout each stage in deve lopme nt. O -O is best applied with specifically desig ned O-O developme nt tools, but it is importa nt to remember that as a methodology is it not specific to any programmingIanguage. Many dif

20、fere nt program ming Ian guages can be used to impleme nt0-0 tech no logy and desig n methodologies. In stead of procedures and functionspass ing data back and forth,in object erati ons. oriented design, the system is viewed as a collectionof objects with messages passed from object to object. Each

21、object has its own set of associated op Object-orie nteddesig n is based on the idea of in formati onhid ingand modularizationof both data and processing.It is best used when neither data structurenor processing operations are well defined ahead of time. This is quite useful in todays bus in ess env

22、ironment where requireme nts are always cha nging and not very well defined.Thus, it has become quite popular! The concept of objects perform ingservices is a n atural way of th inkingfor both developers and customers.This facilitates understanding the problemdomain and a more natural desig n. In ad

23、diti on, there are many ben efits of object-orie nted developme nt. These in clude: ? In h e r i t a nee capitalizes on t h e com mon al ty o f a tt ri b u t es and services a 11 o w i ng code and objects to be re-used. .Inf ormati on h i d ing makes sy stem s more stable b y l o c al i z ing cha ng

24、es t o objects and thereby m ak ing them re u sa b l e. .The o bj ect - o r i e nted devel opme nt process i s con s i st e nt from an a l y s i s, through desig n, t o co d i ng. More in formatio n on Object Orien ted Programmi ng principles can be found in Chapter4-Orga ni zati onof Program mingLa

25、n guagesand Program ming Con cepts. 2、 Pro tot y p ing Prototyp ing was inven ted because end users participat ing in the developme nt phase found it difficult toun dersta ndrequireme ntspecificati ons and conceptual models. However, when it first began being used in the 1980s, most conven ti on al

26、life cycle developers con sidered itexpe nsive and time consuming. Since th at time, users and d e vel o pers h ave used p rot oty pes successfu 11 y as a com muni cati onstool to dem on strate system requireme nts. After several prototype iterations, developers have a better understanding of user r

27、equireme nts and users have a better idea of how the system will even tually work, look, and l. The nu mb er of ti me s th e p r oto typ e is in creme ntally ref in ed depe nds on how we ll th e user requi rements and underst ood. 11 als o depends on th e users need to add req uir eme nts or change

28、previ ousl y stated r equi rem ents. A fter establishing an overall architecture and framework, the system i s developed and del ivered in in creme nts. Users may experime nt with and use del i vered in creme nts while others are being d ev el o ped. Fo r in st a nee, t he f i r st p rot otyp e ma y

29、 be d el i vered t hat i m p l e m e nts a certa in scree n with only some act i v e menu items. While users are ex p er i me nting with th i s scree n and menu items, other scree ns and menu items are con c urre ntly bei ng d evel oped wh i ch la t er wil l be comb i n ed w i th th e exis ti ng p r

30、oto typ e as it evo l ves. Once t he user i s sati sf i ed t hat the p roto typ e meets requ i re me nts, the prototype i s tra nsformed into th e sys t em. This eff or t depe nds on several facto rs. I t ma y i n clu de add ing fun ct i on a l i ty t hat was nt i ni ti al l y r ecog ni zed as req u

31、 i r ed , repl ac ing in eff icie nt parts of t he p rot otyp e to me et perf orma nee c rit er i a, o r adapt ing th e prototyp e to fit the users hardware en vi ron me nt. Pr ototy p ing can b eg in very e ar l y, a ft er some prelim in ary r equ i reme nts an al y si s h as d eter m ined the basi

32、 c fun ct i on al i t y, scope, and en vi r onment of the p ro posed sof tw are. Con trar y to the tr adi ti onal w at erf al l me th od , in the prot otyp i ng, funct ional speci fi cat ions are not fi xed. Rath er, users ar e en cou r ag ed to modify t hei r r eq u i r e me nts as t hey t hem sel

33、ves beg in t o understand them better. This i s because users often dont reall y know w hat they want unti l they see i t on the screen. The prototyp i ng process of dem on strati o n, rev i ew, and ref in eme nt gets the user m ore in v ol ved in the d evel op m e nt pro cess, g i v ing them a sens

34、e of own ershi p dur ing the process and at final syst em del i very. H ow eve r, due to the min dset of pro toty pe, users of te n find i t d iff ic ul t to ve rif y th at th e proto typ e satis fie s th eir requ ir eme nts. T heref ore, g u id el in es mu st b e est abl i shed t o d ete rm in e wh

35、 en to sto p i te rati ng and th e pr o to t yp e to fin al product. 外文資料譯文 軟件開發(fā)概念和設(shè)計(jì)方法 在 20 世 紀(jì) 60 年 代 ， 大 型 機(jī) 和 高 級(jí) 程 序 語(yǔ) 言 被 用 來(lái) 解 決 包 括 人 力 資 源 系 統(tǒng)、專有系統(tǒng)和制造系統(tǒng)等許多問題。計(jì)算機(jī)和軟件被視為解決所有商業(yè)問 題的萬(wàn)能藥，有時(shí)候甚至被盲目的應(yīng)用。因?yàn)楹芏嘣O(shè)計(jì)上的原因，這些系統(tǒng) 并不是萬(wàn)能的。主要因素如下： 1 不 能 完 全 理 解 復(fù) 雜 的 問 題 2 沒 有 充 分 滿 足 終 端 用 戶 的 需 求 ， 組 織 環(huán) 境 和 性 能

36、 折 中 3 沒 有 準(zhǔn) 確 估 計(jì) 開 發(fā) 時(shí) 間 和 運(yùn) 行 成 本 4 缺 乏 一 致 ， 規(guī) 范 的 客 戶 通 訊 框 架 這個(gè)時(shí)候，結(jié)構(gòu)化的編程，自上而下設(shè)計(jì)的概念出現(xiàn)了。對(duì)軟件工程來(lái) 說(shuō) ，結(jié) 構(gòu) 化 編 程 至 今 仍 是 最 重 要 的 方 法 且 不 斷 發(fā) 展 ?！?軟 件 工 程 ”概 念 的 出 現(xiàn) 則 是 基 于 這 樣 的 構(gòu) 想 ：一 個(gè) 類 似 工 程 學(xué) 的 學(xué) 科 可 以 應(yīng) 用 于 軟 件 的 設(shè) 計(jì) 和 開 發(fā) 。 軟件設(shè)計(jì)是一種方法，軟件設(shè)計(jì)人員可以籍此應(yīng)用技術(shù)和規(guī)則生成一種 描述并定義問題解決方法的模型。最初，設(shè)計(jì)方法一直未能構(gòu)建好，而且模型 也不

37、能準(zhǔn)確地描述軟件開發(fā)的問題。然而，隨著我們對(duì)開發(fā)過程的深入理解， 設(shè)計(jì)方法已經(jīng)不斷適應(yīng)技術(shù)的變化了。 生命周期過程的模型下開發(fā)的，但人們開始嘗試尋找這種模型的替代品。 一、 軟件設(shè) 計(jì)基礎(chǔ) 軟件設(shè)計(jì)方法最終的目標(biāo)就是向軟件設(shè)計(jì)者提供一張系統(tǒng)藍(lán)圖。它通常有 三個(gè)方面：數(shù)據(jù)，構(gòu)架和過程。 數(shù)據(jù)設(shè)計(jì)指的 是數(shù)據(jù)的組 織、關(guān) 系、訪問和處 理方法 。 構(gòu)架設(shè)計(jì)定義系統(tǒng)組件和它們之間的關(guān)系。 過程設(shè)計(jì)建立在數(shù)據(jù)和構(gòu)架設(shè)計(jì)階段之上描述系統(tǒng)的處理細(xì)節(jié)。 盡管設(shè)計(jì)方法眾多，但它們的基本概念非常相似。為了減少?gòu)?fù)雜度，幾乎 所有軟件設(shè)計(jì)方法都把問題和軟件分割成較小的部分用于標(biāo)識(shí)數(shù)據(jù)結(jié)構(gòu)、功能 以及度量軟件品質(zhì)。軟

38、件設(shè)計(jì)包括以下這些普遍原則：逐步求精、軟件構(gòu)架、 程序結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)、軟件過程、模塊化、抽象和信息隱藏。 二 、 現(xiàn)代 設(shè) 計(jì)方 法 常規(guī)的軟件開發(fā)實(shí)踐通常能被映射到傳統(tǒng)的生命階段上，包括分析、功能 說(shuō)明、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試和維護(hù)。然而對(duì)軟件需求的增長(zhǎng)比軟件開發(fā)者數(shù)量增 長(zhǎng)要快，遵守常規(guī)的技術(shù)你瀑布模型）耗時(shí)太長(zhǎng)，過多人員的參與也帶來(lái)了 管理上的困難，顯然常規(guī)的思考過程對(duì)于今天的復(fù)雜信息系統(tǒng)是不夠的。因 此，產(chǎn)生了許多新的軟件開發(fā)技術(shù)。最新發(fā)展出的實(shí)踐和模型井不試圖把軟 件 開 發(fā) 分 割 成 多 個(gè) 階 段（ 如 說(shuō) 明 和 實(shí) 現(xiàn) ），而 是 注 重 于 通 過 逐 步 求 精 和 迭 代

39、把 概念轉(zhuǎn)換成程序。 1、 面 向 對(duì) 象 的 技 術(shù) 面向?qū)ο蟮能浖O(shè)計(jì) 技術(shù)從根本上有別于傳統(tǒng)的設(shè)計(jì)方法。傳統(tǒng)方法中， 每個(gè)模塊被當(dāng)作全局過程的一個(gè)主要步驟，一步一步地往下走；而面向?qū)ο?的設(shè)計(jì)圍繞著對(duì)象模型和對(duì)象所執(zhí)行的功能進(jìn)行結(jié)構(gòu)化。 面向?qū)ο蟮木幊炭梢宰匪莸椒抡嬲Z(yǔ)言SIMULA。SIMULA是一種20世紀(jì)60 年代后期的高級(jí)語(yǔ)言，引 入了“ 對(duì)象類”作 為封裝數(shù)據(jù)的 方法。到 了 20 世紀(jì) 70年代，Smalltalk 被作為一種完全的圖形用戶界面（GUI ）面向?qū)ο蟮木幊?環(huán)境被引入。甚 至在 30 年以后， Smalltalk 仍然是度量其他所有面向?qū)ο笳Z(yǔ) 言 的標(biāo)準(zhǔn)。 由于面

40、向?qū)ο蟮母拍钊遮叧墒欤?最近十年這種軟件開發(fā)方法已經(jīng) 流行起來(lái)。 同時(shí)， 軟件業(yè)注意的焦點(diǎn)己經(jīng)從編碼和結(jié)構(gòu)化過程轉(zhuǎn)移到通過設(shè) 計(jì)和柔韌性來(lái)節(jié)省勞動(dòng)力成本和時(shí)間。柔韌性變得十分關(guān)鍵，因?yàn)橄到y(tǒng)隨著 需求的變化而快速改變：變得更大，更復(fù)雜和更不穩(wěn)定。 在 面 向 對(duì) 象 中 ， 分 析 和 設(shè) 計(jì) 沒 有 真 正 分 開 。 在 分 析 期 間 ， 系 統(tǒng) 對(duì) 象 及 其 特性和關(guān)系一起被確定。這些對(duì)象可以護(hù)，這樣就給整個(gè)開發(fā)過程中的所有 階段提供了一種公用的語(yǔ)言。采用面向?qū)ο蠓椒ㄗ詈檬鞘褂脤ｉT設(shè)計(jì)的面向 對(duì) 象 的 開 發(fā) 工 具 ， 但 是 請(qǐng) 一 定 記 住 它 是 一 種 方 法 而 不 是 特 指 任 何 編 程 語(yǔ) 言 。 許多不同的編程語(yǔ)言都可以用來(lái)實(shí)現(xiàn)面向?qū)ο蠹夹g(shù)和設(shè)計(jì)方法。 和過程、功能往返傳遞數(shù)據(jù)的方式不同，在面向?qū)ο蟮脑O(shè)計(jì)中，系統(tǒng)被 看成一個(gè)由很多互相傳遞消息的對(duì)象組成的集合，每個(gè)對(duì)象都有它自己關(guān)聯(lián) 操作的集合。面向?qū)ο蟮脑O(shè)計(jì)基本構(gòu)想是把數(shù)據(jù)和過程進(jìn)行信息隱藏和模塊 化，它最適用于數(shù)據(jù)結(jié)構(gòu)或者過程操作沒有被提前的定義好的情況。這對(duì)于 今天的商業(yè)環(huán)境中相當(dāng)有用，畢竟需求總是不斷改變而不能很好的定義。這 也是面向?qū)ο蟮脑O(shè)計(jì)現(xiàn)在相當(dāng)流行的重要原因。對(duì)象執(zhí)行服務(wù)的概念是一種 開發(fā)者和客戶都很自然的思考方法，這