1. 程式人生 > >電商之梳理UML相關知識-------建模使用

電商之梳理UML相關知識-------建模使用

統一建模語言 編輯
同義詞 UML(統一建模語言)一般指統一建模語言
本詞條由“科普中國”百科科學詞條編寫與應用工作專案 稽核 。
Unified Modeling Language (UML)又稱統一建模語言或標準建模語言,是始於1997年一個OMG標準,它是一個支援模型化和軟體系統開發的圖形化語言,為軟體開發的所有階段提供模型化和視覺化支援,包括由需求分析到規格,到構造和配置。 面向物件的分析與設計(OOA&D,OOAD)方法的發展在80年代末至90年代中出現了一個高潮,UML是這個高潮的產物。它不僅統一了Booch、Rumbaugh和Jacobson的表示方法,而且對其作了進一步的發展,並最終統一為大眾所接受的標準建模語言。
Grady Booch的描述物件集合和它們之間的關係的方法。James Rumbaugh的物件建模技術(OMT)。Ivar Jacobson的包括用例方法的方式。還有其他一些想法也對UML起到了作用,UML是Booch, Rumbaugh, Jacobson。UML已經被物件管理組織(OMG)接受為標準,這個組織還制定了通用物件請求代理體系結構(CORBA),是分散式物件程式設計行業的領頭羊。計算機輔助軟體工程(CASE)產品的供應商也支援UML,並且它基本上已經被所有的軟體開發產品製造商所認可,這其中包括IBM和微軟(用於它的VB環境)。
UML規範用來描述建模的概念有,類(物件的)、物件、關聯、職責、行為、介面、用例、包、順序、協作,以及狀態。[1]
作品名稱 統一建模語言 外文名稱 UML 作品別名 標準建模語言 創作年代 1997年 作 用 支援模型化和軟體開發 產 源 OOA&D,OOAD
目錄
1 歷史
2 主要內容
3 分類
4 特點
5 應用領域
6 發展歷史
7 圖
8 應用
9 建模工具
歷史
統一建模語言(UML,UnifiedModelingLanguage)是面向物件軟體的標準化建模語言。UML因其簡單、統一的特點,而且能表達軟體設計中的動態和靜態資訊,目前已成為視覺化建模語言的工業標準。在軟體無線電系統的開發過程中,統一建模語言可以在整個設計週期中使用,幫助設計者縮短設計時間,減少改進的成本,使軟硬體分割最優。
UML的演化可以分為幾個階段[1]:第一階段是3位面向物件(OO,Object-Oriented)方法學家Booch、Rumbaugh和Jacobson共同努力,形成了UML0.9;第二階段是公司的聯合行動,由十幾家公司(DEC、HP、I-Logix、IBM、Microsoft、Oracle、TI、RationalSoftware等)組成了UML成員協會,將各自意見加入UML,以完善和促進UML的定義工作,形成了UML1.0和1.1,並向物件管理組織(OMG,ObjectManagementGroup)申請成為建模語言規範的提案;第三階段是在OMG控制下對版本的不斷修訂和改進,其中UML1.3是較為重要的修訂版。
UML由3個要素構成:UML的基本構造塊、支配這些構造塊如何放置在一起的規則和運用於整個語言的公用機制。
UML有3種基本的構造塊:事物、關係和圖。
事物是對模型中最具有代表性的成分的抽象,包括結構事物,如類(Class)、介面(Interface)、協作(Collaboration)、用例(UseCase)、主動類(ActiveClass)、元件(Component)和節點(Node);行為事物,如互動(Interaction)、態機(Statemachine)、分組事物(包,Package)、註釋事物(註解,Note)。
關係用來把事物結合在一起,包括依賴、關聯、泛化和實現關係。
主要內容
UML是在Booch、OMT、OOSE等面向物件的方法及其它許多方法與資料的基礎上發展起來的。UML表示法集中了不同的圖形表示方法,剔除了其中容易引起的混淆、冗餘或者很少使用的符號,同時添加了一些新的符號。其中的概念來自於面向物件技術領域中眾多專家的思想。
UML從考慮系統的不同角度出發,定義了用例圖、類圖、物件圖、狀態圖、活動圖、序列圖、協作圖、構件圖、部署圖等9種圖。這些圖從不同的側面對系統進行描述。系統模型將這些不同的側面綜合成一致的整體,便於系統的分析和構造。儘管UML和其它開發工具還會設計出許多派生的檢視,但上述這些圖和其它輔助性的文件是軟體開發人員所見的最基本的構造。其中:
UML用例圖與OOSE中的用例圖類似。
UML的類圖綜合了OMT、Booch等面向物件方法中的類圖。
UML狀態圖是對David Harel所提出狀態圖的改進。
UML活動圖的基本語義和狀態圖大致相同,它類似於許多方法(包括面向物件技術之前的一些方法)中的工作流圖。
UML的協作圖是通過對Booch方法的物件圖、Fusion方法的物件互動圖以及其它一些方法中的相關圖表改造而成的。
UML的構建圖和部署圖是在Booch方法中的模組和程序圖(處理關係圖、處理器圖)的基礎上發展起來的。
UML簡化了建模方法,它揚棄了Booch、OMT或OOSE等方法中的糟粕,而代之以其它方法中的精華。UML一般不引入新的概念和符號,只有在沒有現有的解決方法可以借鑑時,UML的開發者們才考慮加入新的概念。UML的開發者們是在設計一種語言(儘管只是一種圖形化語言),因此必須在簡明(所有元素一律用方框和文字表示)和繁瑣(為每個元素設計單獨的符號)之間權衡。儘管如此,UML中還是增添了衍型和擴充套件機制等一些新的元素,因為這些元素在其它建模語言的實踐中已經被證明是非常有用的。[2]
用例圖主要用來描述 使用者、需求、系統功能單元 之間的關係。它展示了一個外部使用者能夠觀察到的系統功能模型圖。
【用途】:幫助開發團隊以一種視覺化的方式理解系統的功能需求。[3]
類圖顯示了一組類、介面、協作以及他們之間的關係。在UML中問題域最終要被逐步轉化,通過類來建模,通過程式語言構建這些類從而實現系統。類加上他們之間的關係就構成了類圖,類圖中還可以包含介面、包等元素,也可以包括物件、鏈等例項。[4]
物件圖(Object Diagram) 是顯示了一組物件和他們之間的關係。使用物件圖來說明資料結構,類圖中的類或元件等的例項的靜態快照。物件圖和類圖一樣反映系統的靜態過程,但它是從實際的或原型化的情景來表達的。
物件圖顯示某時刻物件和物件之間的關係。一個物件圖可看成一個類圖的特殊用例,例項和類可在其中顯示。物件也和合作圖相聯絡,合作圖顯示處於語境中的物件原型(類元角色)。
物件圖是類圖的例項,幾乎使用與類圖完全相同的標識。他們的不同點在於物件圖顯示類的多個物件例項,而不是實際的類。一個物件圖是類圖的一個例項。由於物件存在生命週期,因此物件圖只能在系統某一時間段存在。[5]
分類
UML定義了5類,10種模型圖
五種類圖定義:
1.用例圖:從使用者角度描述系統功能,並指各功能的操作者。
2.靜態圖:包括類圖,包圖,物件圖。
類圖:描述系統中類的靜態結構
包圖:是包和類組成的,表示包與包之間的關係,包圖描述系統的分層結構
物件圖:是類圖的例項
3.行為圖:描述系統動態模型和物件組成的交換關係。包括狀態圖和活動圖
活動圖:描述了業務實現用例的工作流程
狀態圖:是描述狀態到狀態控制流,常用於動態特性建模
4.互動圖:描述物件之間的互動關係
順序圖:物件之間的動態合作關係,強調物件傳送訊息的順序,同時顯示物件之間的互動
合作圖:描述物件之間的協助關係
5.實現圖:
配置圖:定義系統中軟硬體的物理體系結構

  
十種模型圖定義:
(1)、用例圖:展示系統外部的各類執行者與系統提供的各種用例之間的關係
(2)、類圖:展示系統中類的靜態結構
(3)、物件圖:是類圖的一種例項化圖(物件圖是對類圖的一種例項化)
(4)、包圖:是一種分組機制。在UML1.1版本中,包圖不再看作一種獨立的模型圖)
[6]
特點
(1)UML統一了各種方法對不同型別的系統、不同開發階段以及不同內部概念的不同觀點,從而有效的消除了各種建模語言之間不必要的差異。它實際上是一種通用的建模語言,可以為許多面向物件建模方法的使用者廣泛使用。
(2)UML建模能力比其它面向物件建模方法更強。它不僅適合於一般系統的開發,而且對並行、分散式系統的建模尤為適宜。
(3)UML是一種建模語言,而不是一個開發過程。[2]
應用領域
UML的目標是以面向物件圖的方式來描述任何型別的系統,具有很寬的應用領域。其中最常用的是建立軟體系統的模型,但它同樣可以用於描述非軟體領域的系統,如機械系統、企業機構或業務過程,以及處理複雜資料的資訊系統、具有實時要求的工業系統或工業過程等。總之,UML是一個通用的標準建模語言,可以對任何具有靜態結構和動態行為的系統進行建模。
此外,UML適用於系統開發過程中從需求規格描述到系統完成後測試的不同階段。在需求分析階段,可以用用例來捕獲使用者需求。通過用例建模,描述對系統感興趣的外部角色及其對系統(用例)的功能要求。分析階段主要關心問題域中的主要概念(如抽象、類和物件等)和機制,需要識別這些類以及它們相互間的關係,並用UML類圖來描述。為實現用例,類之間需要協作,這可以用UML動態模型來描述。在分析階段,只對問題域的物件(現實世界的概念)建模,而不考慮定義軟體系統中技術細節的類(如處理使用者介面、資料庫、通訊和並行性等問題的類)。這些技術細節將在設計階段引入,因此設計階段為構造階段提供更詳細的規格說明。
程式設計(構造)是一個獨立的階段,其任務是用面向物件程式語言將來自設計階段的類轉換成實際的程式碼。在用UML建立分析和設計模型時,應儘量避免考慮把模型轉換成某種特定的程式語言。因為在早期階段,模型僅僅是理解和分析系統結構的工具,過早考慮編碼問題十分不利於建立簡單正確的模型。
UML模型還可作為測試階段的依據。系統通常需要經過單元測試、整合測試、系統測試和驗收測試。不同的測試小組使用不同的UML圖作為測試依據:單元測試使用類圖和類規格說明;整合測試使用部件圖和合作圖;系統測試使用用例圖來驗證系統的行為;驗收測試由使用者進行,以驗證系統測試的結果是否滿足在分析階段確定的需求。
總之,標準建模語言UML適用於以面向物件技術來描述任何型別的系統,而且適用於系統開發的不同階段,從需求規格描述直至系統完成後的測試和維護。
發展歷史
1997年,OMG組織(Object Management Group物件管理組織)釋出了統一建模語言(Unified Modeling Language,UML)。UML的目標之一就是為開發團隊提供標準通用的設計語言來開發和構建計算機應用。UML提出了一套IT專業人員期待多年的統一的標準建模符號。通過使用UML,這些人員能夠閱讀和交流系統架構和設計規劃–就像建築工人多年來所使用的建築設計圖一樣。[7]
2003年,UML已經獲得了業界的認同。[7]
UML的是要成為一種標準的統一語言,使得IT專業人員能夠進行計算機應用程式的建模。UML的主要創始人是Jim Rumbaugh、Ivar Jacobson和Grady Booch,他們最初都有自己的建模方法(OMT、OOSE和Booch),彼此之間存在著競爭。最終,他們聯合起來創造了一種開放的標準。UML成為”標準”建模語言的原因之一在於,它與程式設計語言無關。而且,UML符號集只是一種語言而不是一種方法學。因為語言與方法學不同,它可以在不做任何更改的情況下很容易地適應任何公司的業務運作方式。
UML不是一種方法學,不需要任何正式的工作產品。而且它還提供了多種型別的模型描述圖(diagram),當在某種給定的方法學中使用這些圖時,它使得開發中的應用程式的更易理解。UML的內涵遠不只是這些模型描述圖,但是對於入門來說,這些圖對這門語言及其用法背後的基本原理提供了很好的介紹。通過把標準的UML圖放進工作產品中,精通UML的人員就更加容易加入專案並迅速進入角色。最常用的UML圖包括:用例圖、類圖、序列圖、狀態圖、活動圖、元件圖和部署圖。[7]
UML語言開發始於1994年8月,當時Rational軟體公司的Booch和Rumbaugh著手進行統一的Booch方法和OMT方法,以便以後得到一種統一的建模語言。1995年10月,他們釋出了統一方法(UM)的初級版本。同年秋天,Jacobson加盟聯合開發小組,併力圖把OOSE方法也統一進來。[2]
經過Booch、Rumbaugh和Jacobson的努力,UML0.9和0.91版在1996年的6月和10月出版。1996年,OMG(物件管理組)釋出了向外界徵集關於面向物件建模標準方法的訊息。UML的3位創始人開始與來自其它公司的軟體工程方法專家和開發人員一道制定了一套OMG感興趣的方法,並設計了一種被軟體開發工具提供者、軟體開發方法學家和開發人員這些終端使用者接受的建模語言。與此同時,其它一些相關人員也在做這項富有競爭性的工作。1997年9月1日產生了UML1.1,並提交到OMG進行討論。
OMG於1997年11月正式接納了UML1.1,然後成立任務組不斷的修訂,併產生了UML1.2、1.3和1.4版本,其中UML1.3是較為重要的修訂版本。該組織正在對UML進行重大修訂,其目標是推出UML2.0,做為向ISO提交的標準方案。[2]
[8]  公認的面向物件建模語言出現於20世紀70年代中期。從1989年到1994年,其數量從不到十種增加到了五十多種。在眾多的建模語言中,語言的創造者努力推崇自己的產品,並在實踐中不斷完善。但是,OO方法(Object-Oriented Method,面向物件的方法)的使用者並不瞭解不同建模語言的優缺點及相互之間的差異,因而很難根據應用特點選擇合適的建模語言,於是爆發了一場“方法大戰”。20世紀90年代中,一批新方法出現了,其中最引人注目的是Booch 1993、OOSE和OMT-2等。
Grady Booch是面向物件方法最早的倡導者之一,他提出了面向物件軟體工程的概念。1991年,他將以前面向Ada的工作擴充套件到整個面向物件設計領域。Booch 1993比較適合於系統的設計和構造。
James Rumbaugh等人提出了面向物件的建模技術(OMT,一種軟體開發方法)方法,採用了面向物件的概念,並引入各種獨立於語言的表示符。這種方法用物件模型、動態模型、功能模型和用例模型,共同完成對整個系統的建模,所定義的概念和符號可用於軟體開發的分析、設計和實現的全過程,軟體開發人員不必在開發過程的不同階段進行概念和符號的轉換。OMT-2特別適用於分析和描述以資料為中心的資訊系統。
Jacobson於1994年提出了OOSE方法,其最大特點是面向用例(Use-Case),並在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器,但用例貫穿於整個開發過程,包括對系統的測試和驗證。OOSE比較適合支援商業工程和需求分析。
此外,還有Coad/Yourdon方法,即著名的OOA/OOD,它是最早的面向物件的分析和設計方法之一。該方法簡單、易學,適合於面向物件技術的初學者使用,但由於該方法在處理能力方面的侷限,截至2013年已很少使用。
概括起來:首先,面對眾多的建模語言,使用者由於沒有能力區別不同語言之間的差別,因此很難找到一種比較適合其應用特點的語言;其次,眾多的建模語言實際上各有千秋;第三,雖然不同的建模語言大多雷同,但仍存在某些細微的差別,極大地妨礙了使用者之間的交流。因此在客觀上,極有必要在精心比較不同的建模語言優缺點及總結面向物件技術應用實踐的基礎上,組織聯合設計小組,根據應用需求,取其精華,去其糟粕,求同存異,統一建模語言。
1994年10月,Grady Booch和Jim Rumbaugh開始致力於這一工作。他們首先將Booch 93和OMT-2 統一起來,並於1995年10月釋出了第一個公開版本,稱之為統一方法UM 0.8(Unitied Method)。1995年秋,OOSE 的創始人Ivar Jacobson加盟到這一工作。經過Booch、Rumbaugh和Jacobson三人的共同努力,於1996年6月和10月分別釋出了兩個新的版本,即UML 0.9和UML 0.91,並將UM重新命名為UML(Unified Modeling Language)。
1996年,一些機構將UML作為其商業策略已日趨明顯。UML的開發者得到了來自公眾的正面反應,並倡議成立了UML成員協會,以完善、加強和促進UML的定義工作。當時的成員有DEC、HP、I-Logix、 Itellicorp、 IBM、ICON Computing、MCI Systemhouse、Microsoft、Oracle、Rational Software、TI以及Unisys。這一機構對UML 1.0(1997年1月)及UML 1.1(1997年11月17日)的定義和釋出起了重要的促進作用。
UML是一種定義良好、易於表達、功能強大且普遍適用的建模語言。它融入了軟體工程領域的新思想、新方法和新技術。它的作用域不限於支援面向物件的分析與設計,還支援從需求分析開始的軟體開發的全過程。
面向物件技術和UML的發展過程可用上圖來表示,標準建模語言的出現是其重要成果。在美國,截止1996年10月,UML獲得了工業界、科技界和應用界的廣泛支援,已有700多個公司表示支援採用UML作為建模語言。1996年底,UML已穩佔面向物件技術市場的85%,成為視覺化建模語言事實上的工業標準。1997年11月17日,OMG採納UML 1.1作為基於面向物件技術的標準建模語言。

