EEA（Electrical/Electronic Architecture）：電子電氣架構(gòu)，是首先由德?tīng)柛９咎岢龅?，集合汽車的電子電氣系統(tǒng)原理設(shè)計(jì)、中央電器盒的設(shè)計(jì)、連接器的設(shè)計(jì)、電子電氣分配系統(tǒng)等設(shè)計(jì)為一體的整車電子電氣解決方案的概念。
ASPICE：是Automotive SPICE的簡(jiǎn)稱,即汽車行業(yè)軟件過(guò)程改進(jìn)與能力評(píng)定的過(guò)程評(píng)估模型。(SPICE是software process improvement and capability determination英文縮寫(xiě)。)
V模型：是Kevin Forsberg & Harold Mooz在1978年提出的，V模型強(qiáng)調(diào)測(cè)試在系統(tǒng)工程各個(gè)階段中的作用，并將系統(tǒng)分解和系統(tǒng)集成的過(guò)程通過(guò)測(cè)試彼此關(guān)聯(lián)。V模型從整體上看起來(lái)，就是一個(gè)V字型的結(jié)構(gòu)。左邊的下畫(huà)線分別代表了用戶需求、需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼和實(shí)現(xiàn)。右邊的上畫(huà)線代表了單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試與驗(yàn)收測(cè)試。
UML：UML建模技術(shù)是一種建模語(yǔ)言,指用模型元素來(lái)組建整個(gè)系統(tǒng)的模型,模型元素包括系統(tǒng)中的類、類和類之間的關(guān)聯(lián)、類的實(shí)例相互配合實(shí)現(xiàn)系統(tǒng)的動(dòng)態(tài)行為等。
ECU：ECU(Electronic Control Unit)電子控制單元,又稱“行車電腦”、“車載電腦”等。從用途上講則是汽車專用微機(jī)控制器,也叫汽車專用單片機(jī)。
OOAD：OOAD(Object Oriented Analysis and Design),面向?qū)ο蟮姆治雠c設(shè)計(jì)。 OOAD是根據(jù)OO的方法學(xué),對(duì)軟件系統(tǒng)進(jìn)行分析與設(shè)計(jì)的過(guò)程。
FREEvision：Vector公司為汽車行業(yè)提供的一個(gè)UML建模的工具。
AUTOSAR：Autosar(AUTomotive Open System ARchitecture)就是汽車開(kāi)放式系統(tǒng)架構(gòu)。這是一個(gè)由整車廠,零配件供應(yīng)商,以及軟件、電子、半導(dǎo)體公司合起來(lái)成立的一個(gè)組織。
汽車行業(yè)的軟件開(kāi)發(fā)有別于傳統(tǒng)互聯(lián)網(wǎng)行業(yè)的軟件開(kāi)發(fā)，其更傾向于一個(gè)系統(tǒng)工程。因?yàn)槟愠艘P(guān)心軟件系統(tǒng)以外，同時(shí)也要兼顧不同零部件之間的協(xié)作，以及ECU的算力問(wèn)題。所以，并不能簡(jiǎn)單地通過(guò)傳統(tǒng)的瀑布、敏捷等開(kāi)發(fā)方法直接套用在汽車行業(yè)當(dāng)中。
基于汽車行業(yè)的復(fù)雜度，行業(yè)的軟件成熟度通過(guò)ASPICE進(jìn)行評(píng)估。ASPICE通過(guò)V模型來(lái)體現(xiàn)其設(shè)計(jì)的生命周期，并將相關(guān)的生命周期區(qū)分成SYS系統(tǒng)V模型，SWC軟件V模型兩個(gè)主要層面來(lái)了解汽車。同時(shí)硬件開(kāi)發(fā)、線束、布線等都有其相應(yīng)的V模型進(jìn)行表現(xiàn)。
ASPICE對(duì)整車開(kāi)發(fā)定義了多套V模型，包括系統(tǒng)分析V模型、軟件開(kāi)發(fā)V模型、硬件開(kāi)發(fā)等多種V模型。
汽車電子電器架構(gòu)設(shè)計(jì)從傳統(tǒng)的分布式結(jié)構(gòu)逐步發(fā)展，向領(lǐng)域驅(qū)動(dòng)和中心化的方向推進(jìn)，其目的就是簡(jiǎn)化電子電器的線束的復(fù)雜度，并且能夠通過(guò)統(tǒng)一的方式使用和調(diào)度不同Zone區(qū)域節(jié)點(diǎn)的功能。
OMG組織發(fā)布的系統(tǒng)建模語(yǔ)言SysML是一種通用圖形建模語(yǔ)言，通過(guò)需求、分析、設(shè)計(jì)、驗(yàn)證等角度來(lái)定義復(fù)雜系統(tǒng)，實(shí)現(xiàn)對(duì)包括硬件、軟件、信息、人員、程序和設(shè)施等的定義。該語(yǔ)言提供了大量UML擴(kuò)展的圖形，針對(duì)系統(tǒng)建模當(dāng)中的系統(tǒng)需求，行為，結(jié)構(gòu)和參數(shù)的語(yǔ)義等信息，并可以用于與其他工程分析模型集成進(jìn)行。
SysML針對(duì)相關(guān)的行業(yè)定義了一些特有的圖形進(jìn)行描述，專業(yè)的汽車設(shè)計(jì)軟件PREEvision，是一個(gè)可以支持整車電子電器開(kāi)發(fā)設(shè)計(jì)以及仿真的軟件，PREEvision為汽車EEA電子電器開(kāi)發(fā)的各個(gè)階段提供了不同的圖形的支持。
但是，即使是有一定的技術(shù)基礎(chǔ)，很多時(shí)候遇到具體業(yè)務(wù)場(chǎng)景實(shí)施時(shí)，依然會(huì)有各種各樣的問(wèn)題。一方面各種方法論無(wú)法通用地解決所有問(wèn)題；另外一方面，汽車行業(yè)從業(yè)人員需要的技能比較多，要能夠透徹看清楚各個(gè)環(huán)節(jié)，需要大量跨領(lǐng)域的知識(shí)。大多從業(yè)人員自身的技能依然維持在傳統(tǒng)的模式上，行業(yè)局限性比較大，軟件及架構(gòu)等技能也相對(duì)有限。
UML是一種通用的建模語(yǔ)言，其作用貫穿整個(gè)軟件系統(tǒng)的生命周期。SysML是UML的一個(gè)子集，它繼承和擴(kuò)展了UML基礎(chǔ)的各種能力和模型。
UML是一種用于對(duì)軟件密集型系統(tǒng)進(jìn)行可視化、詳述、構(gòu)造和文檔化的建模語(yǔ)言，主要適用于分析與設(shè)計(jì)階段的系統(tǒng)建模。UML最主要的特點(diǎn)是表達(dá)能力豐富。UML從各種OOA&D方法中吸取了大量的概念，對(duì)這些概念的語(yǔ)義、圖形表示法和使用規(guī)則作了完整而詳細(xì)的定義?？梢哉f(shuō)，UML對(duì)系統(tǒng)模型的表達(dá)能力超出了以往任何一種OOA&D方法。當(dāng)然，它的復(fù)雜性也超出了以往任何一種方法。
UML的問(wèn)世引起了計(jì)算機(jī)軟件界的廣泛重視，因?yàn)樗砹艘环N積極的方向——多種方法相互借鑒、相互融合、趨于一致、走向標(biāo)準(zhǔn)化。建模語(yǔ)言的標(biāo)準(zhǔn)化為軟件開(kāi)發(fā)商及其用戶帶來(lái)了諸多便利。
UML1.x是為軟件行業(yè)制定的一種交互語(yǔ)言，用來(lái)給軟件的各個(gè)階段提供交流手段。UML2.x基于UML1.x的成功結(jié)果，嘗試對(duì)世間萬(wàn)物進(jìn)行建模，在解決了一些UML1.x問(wèn)題的基礎(chǔ)上增加了許多圖例來(lái)支持更多行業(yè)的建模要求。
UML語(yǔ)言是一種面向?qū)ο蟮慕ＵZ(yǔ)言，適合用來(lái)輔助了解復(fù)雜的系統(tǒng)和結(jié)構(gòu)，具有比較高的思維同質(zhì)性。我們可以想象一下，如果我們要為一盤圍棋進(jìn)行建模，將所有的圍棋棋子都看成對(duì)象，這樣理解其行為容易還是從過(guò)程的角度來(lái)思考所有圍棋容易。從面相對(duì)象角度，我們只需要關(guān)心每個(gè)棋子每一瞬間的位置和行為即可。
UML語(yǔ)言適用于系統(tǒng)所有階段的建模，它提供了多種方式來(lái)體現(xiàn)信息內(nèi)容。這些表現(xiàn)非常容易被系統(tǒng)和軟件周期的各個(gè)階段的成員進(jìn)行理解，方便了各個(gè)階段成員之間的交流。
UML語(yǔ)言提供了大量的表現(xiàn)方式，使用者可以從多種維度描述系統(tǒng)和架構(gòu)的相關(guān)信息。無(wú)論是系統(tǒng)、架構(gòu)、軟件、硬件、嵌入式、功能、非功能等都可以使用不同的UML語(yǔ)言圖例進(jìn)行精確描述將實(shí)施過(guò)程碰到的信息和內(nèi)容進(jìn)行沉淀。而且，汽車行業(yè)的業(yè)務(wù)行為復(fù)雜，需要一種能夠兼容各種要求的模式進(jìn)行表現(xiàn)。
當(dāng)前汽車行業(yè)蓬勃發(fā)展，軟件定義汽車的概念越來(lái)越普及。固有的思路和傳統(tǒng)的方法已經(jīng)無(wú)法支持新概念的引入，同時(shí)也存在固有理念影響了新概念引入整車的情況（例如元宇宙、SOA服務(wù)驅(qū)動(dòng)等），從正向角度思考汽車系統(tǒng)和汽車軟件的開(kāi)發(fā)流程越來(lái)越得到重視。這也是汽車行業(yè)發(fā)展的未來(lái)方向。未來(lái)的汽車就是一個(gè)帶有四個(gè)輪子的手機(jī)。如何能夠?qū)⑺行滤枷搿⑿赂拍钜肫囆袠I(yè)，如何落地，都期待新的火花的出現(xiàn)。
需求分析和業(yè)務(wù)分析是一個(gè)過(guò)程，是一個(gè)整理思路的過(guò)程，使用工具是輔助我們梳理思路。是一個(gè)比較復(fù)雜的整理和匹配要求的方式，沉淀后得到一個(gè)統(tǒng)一的結(jié)果。使用 PREEvision 編寫(xiě)的內(nèi)容可以理解為是一個(gè)結(jié)果，產(chǎn)生這個(gè)結(jié)果的過(guò)程需要更多的專業(yè)的好行業(yè)的知識(shí)的注入。
用例圖
原則上來(lái)說(shuō)，用例圖并不是一種面向?qū)ο蟮膱D形，UML引入用例圖的目的是為了能夠在UML進(jìn)行面向?qū)ο蠼r(shí)，提供一個(gè)基礎(chǔ)和入口，以及劃定分析設(shè)計(jì)的邊界。
Use Case 用例圖主要包含Actor 和 use case兩樣?xùn)|西，use case 是一組連續(xù)行為的集合，例如“打開(kāi)門”等。事件可大可小，原則上并沒(méi)有嚴(yán)格約束。Actor用來(lái)描述對(duì)該事件的驅(qū)動(dòng)者或者該事件關(guān)聯(lián)的外部各方。我們也可以通過(guò)Region域的劃定來(lái)將用例放置于指定的限定的范圍內(nèi)。Actor和Use Case之間的連線代表交互關(guān)系。
活動(dòng)圖
活動(dòng)圖用來(lái)描述行為的過(guò)程，可以表示行為執(zhí)行的步驟和過(guò)程中的并發(fā)、條件、選擇、合并等行為的體現(xiàn)。
順序圖
順序圖用來(lái)描述強(qiáng)時(shí)間要求的順序行為。精確體現(xiàn)對(duì)象之間的驅(qū)動(dòng)和執(zhí)行關(guān)系。UML2.0為了增強(qiáng)sequence順序圖的功能，加入了fragment的概念，讓順序圖可以表現(xiàn)一些可重用的順序塊和邏輯信息，例如條件分支等。
狀態(tài)機(jī)
State Machine 狀態(tài)機(jī)圖體現(xiàn)的是事物狀態(tài)以及狀態(tài)之間變化的關(guān)系，以及變化的驅(qū)動(dòng)源等信息。狀態(tài)機(jī)能夠很好地體現(xiàn)事物的一些靜態(tài)特性。
類圖
在UML語(yǔ)言當(dāng)中，所有需要沉淀的內(nèi)容都需要通過(guò)類圖（或類相關(guān)圖）進(jìn)行沉淀的。在需求整理過(guò)程中，并不一定要類圖參與，但是類圖的參與能夠更好地將需求內(nèi)容延續(xù)到后期的架構(gòu)和軟件過(guò)程當(dāng)中。
什么是需求
所謂需求，是指因?yàn)橛笠l(fā)的某種動(dòng)機(jī)，這個(gè)動(dòng)機(jī)就是需求。我們一般的理解是利益相關(guān)者stakeholder對(duì)系統(tǒng)的一種要求。需求有業(yè)務(wù)需求、用戶需求和功能需求等。
如何描述用戶的需求呢？對(duì)于軟件行業(yè)我們一般會(huì)從業(yè)務(wù)的角度去描述用戶的需求，更直觀地，我們會(huì)通過(guò)冰山模型來(lái)表現(xiàn)
用戶要實(shí)現(xiàn)的功能就是整座冰山，冰山浮出水面的部分就是用戶的需求，用戶需求就是冰山對(duì)于用戶的可見(jiàn)部分。所謂可見(jiàn)部分，包括視覺(jué)、聽(tīng)覺(jué)、觸覺(jué)、味覺(jué)在內(nèi)的各種感知。例如主機(jī)廠要求的用戶需求，可以是中控屏的操作，可以是雷達(dá)的聲響，也可以是語(yǔ)音與SIRI 的對(duì)話過(guò)程。我們觸碰雨刮開(kāi)關(guān)，導(dǎo)致雨刮擺動(dòng)，這也是主機(jī)廠能夠感覺(jué)到的用戶需求。通過(guò)對(duì)冰山水面可見(jiàn)部分的分析和理解，搭建出整個(gè)能夠支持冰山的不可見(jiàn)部分的內(nèi)容。
汽車行業(yè)需求分析過(guò)程，可以區(qū)分為業(yè)務(wù)建模、系統(tǒng)建模以及軟件建模過(guò)程三個(gè)階段，
業(yè)務(wù)建模
業(yè)務(wù)建模是將業(yè)務(wù)相關(guān)過(guò)程進(jìn)行完整梳理，將軟件功能和非軟件功能進(jìn)行確認(rèn)和分離，從而將需求工作的重點(diǎn)集中在需求的軟件部分。
例如我們?cè)谘芯恳粋€(gè)自動(dòng)洗車過(guò)程，自動(dòng)洗車應(yīng)該包含：
1.將車(自動(dòng))從停車場(chǎng)開(kāi)到洗車房
2.點(diǎn)擊系統(tǒng)開(kāi)啟自動(dòng)洗車模式（自動(dòng)洗車模式關(guān)閉窗戶、停止雨刮、關(guān)閉空調(diào)、鎖住后車門、關(guān)閉車身保護(hù)雷達(dá)等）
3.將汽車檔位掛在N空擋位置
4.洗車房機(jī)器開(kāi)始洗車過(guò)程
5.洗完車關(guān)閉自動(dòng)洗車模式（恢復(fù)天窗、雨刮等的狀態(tài)）
6.將車（自動(dòng)）從洗車房開(kāi)回停車場(chǎng)
業(yè)務(wù)建模及業(yè)務(wù)分析過(guò)程是必須有的，但是在整理整車業(yè)務(wù)需求時(shí)可以簡(jiǎn)化相關(guān)過(guò)程。通過(guò)業(yè)務(wù)建模后，我們判斷1和6，汽車從停車場(chǎng)自動(dòng)開(kāi)到洗車房并回來(lái)的過(guò)程現(xiàn)在依然不成熟，所以無(wú)法支持，于是將這個(gè)過(guò)程分析為人為處理實(shí)現(xiàn)。對(duì)于4，無(wú)需人為干預(yù)。對(duì)于3，需要人為將物理檔位切換，當(dāng)前車身并不具備這個(gè)功能，但是我們可以編寫(xiě)一個(gè)用戶指引guideline來(lái)引導(dǎo)用戶完成洗車過(guò)程。于是，對(duì)于2和5將被分析成系統(tǒng)需求，交由自動(dòng)洗車功能模塊來(lái)完成。
系統(tǒng)建模
系統(tǒng)建模的目的是將車身功能進(jìn)行分析和細(xì)化，依據(jù)用戶可感知的部分的信息，搭建起整個(gè)系統(tǒng)的架構(gòu)。就是參考冰山可見(jiàn)部分構(gòu)建出整個(gè)冰山的內(nèi)容。描述冰山可見(jiàn)部分可以理解為系統(tǒng)需求過(guò)程，構(gòu)造出支撐可見(jiàn)部分的整個(gè)冰山可以理解為系統(tǒng)架構(gòu)、系統(tǒng)設(shè)計(jì)的過(guò)程。系統(tǒng)建模過(guò)程也需要考慮非功能性需求，例如安全、性能、法律法規(guī)等非功能性需求也會(huì)影響系統(tǒng)整個(gè)建模過(guò)程。
軟件建模
系統(tǒng)建模過(guò)程結(jié)束后，將設(shè)計(jì)結(jié)果轉(zhuǎn)換成軟件架構(gòu)實(shí)現(xiàn)的接口要求，一般是子系統(tǒng)的接口需求或者SOA服務(wù)的服務(wù)接口需求。軟件接口需求會(huì)定義軟件接口的名稱、參數(shù)信息和參數(shù)值、返回信息和返回值。參數(shù)信息和參數(shù)值之間存在一定的依賴關(guān)系，這些依賴關(guān)系也需要也需要通過(guò)一定的方式描述其內(nèi)部功能實(shí)現(xiàn)的流程關(guān)系。這些接口的定義信息就是軟件子系統(tǒng)的需求。
同時(shí)，軟件建模過(guò)程也會(huì)從系統(tǒng)建模過(guò)程細(xì)化出來(lái)各種非功能性需求，這些非功能性需求也會(huì)影響軟件建模和實(shí)現(xiàn)過(guò)程。
這里主要講解的是系統(tǒng)需求分析的全過(guò)程，業(yè)務(wù)場(chǎng)景分析雖然包含在內(nèi)，但是會(huì)一帶而過(guò)。軟件分析過(guò)程可以參考傳統(tǒng)的軟件分析過(guò)程實(shí)施完成。
具體分析過(guò)程可以參考以下流程（并不是完整流程，可以根據(jù)具體企業(yè)的要求和場(chǎng)景進(jìn)行調(diào)整）?？傮w流程氛圍業(yè)務(wù)場(chǎng)景分析和梳理、系統(tǒng)需求分析和梳理、系統(tǒng)需求細(xì)化、系統(tǒng)需求評(píng)審的過(guò)程。
業(yè)務(wù)場(chǎng)景分析的目的如下：
1.梳理出可以通過(guò)軟件實(shí)現(xiàn)的系統(tǒng)功能；
2.將功能硬件理解成軟件包（所有硬件功能的實(shí)現(xiàn)都由軟件進(jìn)行代理完成）；
3.將硬件部分都理解成non-human 的actor，包括聲音，雷達(dá)等等可感知部分
4.梳理出涉及的human的actor，例如駕駛員、乘客等。
系統(tǒng)需求分析的目的如下：
1.識(shí)別所有系統(tǒng)用例，系統(tǒng)用例為一系列時(shí)間相關(guān)的行為總和。并將系統(tǒng)用例通過(guò)簡(jiǎn)單的名稱進(jìn)行描述；
2.將系統(tǒng)用例與actor以及non-human的actor進(jìn)行關(guān)聯(lián)，清晰體現(xiàn)出所有系統(tǒng)用例的邊界；
3.將non-functional的非功能性需求進(jìn)行描述以及體現(xiàn)；
4.將UI相關(guān)（界面、語(yǔ)音、雷達(dá)等交互）與非UI行為進(jìn)行分離，單獨(dú)描述；
5.將所有涉及或影響到這個(gè)業(yè)務(wù)場(chǎng)景的事件也作為系統(tǒng)用例進(jìn)行表現(xiàn)。但是要注意其Actor的識(shí)別，例如司機(jī)踩油門導(dǎo)致車速加快會(huì)啟動(dòng)車門安全鎖，那么啟動(dòng)這個(gè)驅(qū)動(dòng)者的Actor將是車身，而不是駕駛員；
系統(tǒng)需求細(xì)化的目的如下：
1.將UI相關(guān)的用例，借助活動(dòng)圖描述出頁(yè)面流轉(zhuǎn)的關(guān)系，主要體現(xiàn)出頁(yè)面，以及頁(yè)面切換的邏輯依賴關(guān)系。非頁(yè)面行為可以弱化成單個(gè)活動(dòng)行為；
2.將非UI的用例細(xì)化成以功能實(shí)現(xiàn)為主線的活動(dòng)圖，UI相關(guān)部分需要體現(xiàn)成UI類型活動(dòng)圖；
3.對(duì)于外部事件相關(guān)的活動(dòng)也需要轉(zhuǎn)換成活動(dòng)圖；
4.細(xì)化過(guò)程的語(yǔ)言描述不可以存在歧義，存在歧義的文字描述需要在術(shù)語(yǔ)定義當(dāng)中進(jìn)行定義；
5.對(duì)于一些部件或狀態(tài)類型的信息可以通過(guò)狀態(tài)機(jī)進(jìn)行體現(xiàn)；
6.對(duì)于一些時(shí)間強(qiáng)相關(guān)的事件可以通過(guò)序列圖進(jìn)行體現(xiàn)；
7.對(duì)于需要有信息沉淀或術(shù)語(yǔ)定義類型的信息，可以通過(guò)類圖進(jìn)行體現(xiàn)。例如恢復(fù) “原來(lái)狀態(tài)” 就代表需要存在一個(gè)需要沉淀下來(lái)的信息。
需求評(píng)審的目的如下：
1.評(píng)審是一個(gè)周期性的行為，可以理解成檢查，主要目的是進(jìn)行各個(gè)階段的把關(guān)工作。
2.需求評(píng)審和總需求交付評(píng)審不是一個(gè)概念，總交付評(píng)審是一個(gè)蓋章過(guò)程，需求各個(gè)階段的評(píng)審是對(duì)階段工作的檢查。
3.評(píng)審?fù)ㄟ^(guò)提前的同行交流、跨部門交流、架構(gòu)師檢查等方式來(lái)發(fā)現(xiàn)需求階段存在的問(wèn)題。
4.由于需求人員的背景和知識(shí)能力的差異，可以通過(guò)評(píng)審來(lái)減少錯(cuò)誤，同時(shí)達(dá)到提高專業(yè)能力和實(shí)現(xiàn)共識(shí)的目的。
在需求分析的時(shí)候需要注意以下幾點(diǎn)：
1.非功能性需求需要依賴不同的要求進(jìn)行描述和表示，可能是圖形也可能是文字表格，目的是能夠體現(xiàn)需求的特點(diǎn)和相關(guān)性。此次并不會(huì)對(duì)非功能性需求描述過(guò)多，更多的需求表述可以另設(shè)話題討論。
2.不管是需求分析，還是架構(gòu)設(shè)計(jì)，都是一個(gè)遞進(jìn)的過(guò)程，圖形隨著分析的遞進(jìn)，逐步細(xì)化和深入。當(dāng)前展示的內(nèi)容主要是展示分析結(jié)果，相關(guān)分析過(guò)程信息將會(huì)通過(guò)文字表示。
3.使用UML進(jìn)行需求分析，目的都是為了能夠簡(jiǎn)化和清晰需求描述，做到簡(jiǎn)化和解耦的目的，部分難以表述的內(nèi)容會(huì)建議采用文字表述的方式進(jìn)行表達(dá)。
4.圖形的多少并不是越多越好，判斷標(biāo)準(zhǔn)就是是否能夠清晰表達(dá)需求的信息。當(dāng)然，另外一個(gè)判斷標(biāo)準(zhǔn)就是：任何人拿著需求文檔都能夠通過(guò)UML和文字清晰了解需求內(nèi)容即可。所以并沒(méi)有嚴(yán)格的標(biāo)準(zhǔn)。
5.需求的編寫(xiě)是以UML管理的目錄結(jié)構(gòu)為基礎(chǔ)，Word文檔和Excel的表述只是它的一種展示方式。
6.當(dāng)前需求的編寫(xiě)是通過(guò)UML Designer軟件進(jìn)行編寫(xiě)，通過(guò)工具，能夠更好地管理和定位軟件模型，這個(gè)工具本身并不能完美支持UML2.x的所有內(nèi)容，為了避免切換工具的時(shí)候帶來(lái)的移植問(wèn)題，編寫(xiě)圖形時(shí)都使用標(biāo)準(zhǔn)的圖形即可。
總述
該文檔的編寫(xiě)是以一個(gè)《自動(dòng)洗車功能》作為基礎(chǔ)，自動(dòng)洗車功能概述如下：自動(dòng)洗車功能是為了使用戶能夠快速自動(dòng)洗車，在進(jìn)入自動(dòng)洗車機(jī)前，通過(guò)快捷按鍵一次性完成關(guān)窗、停止雨刮、關(guān)閉雷達(dá)、禁止開(kāi)啟后車門等操作，并且在洗車完成后通過(guò)快捷按鍵恢復(fù)各個(gè)相關(guān)零部件洗車前狀態(tài)。自動(dòng)洗車模式包括進(jìn)入自動(dòng)洗車模式、退出自動(dòng)洗車模式、自動(dòng)洗車模式保持期間對(duì)相關(guān)零部件的操作的三大部分。各個(gè)功能需求通過(guò)需求整理和車型對(duì)標(biāo)獲得。
下圖是自動(dòng)洗車模式層次架構(gòu)的樣貌。整個(gè)需求分析過(guò)程是一個(gè)遞進(jìn)過(guò)程，分析過(guò)程會(huì)產(chǎn)生許多圖形和結(jié)構(gòu)以及關(guān)系，可以使用package包分類管理起來(lái)。
模型是UML定義的元對(duì)象，圖形 diagram是模型在不同側(cè)面的一個(gè)體現(xiàn)，根據(jù)需要將特定的UML模型進(jìn)行展示和體現(xiàn)，根據(jù)需求在圖形上進(jìn)行取舍。圖形展示并不會(huì)影響模型之間的關(guān)系，圖形可以看成只是一個(gè)輔助工具而已。
用例
首先第一步是進(jìn)行用例的確定，確定的基本方向?yàn)椋?/span>1.UI與非UI進(jìn)行分離。2.將正常業(yè)務(wù)與異常業(yè)務(wù)場(chǎng)景進(jìn)行分離。3.異常業(yè)務(wù)場(chǎng)景單獨(dú)體現(xiàn)。4.由于觸及的外部零部件都是可見(jiàn)部分，所以將外部零部件都作為單獨(dú)的non-human actor來(lái)體現(xiàn)。
下圖A中，UI進(jìn)入自動(dòng)洗車模式表示通過(guò)中控屏啟動(dòng)功能的過(guò)程，虛擬按鍵點(diǎn)擊和語(yǔ)音交互都是一種UI的啟動(dòng)方式而已。因?yàn)檫@里是UI用例，UI用例是借助UML來(lái)體現(xiàn)UI交互過(guò)程，它并不是一個(gè)真實(shí)的用例的概念，所以我們只需要關(guān)心驅(qū)動(dòng)者是駕駛員即可，無(wú)需考慮零部件的相關(guān)行為。
下圖B中，對(duì)中控屏主動(dòng)控制，發(fā)出信號(hào)的是駕駛員，每個(gè)用例我們可以理解成一塊軟件團(tuán)完成的功能。窗戶雨刮等為non-human的actor，這些作為外部部件。未來(lái)經(jīng)過(guò)架構(gòu)階段的推導(dǎo)，外部部件都會(huì)很自然地變成一個(gè)一個(gè)的子系統(tǒng)或服務(wù)，但這是后話。這個(gè)階段，我們只需要將冰山上可見(jiàn)部分，就是用戶可感知部分，都作為外部的actor考慮即可。對(duì)于關(guān)閉自動(dòng)洗車模式的行為，在用戶無(wú)意中改變了檔位以后，一樣會(huì)觸發(fā)關(guān)閉自動(dòng)洗車模式的行為，所以我們將這個(gè)行為作為擴(kuò)展考慮。其原因是我們幾乎不用增加任何的描述就可以體現(xiàn)更改檔位導(dǎo)致的變化，也可以理解為我們?cè)谶M(jìn)行用例細(xì)化的時(shí)候只需要細(xì)化其中一個(gè)用例即可。
下圖C中，表現(xiàn)的是自動(dòng)洗車模式場(chǎng)景ongoing的狀態(tài)時(shí)，某些對(duì)空調(diào)、窗戶等硬件操作后會(huì)影響自動(dòng)洗車模式的情況。簡(jiǎn)單來(lái)說(shuō)，就是洗車模式關(guān)閉的時(shí)候會(huì)將相關(guān)零部件恢復(fù)到進(jìn)入洗車模式前的狀態(tài)，但是如果零部件被觸碰，例如天窗被調(diào)整以后，退出時(shí)將忽略天窗的恢復(fù)。由于該事件的完整行為過(guò)程為外部器件驅(qū)動(dòng)并記錄外部事件的信息，因此用例定義簡(jiǎn)單。
A.UI相關(guān)用例 | B.功能用例 | C.外部事件用例 |
| | |
用例活動(dòng)
有的用例內(nèi)容可以通過(guò)其他用例的信息體現(xiàn)，所以無(wú)需進(jìn)行用例活動(dòng)描述，能夠體現(xiàn)用例信息的用例需要將用例實(shí)現(xiàn)過(guò)程，即所有涉及可見(jiàn)/可感知的行為，都通過(guò)活動(dòng)圖體現(xiàn)出來(lái)。文字表達(dá)不能模糊，必須清晰體現(xiàn)具體行為，對(duì)于某些詞匯定義，可以在詞匯表進(jìn)行解釋。
對(duì)于UI相關(guān)的用例，主要是體現(xiàn)UI交互/語(yǔ)音交互的交互過(guò)程，甚至包括硬件操作過(guò)程，弱化非UI部分的內(nèi)容。如果圖形不能表達(dá)清楚，可以通過(guò)文字進(jìn)行補(bǔ)充。
描述UI活動(dòng)過(guò)程中，需要把事件和行為進(jìn)行分離。流程描述的是事件，例如按下按鈕是確認(rèn)行為，而不是點(diǎn)擊按鈕或語(yǔ)音（小度，小度，我選一）確認(rèn)?？梢酝ㄟ^(guò)文字描述體現(xiàn)這個(gè)按鈕確認(rèn)行為，包含通過(guò)鼠標(biāo)點(diǎn)擊和語(yǔ)音確認(rèn)兩種方式。
對(duì)于UI的action采用自定義的方式表示，紅底表示UI相關(guān)，白底的活動(dòng)為非UI/軟件行為層面的行為。
對(duì)于非UI的業(yè)務(wù)流程，必要的地方依然會(huì)描述出UI活動(dòng)，更多的內(nèi)容需要分析軟件判斷邏輯，這些邏輯和行為基本是與actor相關(guān)的。非UI流程里，所有涉及到的外部Actor（human actor或non-human actor）交互的過(guò)程都應(yīng)該在活動(dòng)圖里進(jìn)行體現(xiàn)。有時(shí)候，UI活動(dòng)的結(jié)束就是非UI的開(kāi)始。
對(duì)于外界事件的影響，根據(jù)實(shí)際情況將用例的活動(dòng)描述轉(zhuǎn)換成活動(dòng)圖進(jìn)行表現(xiàn)。
類圖
根據(jù)實(shí)際情況，將類圖進(jìn)行抽取和表現(xiàn)。
類圖的來(lái)源包括：
1.術(shù)語(yǔ)定義
2.狀態(tài)機(jī)抽象
3.關(guān)鍵實(shí)體對(duì)象
4.存儲(chǔ)管理信息
5.模糊術(shù)語(yǔ)定義
在UML語(yǔ)言當(dāng)中，所有需要沉淀保存和管理的信息都是通過(guò)類來(lái)實(shí)現(xiàn)的，類圖可以體現(xiàn)出實(shí)體的信息。進(jìn)行類圖抽象，可以輔助后續(xù)架構(gòu)設(shè)計(jì)進(jìn)行類的抽取。因此，根據(jù)實(shí)際情況抽取類圖。
當(dāng)前類圖并沒(méi)有很好地體現(xiàn)實(shí)體的內(nèi)容，并不是一個(gè)合理的類圖信息的展示，但是卻能夠體現(xiàn)需求整理者對(duì)各種信息的理解?；谶@些信息，架構(gòu)設(shè)計(jì)人員可以根據(jù)類圖進(jìn)行參考和對(duì)實(shí)體對(duì)象信息的收集。
狀態(tài)機(jī)圖
狀態(tài)機(jī)可以清晰體現(xiàn)出對(duì)象的狀態(tài)的類型、狀態(tài)之間切換的條件以及方向等信息。
下圖為后視鏡的狀態(tài)信息，包含折疊和展開(kāi)。這個(gè)狀態(tài)機(jī)也體現(xiàn)了狀態(tài)之間進(jìn)行切換的時(shí)候的行為以及轉(zhuǎn)換方向等信息。
下圖展示了一個(gè)二維的狀態(tài)變化管理，通過(guò)狀態(tài)機(jī)表現(xiàn)兩個(gè)狀態(tài)類型轉(zhuǎn)換之間的關(guān)系信息等。
其他模型
由于當(dāng)前進(jìn)行需求分析的方式是采用工具UML，更多的是通過(guò)圖形方式展示結(jié)構(gòu)和關(guān)系類型。但是圖形不是萬(wàn)能的，有時(shí)候一兩句話就能夠簡(jiǎn)化和體現(xiàn)相關(guān)信息，所以文字描述也可以適當(dāng)使用。同時(shí)，任何的理解和共識(shí)信息都可以通過(guò)文字進(jìn)行描述，方便相關(guān)人員的同步和理解。
基于UML模型的管理結(jié)構(gòu)，存在presentation角度的圖形管理展示，可以借助工具進(jìn)行展示。雖然工件artifact和關(guān)系是UML語(yǔ)言的基礎(chǔ)，圖形只是不同角度、不同側(cè)面的展示方式而已，但是人們接受信息的方式是通過(guò)圖形去體現(xiàn)的，所以圖形展示是一個(gè)重要的管理環(huán)境。
通過(guò)表格針對(duì)需要展示某些信息的列表以及描述信息的內(nèi)容進(jìn)行體現(xiàn)。
http://mp.weixin.qq.com/s?__biz=Mzg5NzUyMjU1OA==&mid=2247483825&idx=1&sn=3e426e6fd5ea9c24f6b1ee768d60d854&chksm=c071cfa0f70646b6b86410df46e45e3d5817307930ab7f81c898eae7556ea589011c84a1fc69#rd
聯(lián)系客服
