系統架構的設計方法(設計軟件系統結構的具體辦法)
1.設計軟件系統結構的具體辦法有哪些
結構化程序設計的思路是：自頂向下、逐步求精；其程序結構是按功能劃分為若干個(gè)基本模塊；各模塊之間的關(guān)系盡可能簡(jiǎn)單，在功能上相對獨立；每一模塊內部均是由順序、選擇和循環(huán)三種基本結構組成；其模塊化實(shí)現的具體方法是使用子程序。
結構化程序設計由于采用了模塊分解與功能抽象，自頂向下、分而治之的方法，從而有效地將一個(gè)較復雜的程序系統設計任務(wù)分解成許多易于控制和處理的子任務(wù)，便于開(kāi)發(fā)和維護。 雖然結構化程序設計方法具有很多的優(yōu)點(diǎn)，但它仍是一種面向過(guò)程的程序設計方法，它把數據和處理數據的過(guò)程分離為相互獨立的實(shí)體。
當數據結構改變時(shí)，所有相關(guān)的處理過(guò)程都要進(jìn)行相應的修改，每一種相對于老問(wèn)題的新方法都要帶來(lái)額外的開(kāi)銷(xiāo)，程序的可重用性差。由于圖形用戶(hù)界面的應用，程序運行由順序運行演變?yōu)槭录寗?dòng)，使得軟件使用起來(lái)越來(lái)越方便，但開(kāi)發(fā)起來(lái)卻越來(lái)越困難，對這種軟件的功能很難用過(guò)程來(lái)描述和實(shí)現，使用面向過(guò)程的方法來(lái)開(kāi)發(fā)和維護都將非常困難。
2.系統架構方案有哪些
系統架構屬于系統設計階段，系統架構圖只是這個(gè)階段一個(gè)產(chǎn)物，要正確的、合理的畫(huà)系統架構圖需要全面的理解用戶(hù)需求以及業(yè)務(wù)流程，當理解了這些東西后，剩下的就是如何進(jìn)行表達了，一般而言，可以參照RUP的用例驅動(dòng)來(lái)進(jìn)行邏輯架構，開(kāi)發(fā)架構等設計工作，你的系統架構圖可以反應在各個(gè)視圖里面，我估計你所說(shuō)的系統架構圖是屬于邏輯架構里面，比如分多少層，每層分多少模塊等。
至于，繪制的工具，有很多很多。可以選擇微軟的visio，或者EA,rose,power designer等UML建模工具，當然，你甚至可以用PPT,Word來(lái)繪制。
當然，系統架構不是一日之功，需長(cháng)期努力，跟經(jīng)驗和技術(shù)都有很大關(guān)系。
今天興致來(lái)了，回復了這么多，不知滿(mǎn)意不。
3.系統架構方案有哪些
系統架構屬于系統設計階段，系統架構圖只是這個(gè)階段一個(gè)產(chǎn)物，要正確的、合理的畫(huà)系統架構圖需要全面的理解用戶(hù)需求以及業(yè)務(wù)流程，當理解了這些東西后，剩下的就是如何進(jìn)行表達了，一般而言，可以參照RUP的用例驅動(dòng)來(lái)進(jìn)行邏輯架構，開(kāi)發(fā)架構等設計工作，你的系統架構圖可以反應在各個(gè)視圖里面，我估計你所說(shuō)的系統架構圖是屬于邏輯架構里面，比如分多少層，每層分多少模塊等。
至于，繪制的工具，有很多很多。可以選擇微軟的visio，或者EA,rose,power designer等UML建模工具，當然，你甚至可以用PPT,Word來(lái)繪制。
當然，系統架構不是一日之功，需長(cháng)期努力，跟經(jīng)驗和技術(shù)都有很大關(guān)系。 今天興致來(lái)了，回復了這么多，不知滿(mǎn)意不。
4.面向對象的設計中,系統架構設計的內容有哪些
面向對象程序設計中的概念主要包括：對象、類(lèi)、數據抽象、繼承、動(dòng)態(tài)綁定、數據封裝、多態(tài)性、消息傳遞。通過(guò)這些概念面向對象的思想得到了具體的體現。
1）對象（Object） 可以對其做事情的一些東西。一個(gè)對象有狀態(tài)、行為和標識三種屬性。
2）類(lèi)（class） 一個(gè)共享相同結構和行為的對象的集合。
類(lèi)（Class）定義了一件事物的抽象特點(diǎn)。通常來(lái)說(shuō)，類(lèi)定義了事物的屬性和它可以做到的（它的行為）。舉例來(lái)說(shuō)，“狗”這個(gè)類(lèi)會(huì )包含狗的一切基礎特征，例如它的孕育、毛皮顏色和吠叫的能力。類(lèi)可以為程序提供模版和結構。一個(gè)類(lèi)的方法和屬性被稱(chēng)為“成員”。
5.如何做好軟件系統的架構設計
軟件架構設計的目的 對于外包業(yè)務(wù)類(lèi)型的項目，軟件架構設計的目的與產(chǎn)品類(lèi)型的項目有所不同，在這里主要討論外包類(lèi)型項目的軟件架構設計目的。
1、為大規模開(kāi)發(fā)提供基礎和規范，并提供可重用的資產(chǎn)，軟件系統的大規模開(kāi)發(fā)，必須要有一定的基礎和遵循一定的規范，這既是軟件工程本身的要求，也是客戶(hù)的要求。架構設計的過(guò)程中可以將一些公共部分抽象提取出來(lái)，形成公共類(lèi)和工具類(lèi)，以達到重用的目的。
2、一定程度上縮短項目的周期，利用軟件架構提供的框架或重用組件，縮短項目開(kāi)發(fā)的周期。 3、降低開(kāi)發(fā)和維護的成本，大量的重用和抽象，可以提取出一些開(kāi)發(fā)人員不用關(guān)心的公共部分，這樣便可以使開(kāi)發(fā)人員僅僅關(guān)注于業(yè)務(wù)邏輯的實(shí)現，從而減少了很多工作量，提高了開(kāi)發(fā)效率。
4、提高產(chǎn)品的質(zhì)量，好的軟件架構設計是產(chǎn)品質(zhì)量的保證，特別是對于客戶(hù)常常提出的非功能性需求的滿(mǎn)足。 軟件架構設計的原則 軟件架構設計必須遵循以下原則： 1、滿(mǎn)足功能性需求和非功能需求。
這是一個(gè)軟件系統最基本的要求，也是架構設計時(shí)應該遵循的最基本的原則。 2、實(shí)用性原則，就像每一個(gè)軟件系統交付給用戶(hù)使用時(shí)必須實(shí)用，能解決用戶(hù)的問(wèn)題一樣，架構設計也必須實(shí)用，否則就會(huì )“高來(lái)高去”或“過(guò)度設計”。
3、滿(mǎn)足復用的要求，最大程度的提高開(kāi)發(fā)人員的工作效率。 軟件架構設計的幾種視圖 我們常常在討論架構設計該做些什么的時(shí)候，或是在架構設計評審的會(huì )議上，會(huì )提出各種各樣的問(wèn)題，例如開(kāi)發(fā)人員該如何記錄Log，事務(wù)如何控制？怎樣才能提高我們的開(kāi)發(fā)人員的工作效率，即在單位時(shí)間內更有品質(zhì)的完成更多的功能？怎樣滿(mǎn)足客戶(hù)的非功能性需求？怎樣讓生產(chǎn)環(huán)境的平臺管理人員更好的維護系統？ 上面這些問(wèn)題，實(shí)際上是軟件系統的不同的干系人站在不同的角度上提出的問(wèn)題，要回答上面這些問(wèn)題，我們就得從不同的視角來(lái)看待軟件架構設計這項工作。
1、邏輯架構視角，從系統用戶(hù)的角度考慮問(wèn)題，設計出來(lái)的軟件架構能夠滿(mǎn)足業(yè)務(wù)邏輯的需求，能夠處理現在越來(lái)越復雜的業(yè)務(wù)邏輯需求。 2、開(kāi)發(fā)架構視角，從系統開(kāi)發(fā)人員的角度來(lái)考慮問(wèn)題，設計的架構要易于理解，易于開(kāi)發(fā)，易于單元測試，最好做到讓開(kāi)發(fā)人員可以用最少的代碼行數完成功能的開(kāi)發(fā)。
3、運行架構視角，從系統運行時(shí)的質(zhì)量需求考慮問(wèn)題，特別關(guān)注于系統的非功能需求，客戶(hù)常常都會(huì )要求我們系統的功能畫(huà)面的最長(cháng)響應時(shí)間不超過(guò)4秒，能滿(mǎn)足2000個(gè)用戶(hù)同時(shí)在線(xiàn)使用，基于角色的系統資源的安全控制等。 4、物理架構視角，關(guān)注系統安裝和部署在什么樣的環(huán)境上，例如現在最流行的企業(yè)應用服務(wù)解決方案IBM Http Server + WebSphere Application Server + DB2,WebLogic + Oracle等。
5、數據架構視角，如今我們開(kāi)發(fā)的各類(lèi)系統，如MIS,ERP,SAP，基本上都是對各類(lèi)數據的操作，把一堆不太好懂的數據展現成用戶(hù)容易看懂的數據，自動(dòng)處理各類(lèi)數據的運算等，所以數據的持久化是十分重要的一件事情。1、分析需求和理解業(yè)務(wù)模型（或領(lǐng)域建模），并選定關(guān)鍵Use case。
軟件的需求，可以分為從用戶(hù)視角和開(kāi)發(fā)人員視角來(lái)看，從用戶(hù)的角度看，又可以分為功能性和非功能性需求，我們必須從不同的視角和級別去全面的認識需求并分析需求，理解業(yè)務(wù)模型。實(shí)踐表明，常常被我們忽視的非功能性需求常常會(huì )導致整個(gè)項目失敗。
理解業(yè)務(wù)需求最好的方式莫過(guò)于進(jìn)行領(lǐng)域建模，領(lǐng)域建模與需求分析往往是交替穿叉進(jìn)行的，領(lǐng)域建模主要有以下三個(gè)方面的作用： ◆探索復雜問(wèn)題，弄清領(lǐng)域知識。Martin Fowler曾經(jīng)說(shuō)過(guò)，他采用面向對象方法最大的好處就是它有助于解決更為復雜的問(wèn)題。
領(lǐng)域建模本身作為輔助思維的工具，幫助我們將注意力始終保持在最為重要的業(yè)務(wù)概念及其關(guān)系上，使我們能夠不斷深入地，系統的對需求進(jìn)行分析和認識。領(lǐng)域建模往往是一個(gè)從模糊到清晰，從零散到系統的過(guò)程。
◆決定功能范圍，影響可擴展性。任何模型都是對現實(shí)世界某種程序的抽象，這種抽象就會(huì )忽略某一些東西，例如忽略對象的屬性和對象間的關(guān)系，而這些忽略往往都是帶有一定的目的性的，這種忽略就決定了功能的范圍。
模型揭示了各種功能背后的結構，如果說(shuō)定義功能相當于“拍照片”的話(huà)，那么領(lǐng)域建模就相當于“做透視”，更加關(guān)注問(wèn)題領(lǐng)域的內在結構，相當于對問(wèn)題領(lǐng)域進(jìn)行了一定的抽象，良好的領(lǐng)域模型不僅能很好的支持現有的功能，而且還可以在一定程度上支持未來(lái)可能出現的新需求，體現良好的可擴展性。 ◆提供交流基礎，促進(jìn)有效溝通。
領(lǐng)域建模通常會(huì )使用UML圖作為呈現的方式，這樣為我們的溝通提供了方便。當然，有時(shí)候文字在描述某些特定領(lǐng)域的問(wèn)題時(shí)可能更適合，可以靈活運用。
在我們公司的實(shí)際軟件開(kāi)發(fā)流程中，往往領(lǐng)域建模缺少這一環(huán)節，這可能是在以后的工作中需要進(jìn)一步提高之處。 雖然我們總是期望架構設計師能全面掌握需求，但由于時(shí)間和精力的限制，擺在我們面前的現實(shí)就是架構設計師沒(méi)有時(shí)間對所有需求進(jìn)行深入分析，所以我們的策略就是“把好鋼用在刀刃上”，即把大部分時(shí)間和精力花在對決定架構最重要的關(guān)鍵需求。
6.什么是系統架構設計
系統架構設計是人們對一個(gè)結構內的元素及元素間關(guān)系的一種主觀(guān)映射的產(chǎn)物。系統架構設計是一系列相關(guān)的抽象模式，用于指導大型軟件系統各個(gè)方面的設計。
擴展資料：
系統架構設計師是一個(gè)最終確認和評估系統需求，給出開(kāi)發(fā)規范，搭建系統實(shí)現的核心構架，并澄清技術(shù)細節、掃清主要難點(diǎn)的技術(shù)人員。
系統架構設計師考試合格人員能夠根據系統需求規格說(shuō)明書(shū)，結合應用領(lǐng)域和技術(shù)發(fā)展的實(shí)際情況，考慮有關(guān)約束條件，設計正確、合理的軟件架構，確保系統架構具有良好的特性；能夠與系統分析師、項目管理師相互協(xié)作、配合工作；具有高級工程師的實(shí)際工作能力和業(yè)務(wù)水平。
架構師是由國外引進(jìn)的一個(gè)概念，國外軟件開(kāi)發(fā)的幾個(gè)職位是技術(shù)官、架構師、設計師、開(kāi)發(fā)、測試，對應我們的公司應該是技術(shù)總監、架構師、系統分析員、程序員、測試人員。
參考資料：搜狗百科-系統架構設計
參考資料：搜狗百科-系統架構設計師
7.組織結構設計的要求與方法有哪些
組織結構設計的六項主要內容：
(1)職能設計
職能設計是指企業(yè)的經(jīng)營(yíng)職能和管理職能的設計。企業(yè)作為一個(gè)經(jīng)營(yíng)單位，要根據其戰略任務(wù)設計經(jīng)營(yíng)、管理職能。如果企業(yè)的有些職能不合理，那就需要進(jìn)行調整，對其弱化或取消。
(2)框架設計
框架設計是企業(yè)組織設計的主要部分，運用較多。其內容簡(jiǎn)單來(lái)說(shuō)就是縱向的分層次、橫向的分部門(mén)。其縱向和橫向的一般模式可表示如下：
(3)協(xié)調設計
協(xié)調設計是指協(xié)調方式的設計。框架設計主要研究分工，有分工就必須要有協(xié)作。協(xié)調方式的設計就是研究分工的各個(gè)層次、各個(gè)部門(mén)之間如何進(jìn)行合理的協(xié)調、聯(lián)系、配合，以保證其高效率的配合，發(fā)揮管理系統的整體效應。
(4)規范設計
規范設計就是管理規范的設計。管理規范就是企業(yè)的規章制度，它是管理的規范和準則。結構本身設計最后要落實(shí)、體現為規章制度。管理規范保證了各個(gè)層次、部門(mén)和崗位，按照統一的要求和標準進(jìn)行配合和行動(dòng)。
(5)人員設計
人員設計就是管理人員的設計。企業(yè)結構本身設計和規范設計，都要以管理者為依托，并由管理者來(lái)執行。因此，按照組織設計的要求，必須進(jìn)行人員設計，配備相應數量和質(zhì)量的人員。
(6)激勵設計
激勵設計就是設計激勵制度，對管理人員進(jìn)行激勵，其中包括正激勵和負激勵。正激勵包括工資、福利等，負激勵包括各種約束機制，也就是所謂的獎懲制度。激勵制度既有利于調動(dòng)管理人員的積極性，也有利于防止一些不正當和不規范的行為。
詳細介紹您可以參考這里：
/view/543252.htm#6
8.簡(jiǎn)要描述系統概要設計包括哪些方面的架構
在需求明確、準備開(kāi)始編碼之前，要做概要設計，而詳細設計可能大部分公司沒(méi)有做，有做的也大部分是和編碼同步進(jìn)行，或者在編碼之后。
因此，對大部分的公司來(lái)說(shuō)，概要設計文檔是唯一的設計文檔，對后面的開(kāi)發(fā)、測試、實(shí)施、維護工作起到關(guān)鍵性的影響。一、問(wèn)題的提出 概要設計寫(xiě)什么？概要設計怎么做？如何判斷設計的模塊是完整的？為什么說(shuō)設計階段過(guò)于重視業(yè)務(wù)流程是個(gè)誤區？以需求分析文檔還是以概要設計文檔來(lái)評估開(kāi)發(fā)工作量、指導開(kāi)發(fā)計劃準確？結構化好還是面向對象好？以上問(wèn)題的答案請在文章中找。
二、概要設計的目的 將軟件系統需求轉換為未來(lái)系統的設計；逐步開(kāi)發(fā)強壯的系統構架；使設計適合于實(shí)施環(huán)境，為提高性能而進(jìn)行設計；結構應該被分解為模塊和庫。三、概要設計的任務(wù) 制定規范：代碼體系、接口規約、命名規則。
這是項目小組今后共同作戰的基礎，有了開(kāi)發(fā)規范和程序模塊之間和項目成員彼此之間的接口規則、方式方法，大家就有了共同的工作語(yǔ)言、共同的工作平臺，使整個(gè)軟件開(kāi)發(fā)工作可以協(xié)調有序地進(jìn)行。總體結構設計：功能（加工）->模塊：每個(gè)功能用那些模塊實(shí)現，保證每個(gè)功能都有相應的模塊來(lái)實(shí)現；模塊層次結構：某個(gè)角度的軟件框架視圖；模塊間的調用關(guān)系：模塊間的接口的總體描述；模塊間的接口：傳遞的信息及其結構；處理方式設計：滿(mǎn)足功能和性能的算法 用戶(hù)界面設計；數據結構設計：詳細的數據結構：表、索引、文件；算法相關(guān)邏輯數據結構及其操作；上述操作的程序模塊說(shuō)明（在前臺？在后臺？用視圖？用過(guò)程？······） 接口控制表的數據結構和使用規則 其他性能設計。
四、概要設計寫(xiě)什么 結構化軟件設計說(shuō)明書(shū)結構（因篇幅有限和過(guò)時(shí)嫌疑，在此不作過(guò)多解釋?zhuān)?任務(wù)：目標、環(huán)境、需求、局限；總體設計：處理流程、總體結構與模塊、功能與模塊的關(guān)系；接口設計：總體說(shuō)明外部用戶(hù)、軟、硬件接口；內部模塊間接口（注：接口≈系統界面） 數據結構：邏輯結構、物理結構，與程序結構的關(guān)系；模塊設計：每個(gè)模塊“做什么”、簡(jiǎn)要說(shuō)明“怎么做”（輸入、輸出、處理邏輯、與其它模塊的接口，與其它系統或硬件的接口），處在什么邏輯位置、物理位置；運行設計：運行模塊組合、控制、時(shí)間；出錯設計：出錯信息、處錯處理；其他設計：保密、維護；OO軟件設計說(shuō)明書(shū)結構1 概述 系統簡(jiǎn)述、軟件設計目標、參考資料、修訂版本記錄 這部分論述整個(gè)系統的設計目標，明確地說(shuō)明哪些功能是系統決定實(shí)現而哪些時(shí)不準備實(shí)現的。同時(shí)，對于非功能性的需求例如性能、可用性等，亦需提及。
需求規格說(shuō)明書(shū)對于這部分的內容來(lái)說(shuō)是很重要的參考，看看其中明確了的功能性以及非功能性的需求。這部分必須說(shuō)清楚設計的全貌如何，務(wù)必使讀者看后知道將實(shí)現的系統有什么特點(diǎn)和功能。
在隨后的文檔部分，將解釋設計是怎么來(lái)實(shí)現這些的。2 術(shù)語(yǔ)表 對本文檔中所使用的各種術(shù)語(yǔ)進(jìn)行說(shuō)明。
如果一些術(shù)語(yǔ)在需求規格說(shuō)明書(shū)中已經(jīng)說(shuō)明過(guò)了，此處不用再重復，可以指引讀者參考需求說(shuō)明。3 用例 此處要求系統用用例圖表述（UML），對每個(gè)用例（正常處理的情況）要有中文敘述。
4 設計概述4.1 簡(jiǎn)述 這部分要求突出整個(gè)設計所采用的方法（是面向對象設計還是結構化設計）、系統的體系結構（例如客戶(hù)/服務(wù)器結構）以及使用到的相應技術(shù)和工具（例如OMT、Rose）4.2 系統結構設計 這部分要求提供高層系統結構（頂層系統結構、各子系統結構）的描述，使用方框圖來(lái)顯示主要的組件及組件間的交互。最好是把邏輯結構同物理結構分離，對前者進(jìn)行描述。
別忘了說(shuō)明圖中用到的俗語(yǔ)和符號。4.3 系統界面 各種提供給用戶(hù)的界面以及外部系統在此處要予以說(shuō)明。
如果在需求規格說(shuō)明書(shū)中已經(jīng)對用戶(hù)界面有了敘述，此處不用再重復，可以指引讀者參考需求說(shuō)明。如果系統提供了對其它系統的接口，比如說(shuō)從其它軟件系統導入/導出數據，必須在此說(shuō)明。
4.4 約束和假定 描述系統設計中最主要的約束，這些是由客戶(hù)強制要求并在需求說(shuō)明書(shū)寫(xiě)明的。說(shuō)明系統是如何來(lái)適應這些約束的。
另外如果本系統跟其它外部系統交互或者依賴(lài)其它外部系統提供一些功能輔助，那么系統可能還受到其它的約束。這種情況下，要求清楚地描述與本系統有交互的軟件類(lèi)型以及這樣導致的約束。
實(shí)現的語(yǔ)言和平臺也會(huì )對系統有約束，同樣在此予以說(shuō)明。對于因選擇具體的設計實(shí)現而導致對系統的約束，簡(jiǎn)要地描述你的想法思路，經(jīng)過(guò)怎么樣的權衡，為什么要采取這樣的設計等等。
5 對象模型 提供整個(gè)系統的對象模型，如果模型過(guò)大，按照可行的標準把它劃分成小塊，例如可以把客戶(hù)端和服務(wù)器端的對象模型分開(kāi)成兩個(gè)圖表述。在其中應該包含所有的系統對象。
這些對象都是從理解需求后得到的。要明確哪些應該、哪些不應該被放進(jìn)圖中。
所有對象之間的關(guān)聯(lián)必須被確定并且必須指明聯(lián)系的基數。聚合和繼承關(guān)系必須清楚地確定下來(lái)。
每個(gè)圖必須附有簡(jiǎn)單的說(shuō)明。6 對象描述 在這個(gè)部分敘述每個(gè)對象的細節，它的屬性、它的方法。
在這之前必須從邏輯上對對象進(jìn)行組織。你可能需要用結構圖把對象按子系統劃分好。