圖聚集了相關的事物及其關係的組合,是軟體系統在不同角度的投影。圖由代表事物的頂點和代表關係的連通圖表示。下面對常用的幾類圖[2-12]進行簡單介紹。
(1)類圖(ClassDiagram)。展現了一組物件、介面、協作和它們之間的關係。類圖描述的是一種靜態關係,在系統的整個生命週期都是有效的,是面向物件系統的建模中最常見的圖。
(2)物件圖(ObjectDiagram)。展現了一組物件以及它們之間的關係。物件圖是類圖的例項,幾乎使用與類圖完全相同的標示。
(3)用例圖(UseCaseDiagram)。展現了一組用例、參與者(actor)以及它們之間的關係。用例圖從使用者角度描述系統的靜態使用情況,用於建立需求模型。
(4)互動圖。用於描述物件間的互動關係,由一組物件和它們之間的關係組成,包含它們之間可能傳遞的訊息。互動圖又分為序列圖和協作圖,其中序列圖描述了以時間順序組織的物件之間的互動活動;協作圖強調收發訊息的物件的結構組織。
(5)狀態圖(StateDiagram)。由狀態、轉換、事件和活動組成,描述類的物件所有可能的狀態以及事件發生時的轉移條件。通常狀態圖是對類圖的補充,僅需為那些有多個狀態的、行為隨外界環境而改變的類畫狀態圖。
(6)活動圖(ActiveDiagram)。一種特殊的狀態圖,展現了系統內一個活動到另一個活動的流程。活動圖有利於識別並行活動。
(7)元件圖(ComponentDiagram)。展現了一組元件的物理結構和元件之間的依賴關係。部件圖有助於分析和理解元件之間的相互影響程度。
(8)部署圖(DeploymentDiagram)。展現了執行處理節點以及其中的元件的配置。部署圖給出了系統的體系結構和靜態實施檢視。它與元件圖相關,通常一個節點包含一個或多個構建。
需要指出的是,UML並不限定僅使用這9種圖,開發工具可以採用UML來提供其他種類的圖,但到目前為止,這9種圖在實際應用中最常用的。綜合建模型別、模型圖種類、建模機制,UML的建模體系見表1。
表1 UML建模體系
模型型別
模型圖種類
建模機制
用例模型
用例模型圖
靜態建模
靜態模型
類圖、物件圖、包圖
靜態建模
行為模型
狀態圖、活動圖
動態建模
互動模型
序列圖、協作圖
動態建模
實現模型
元件圖、配置圖
靜態建模
應用
目前,UML已成功應用於電信、金融、政府、電子、國防、航天航空、製造與工業自動化、醫療、交通、電子商務等領域中。在這些領域中,UML的建模包括大型、複雜、實時、分散式、集中式資料或者計算,以及嵌入式系統等,而且還用於軟體再生工程、質量管理、過程管理、配置管理的各方面。在軟體無線電技術中,UML的應用是可行的,而且具有優勢。
建模語言可被不同種類的無線電通訊和H/S(Hardware/Software)描述語言所應用。軟體無線電的物件需要具有可配置性及元件可重用性。系統設計階段對語言的要求表現在功能和結構兩個方面。功能設計需要一種對通訊規範進行建模的語言,而結構設計要求一種對軟體和硬體元件進行建模的語言。軟體無線電可以選擇許多語言,一般來講,UML的效能在面向物件和適應性方面是較好的。
進行聯合設計的UML在序列圖、狀態圖、合作圖以及實時擴充套件的幫助下,能很好地為元件和模組之間的相互聯絡構造模型,而且能在整個設計週期中使用,以幫助設計者縮短設計時間、降低改進成本並使軟/硬體分割最優。與UML相比,一些建模語言有其自身的缺陷。比如SDL在傳統意義上缺乏模組性,VHDL對軟體建模來說效率不高等。
UML將硬體和軟體作為一個整體來進行建模。例如,由於規範的不穩定性,設計者可以從硬體移動一些協議到軟體。在UML的幫助下,硬體元件和軟體元件之間將會有更大的透明度。便攜性和綜合效率將會增加。
通常來講,對於使用UML進行硬體軟體聯合設計而言可以應用下面的技術[46]:
(1)UML的模型特性可幫助設計者將協議分割成硬體模組和軟體模組,它們之間的相互關係可以用UML的類圖或元件圖進行描述;
(2)UML狀態圖或序列圖可使互動處理的通訊更加簡明扼要;
(3)軟體綜合和硬體綜合可通過使用實時嵌入式UML而被建模,實時嵌入式UML以將並行任務分配給一個特定的處理器為目標,並將計算步驟分解到各個時鐘週期中;
(4)一旦設計者通過使用類圖或元件圖獲得介面和元件的資訊,則不同種類規範的併發執行和聯合模擬都將變得更容易。
綜合來看,UML作為一種最合適的建模語言,其應用於軟體無線電之中是可實現的,也是非常有前途的。UML在軟體無線電中得以應用,必將極大地促進軟體無線電技術的發展。
建模工具
ProcessOn線上設計器支援UML統一建模語言的定義和語義,同時支援UML的用例圖和靜態圖線上建模。

