2010-02-04 98 views
4

我要尋找一個UI功能建模語言(UML-一樣「東西」,但用戶界面),它已被接受,也許有它的設計模式和處理問題,不是狀態或活動圖更好。用戶界面功能建模語言?

這個問題浮現在腦海的發現UML和圖表失敗的描述與執行的事件驅動的流程複雜的用戶界面功能的結果(即使用Javascript/jQuery的大項目。)

編輯: 我我一直在考慮使用BPMN,但它並不是爲此目的而創建的。

+0

有一些技術特定的DSL,但沒有標準,我知道的。因此,請在創建任何內容之前,如果您希望它有用,請考慮不同的UI範例(並非始終支持所有動態行爲)。請不要使其技術特定,請考慮這種規範的文本語法。如果您選擇文本路徑,請查看Eclipse TMF Xtext。 – 2010-04-05 14:34:46

回答

3

也許user interface prototypesstoryboards可以幫助... 他們是不是「建模語言」,但對GUI設計非常很好的驗證技術的一部分......,想到

+0

UI原型僅用於靜態接口的可用性手段。故事板的東西看起來更好,但他們似乎沒有任何規格。我不確定它是否可以被評爲「比狀態圖更好」;)並且它讓我想起了BPMN http://en.wikipedia.org/wiki/Business_Process_Modeling_Notation – naugtur 2010-02-04 15:13:42

2

我不認爲有任何的標準在那裏爲特定目的(我在想同樣的事情一天)。我認爲,SysML很接近,但它絕對是過分的。

主要是,我的想法是,如果UML配置文件或元模型是用核心UI組件和事件(「文本字段」,「單擊」等)定義的,則不同的UI實現(HTML,Swing,AJAX )可以使用實例模型的XMI上的轉換來生成。除此之外,至少會有更加清晰和形式化的描述給定用戶界面功能的方式。

+0

這與我一直在想的很接近。我還會在圖上添加一種表示事件的新方法。 – naugtur 2010-03-04 11:38:20

1

我只是偶然到你的問題,這是我認真對待的問題。 Here's my answer這個問題,我用了20多年的各種形式。

基本上,這裏是我在這樣的描述性語言尋求的標準:

  • 語言不應被淡化和不能之類的東西進入數據或流的控制基本基元像IF,FOR和子程序調用。我通過在底層標準語言之上構建語言,通過宏和函數定義來實現這一點。因此,它不需要解析器或解釋器,具有應用數據的直接訪問,並且具有潛在的語言的控制流原語(只他們的一些)。
    其原因包括在描述性語言的流控制原語是用於他們的描述性的效用。中頻(測試)-ELSE-END構建體是說的兩組控制一個是依賴於(測試)的值將被顯示的方式。 FOR-END結構是一種說法,表示以多重性顯示的控件集合,例如線性控件陣列。如果需要,可以嵌套這些以獲得控件的2-D矩陣。一個子例程(帶參數)可以顯示一組控件,然後可以在多個位置調用該子控件多次複製該設置。如果DSL中沒有這樣的基元,那麼這樣的結構很難指定。

  • 該語言不應該要求指定UI的人必須處理僅爲實現而存在的問題,例如輸入事件處理,創建,刪除和控件命名以及控件和控件之間的數據移動應用數據。因此,例如,每個編輯,按鈕或其他控件都是一行代碼。處理按鈕單擊等事件的代碼直接寫入指定按鈕的代碼行(不在單獨的函數或閉包中)。控件與應用程序數據的綁定是在「底層」處理的,並不是UI程序員關心的問題。爲了完成所有這些工作,它基於一種稱爲差分執行的控制結構,我於1986年偶然發現它。它基於程序的增量重新執行,以便可以遞增地更新其輸出。在這種情況下,輸出是窗口表面上控件的集合。這些控件是爲了響應應用程序狀態的變化而自動創建,刪除,移動或以其他方式修改的,而不需要UI程序員根據狀態更改進行思考。

我只在桌面用戶界面中使用過這個功能,而且我幾乎沒有完成網頁開發。我敢肯定,相同的原則可以應用於網絡用戶界面,並且尚未完成。

+0

似乎你跳過了我的問題的一些部分。我正在談論一種非編程語言。正如我所說的,它應該更像是一個UML圖 - 用於預先實現GUI的任何實現。所以你正在談論從應用程序創建GUI,而我詢問了GUI架構師用來處理功能/行爲而不是外觀和定位的東西。 – naugtur 2010-04-28 17:09:46

+0

至於你的答案也處理有趣的東西,我更傾向於讓程序員只考慮事件/狀態變化。能夠忘記界面問題會很好,但是隨後你放鬆了對「外觀」的控制。而且大多數客戶的要求就像「這很好,但把它放在頂部,並給它一些漸變發光和陰影」。接下來是挖掘接口技術。這就是爲什麼我認爲應該沒有綁定控件,但接口應該是應用程序的客戶端,就像服務器一樣。 [接下來的評論] – naugtur 2010-04-28 17:15:20

+0

[continuation]然後邏輯只需要有一種API,客戶端大多隻是一個界面+連接應用程序,易於由界面人員維護。任何關於界面控件的抽象概念都很難輕鬆快速地做出客戶想要的任何愚蠢的無用變化,因爲它看起來更好,或者他的圖形設計師發現了一些新的Photoshop技巧。我看到(網絡)項目失敗的原因僅僅是因爲他們無法根據客戶對將數據作爲表格提供服務的期望而不是使用戶單擊每個項目來閱讀詳細信息。 – naugtur 2010-04-28 17:24:23

2

您可以使用傳統的建模符號進行UI建模,但很快就會出現混亂且無用的模型。 您應該考慮特定於域的模型,如WebML(很快將成爲名稱爲IFML的OMG標準)。在這種情況下,您還可以獲得一款名爲WebRatio的免費建模工具,該工具提供了快速原型設計以及與BPMN規範的集成。

[免責聲明:我與米蘭理工大學和WebRatio和WebML/IFML的發明者中]