相關推薦

梳理UML相關知識-------建模使用

統一建模語言 編輯 同義詞 UML(統一建模語言)一般指統一建模語言 本詞條由“科普中國”百科科學詞條編寫與應用工作專案 稽核 。 Unified Modeling Language (UML)又稱統一建模語言或標準建模語言,是始於1997年一個OMG標準

梳理rabbitmq相關知識---通訊--訊息佇列

rabbitmq 編輯 MQ全稱為Message Queue, 訊息佇列(MQ)是一種應用程式對應用程式的通訊方法。應用程式通過讀寫出入佇列的訊息(針對應用程式的資料)來通訊,而無需專用連線來連結它們。訊息傳遞指的是程式之間通過在訊息中傳送資料進行通訊,而不是

梳理mongodb相關知識---分散式資料庫

mongodb 《mongodb》是2013年中國鐵道出版社出版的圖書,作者是鄒貴金。該書介紹了MongoDB基礎、應用、管理、效能優化、資料庫的架構,環境搭建例項,程式設計例項等內容。 書 名 mongodb 作 者 鄒貴金 出版社中國鐵道出

梳理Hbase相關知識---分散式資料庫

HBase 本詞條由“科普中國”百科科學詞條編寫與應用工作專案 稽核 。 HBase是一個分散式的、面向列的開源資料庫,該技術來源於 Fay Chang 所撰寫的Google論文“Bigtable:一個結構化資料的分散式儲存系統”。就像Bigtable利用了

梳理Flume相關知識---資料採集

flume Flume是Cloudera提供的一個高可用的,高可靠的,分散式的海量日誌採集、聚合和傳輸的系統,Flume支援在日誌系統中定製各類資料傳送方,用於收集資料;同時,Flume提供對資料進行簡單處理,並寫到各種資料接受方(可定製)的能力。 當前F

梳理mysql相關知識---資料庫

MySQL資料庫 編輯 MySQL是一種開放原始碼的關係型資料庫管理系統(RDBMS),MySQL資料庫系統使用最常用的資料庫管理語言–結構化查詢語言(SQL)進行資料庫管理。 中文名 MySQL資料庫 類 型開放原始碼的關係型 說 明資料庫管理

梳理Nginx(7層)相關知識---反向代理以及負載均衡

nginx 編輯 Nginx (“engine x”) 是一個高效能的HTTP和反向代理伺服器,也是一個IMAP/POP3/SMTP伺服器。Nginx是由Igor Sysoev為俄羅斯訪問量第二的Rambler.ru站點開發的,第一個公開版本0.1.0釋出於2

梳理servlet知識---javaweb基礎

servelt 是用java程式編寫的伺服器端程式,其主要功能是互動地瀏覽和修改資料(查詢和修改)。狹義說的是介面,廣義是指實現該介面的servlet類。 響應任何型別的請求,但是絕大數情況被用來 擴充套件基於HTTP協議的web伺服器的效

促銷優惠規則業務分析建模

分析 type 模型 最終 過程 下單 橋模式 優惠 edit 轉:http://craft6.cn/detail/b2c_promotion_2017.do?tagKey=promotion 1常 見 的 電 商 促 銷 場 景 左

深圳紐仕達家可信嗎?

多個 90後 html5 網頁設計 實現 電商 店鋪 同時 資源 電商行業越發而壯大,很多傳統行業都跑來做電商,在“魚龍混雜”的商業世界,我們要懂得分清誰才是“龍”,如此才能節約資源,上升到絕佳境界,從而獲得實在的東西,深圳電商之家帶你看清電商的真面目。 ? ? ? ?先了

演算法與資料結構堆的相關知識,簡單易懂。

十、 二叉堆之Java的實現 1) 概要 前面分別通過C和C++實現了二叉堆,本章給出二叉堆的Java版本。還是那句話,它們的原理一樣,擇其一瞭解即可。 目錄 1. 二叉堆的介紹 2. 二叉堆的圖文解析 3. 二叉堆的Java實現(完整原始碼) 4. 二叉堆的Java測試程式

團購與B2C模式以及B2B2C模式對比

一、概述 1、代表性的網站 團購的代表性網站莫過於國外的groupon和國內的“聚划算”這兩個網站。核心模式就是針對某個產品多人下訂單,達到一定訂單數,就以一個特定的價格(不一定是最低的價格...)給所有買家發貨。如果沒達到團購的條件,那麼錢將會退回買家的賬戶中,此產品的團

演算法與資料結構圖的相關知識,簡單易懂。

一、    圖的理論基礎 1)  概要 本章介紹資料結構中圖的基本概念。 目錄 1. 圖的基本概念 2. 圖的儲存結構 2)  圖的基本概念 1. 圖的定義 定義:圖(graph)是由一些點(vertex)和這些點之間的連線(edge)所組成的;其中,點通常被

[資料倉庫]核心業務知識訂單商品模組

電商核心業務知識 訂單商品模組(9張表) --訂單主要資訊表 drop table if exists itqsc.ods_b2c_orders; create external table itqsc.ods_b2c_orders ( order_id  bigint, -

使用 mybatis + flying + 雙向相關建模後端

程式碼下載地址: mybatis.flying 眾所周知,mybatis 雖然易於上手,但放到網際網路環境下使用時,不可避免的要面對諸如‘’一級快取存在髒資料‘’、‘’需要寫大量明文 SQL 語句‘’等問題。對於這些問題 mybatis

萬物皆可,生鮮的坎坷

生鮮電商  雖然現在還沒達到萬物皆可電商的地步,但是一些電商平臺確實是以此為目標向前邁步。而作為實現這個目標的非常重要的一步,就是生鮮。例如最近的大櫻桃不是到季節了嘛,各個電商大企業便開始用其“練手”。  ▲順豐航空的櫻桃專機,一架波音737貨機正在裝載櫻桃。供圖/東方IC  首先,軟件產品網要給大家普及一下

分布式架構設計平臺

用戶服 base 介紹 val 重要 本地 交互 pac 一定的 分布式架構設計之電商平臺 何為軟件架構?不同人的答案會有所不同,而我認為一個好的軟件架構除了要具備業務功能外,還應該具備一定的高性能、高可用、高伸縮性及可拓展等非功能需求。而軟件架構是由業務架構和技術架構

網站商品模型商品詳情頁設計方案

查詢 amp 多對一關系 int cor http 添加 com 托盤 如下設計方案參考淘寶和華為商城 SKU SPU的關系 SPU = Standard Product Unit (標準產品單位) SPU是商品信息聚合的最小單位,是一組可復用、易檢索的標準化信息的集合,該

PMP總結變更相關知識

得到 控制系統 角色 原因 10個 實現 組成 相關 情況 首先總結一下PMBOK哪些過程會輸出變更請求。總共有16個過程會輸出變更請求,它們是:(1)一個規劃過程組:規劃采購管理。采購計劃可以較晚編制,故采購計劃編制可能導致對以前的已經形成的計劃的修改。(2)5個執行過程

巨人大哥談平臺框架後臺管理框架

交易 exc 行修改 出版社 管理系 搜索 平臺 信息 自定義 巨人大哥談電商平臺框架之後臺管理框架 一級目錄 二級目錄 欄目 簡介 網站設置 基本設置 網站設置 可以自定義網站參數 系統設置 可以對系統進行相關參數設