웹킷 어디까지 왔나?
(GPU 가속 feature를 중심으로...)


웹킷 뉴스 그룹에서의 주요 안건들 요약
* HTML5 Microdata 지원 공지 (2011/9/22 : New feature announcement - Implement HTML5 Microdata in WebKit)
* HTML5 WebWorker 관련 기능 구현 논의 (2011/9/23 : starting implementation of postMessage tranferables)
* HTML5 Canvas 관련 기능 구현 논의 (2011/9/13 : Mouse Lock API)
* HTML5 time element 관련 기능 구현 논의 (2011/9/16 : Implementing HTML5 time element)
==> 요약: 현재 WebKit 진영에서는 CSS3와 HTML5에 관한 구현 논의가 주요 이슈임


GPU 가속 관련 현황 요약
* GPU는 CPU와 달리 데이터 병렬성이 풍부해 대용량 데이터 처리에 효율적임
* HTML5 Video를 이용 브라우저에서 HD 영상을 표시하기 위해서는 GPU 가속 기능 활용이 필수적임
* WebKit은 화면 처리를 위해 software rendering path와 hardware accelerated path를 제공함
* GPU 가속 feature는 WebKit 차원에서는 종료된 문제임; GPU 가속 기능 제공 여부는 브라우저 port의 문제임
* 애플의 사파리 브라우저는 오래전부터 hardware accelerated path를 심도 깊게 활용함; GPU 가속 기능 제공함
* 애플의 모바일 사파리 브라우저도 아이폰을 처음 출시할 때부터 GPU 가속 기능을 제공함
* 구글의 크롬 브라우저는 2010년 9월 (크롬7) 부터 GPU 가속 기능을 제공하기 시작함
* 구글의 폰용 안드로이드 브라우저는 아직 GPU 가속 기능을 제공하지 않음 (2011/10/19 현재)
* 구글의 패드용 안드로이드는 (안드로이드 3.0 허니콤은) GPU 가속 기능을 제공하나 아직 최적화 되지 않음; 간혹 화면이 깨지는 문제, 성능 문제 등이 보임 (2011/10/19 현재)
* 구글이 곧 발표할 아이스크림 샌드위치는 스마트 폰에서도 GPU 가속 기능을 제공하리라 전망함. 하지만 아직(2011/10/19)까지 구글의 명시적인 발표는 없음; 오늘(2011/10/21) 아이스크림 샌드위치 발표함. GPU 가속 지원 현황에 대해 좀 더 조사가 필요함 (젠장...)
==> 이제 Android 4.0을 (아이스크림 샌드위치를) 사용하는 모든 단말은 GPU 가속 기능을 제공해야 한다. 이로 인해 모든 안드로이드 App (웹 브라우저도 포함하겠지?..)은 GPU 가속 기능의 혜택을 누릴 수 있게 됐다. (2011.10.24. 내용 추가함. GPU 가속 기능이 OS 차원에서 지원된다는 얘기)
http://developer.android.com/sdk/android-4.0-highlights.html#DeveloperApis
(Hardware-accelerated 2D drawing
All Android-powered devices running Android 4.0 are required to support hardware-accelerated 2D drawing. Developers can take advantage of this to add great UI effects while maintaining optimal performance on high-resolution screens, even on phones. For example, developers can rely on accelerated scaling, rotation, and other 2D operations, as well as accelerated UI components such as TextureView and compositing modes such as filtering, blending, and opacity.)
  

Reference
* 브라우저에서 그래픽 가속하기 (from WebKit mailing-group)
* Accelerated 2D Tesselation Implementation (from WebKit mailing-group)
* Chromium "GPU" LayoutTests (from WebKit mailing-group)
* GPU Accelerated Compositing in Chrome (from Chrome 개발자 사이트)
* Google Activates Chrome GPU Acceleration
* Guess who is WebKit’s new best friend
* Issue 6914: Make android use the GPU (if available) for UI and browsing (안드로이드 이슈 페이지)
 
(이상)
 

JavaScriptCore 현황

(JSC와 SquirrelFish, SFX의 관계에 관해)

 

 

요약

l  SquirrelFish와 SquirrelFishExtreme(SFX)는 JavaScriptCore의 아키텍처를 개선하여 실행성능을 향상시킬 목적으로 WebKit 엔지니어들이 시작한 프로젝트의 코드네임

n  SquirrelFish는 bytecode VM 방식을 구현하기 위해 시작한 프로젝트

n  SFX (SquirrelFishExtreme)은 native code JIT 방식을 구현하기 위해 시작한 프로젝트

l  2008년 6월 SquirrelFish가 WebKit SVN trunk에 통합됨

n  (SquirrelFish가 WebKit SVN main trunk에 통합된) 현재 상황에서 JSC와 SquirrelFish, SFX는 동일함

l  현재 Linux ARM JIT는 지원하나 WinCE ARM JIT는 지원하고 있지 않음

 

 

WIKI 백과 중에서
http://en.wikipedia.org/wiki/WebKit#JavaScriptCore

l  2008/6/2 WebKit 프로젝트가 JavaScriptCore를 “SquirrelFish (bytecode interpreter)”로 rewrite 했음을 발표함

l  2008/9/18 x86 JIT (SFX: SquirrelFishExtreme)를 발표함

l  2009/1 Mac OSX on x86-64 JIT 발표함

 

 

뉴스그룹 중에서

2008/5/18/공지
http://old.nabble.com/The-SquirrelFish-Cometh-to17298445.html#a17298445

l  기존 JavaScriptCore는 AST 기반 인터프리터였다. 성능에 관한 아키텍처적 문제가 있었다

l  그래서 bytecode VM 아키텍처의 SquirrelFish 프로젝트를 시작했다

l  별도의 SVN repository에서 작업을 진행했으나 조만간 main trunk에 통합할 것이다

 

2008/6/98/질문: WebKitGtk 최신 소스에 SquirrelFish JS-engine이 적용되어 있는가?
http://old.nabble.com/Get-SquirrelFish-for-Webkit-in-linux-to17724999.html#a17724999

ð  2주전에 merge됐다.

 

2008/6/13/공지
http://old.nabble.com/JavaScriptCore-directory-reorganization-to17816031.html#a17816031

l  SquirrelFish가 완료되어 SVN trunk의 JavaScriptCore 디렉토리를 변경한다

 

2008/12/24/질문: SFX가 non-x86 JIT를 지원하는가?
http://old.nabble.com/SquirrelFish-Extreme-for-non-x-86-platforms-td21159116.html

ð  JIT는 아직 x86만 지원한다

ð  JIT를 기타 CPU로 포팅하는 것을 고려 중이다

ð  JIT가 bytecode 모델보다 효율적일지 판단 중이다. JIT는 메모리를 압도적으로 많이 사용한다

 

2009/12/11/질문: WinCE JIT 어찌되어 가나?
http://old.nabble.com/JIT-on-Windows-CE-to26740395.html#a26740395

ð  개발 중이다.

 

 

 

(이상입니다.)

 

간단한 내용이지만 고생하는 누군가에게 도움이 되면 좋겠다.

PC에서 Visual Studio 디버그 모드로 웹킷을 실행시켰다 종료시키면 기절할 정도로 많은 메모리 leak이 보고된다.
처음엔 명성 높은 웹킷 소스에서 그토록 많은 leak이 쏟아진다는 것이 믿어지지 않았다. 처음 프로그래밍을 배울 때 메모리 leak은 하나도 남김 없이 제거해야 할 절대 악으로 배웠다. 그래서 메모리 leak에 대해서는 강박관념에 가까운 혐오를 갖고 있다. 그런데 결론을 말하자면 WebKit 소스가 종료시 내는 leak은 의도적인 것이라고 한다. 종료 시점에 사용하던 메모리를 해지하는 절차를 생략함으로써 (해당 절차를 OS에게 맡김으로써) 처리 속도를 높이는 것이 설계 취지란다. 딱히 반박할 수도 없고... 경우에 따라서는 합리적인 판단일 수도 있겠다 하고 수긍하고 있다. 관련된 뉴스 그룹 기사는 다음과 같다.

http://www.nabble.com/freeing-static-variables-to24714380.html


뉴스 그룹 기사를 요약하면 다음과 같다.

static global 변수의 leak은 의도적이다 (by "Adam Treat-2")
* 웹킷은 static global 변수의 해지(clean up)에 관여하지 않는다. 해당 작업은 OS에게 맡긴다.

의도적인 leak에 대한 태클 (by "Zoltan" and "Antonio Gomes")
* 보고되는 leak이 너무 많아, 실제 주의해야 할 개발자의 실수에 의한 leak을 알아내기 어렵다.
* WebKit을 어플리케이션 형태가 아닌 다른 어플리케이션의 플러그인 형태로 사용할 경우, WebKit 플러그인을 내릴 때 leak이 발생하면 문제가 된다.


참고를 위해 뉴스 기사 원문을 아래와 같이 첨부한다.

_______________________________________________
freeing static variables 
by Zoltan Herczeg Jul 29, 2009; 05:05pm

Hi all,

Valgrind reports a lot of memory leaks when QtLauncher quits, because many
static local variables are not freed. I did a little research and realized
there is no consistent way to define static variables in webkit:

WebCore/css/CSSSelector.cpp: CSSSelector::extractPseudoType()
   using a DEFINE_STATIC_LOCAL() macro

WebCore/bindings/js/JSDOMWindowBase.cpp:
JSDOMWindowBase::commonJSGlobalData()
   static JSGlobalData* globalData;

WebCore/platform/qt/CursorQt.cpp:
   Cursors* Cursors::s_self = 0; (no static keyword)

I belive it would be a good thing to define a template for static
variables, which can (optionally) free static variables (enabled in debug
mode, but sometimes it would be good to enable it in release mode as well)

And I am wondering whether it would be worth to free (some) static
variables if they are used in a given time period. This may help to reduce
the memory consumption in the long run. This would be an optional feature,
an extra flag (or timeout value) for the template, which can be enabled or
disabled at compile time. If disabled, the value of this flag is not used
at all.

Regards
Zoltan

_______________________________________________
Re: freeing static variables 
by Zoltan Herczeg Jul 30, 2009; 03:55pm

Hi,

any thoughts on this? I hope my qestion was clear :) I would like to pack
the static declarations into wrapper classes, so we can add platform
and/or compilation mode (debug/release) dependent functionality to all
static variables (i.e: freeing them on exit).

Zoltan

_______________________________________________
Re: freeing static variables 
by tonikitoo (Antonio Gomes) Jul 30, 2009; 11:06pm

Zoltan, I think it would be a great add from a embedder-dev point of view.

Particularly, such leaks have been faced here in a soon past, when we
were loading a webkit browser as a plugin, and not as an application
by itself. So, we the webkit plugin was unloaded, it used to left
behind lots of leaks affecting the (main)  loader application, and as
we you might imagine many of this leaks were from global vars
(including in dependency libs , e.g. fontconfig =/)

--Antonio Gomes

_______________________________________________
Re: freeing static variables 
by Adam Treat-2 Jul 30, 2009; 11:26pm

On Thursday 30 July 2009 02:55:18 am Zoltan Herczeg wrote:
> Hi,
>
> any thoughts on this? I hope my qestion was clear :) I would like to pack
> the static declarations into wrapper classes, so we can add platform
> and/or compilation mode (debug/release) dependent functionality to all
> static variables (i.e: freeing them on exit).
>
> Zoltan

I've tried this before and it didn't work out so well.  The order in which you
free them becomes very important and error prone.  

And, of course, whatever solution you make has to be optional and easy to
maintain as the default policy in WebKit is to not care - by design - about
cleaning up after static globals on exit as that is left to the OS.

Another strategy for the embedded case where you want to free everything on
exit is to create a custom memory handler that will do this for you.

Cheers,
Adam

_______________________________________________
Re: freeing static variables 
by Zoltan Herczeg Aug 05, 2009; 12:10am

Hi Adam,

thank you for your suggestions. I have something similar in my mind.

I have opened a bugzilla entry and submited an early patch draft about my
concept:
https://bugs.webkit.org/show_bug.cgi?id=27980

The patch frees memory objects in a reversed creation order, and seemed
working well with QtLauncher (although only a subset of static variables
are freed right now). Do you know about special cases when this approach
is not enough?

Actually it is hard to find real memory leaks in the output of valgrind
because many of them are related to static variables. I hope this feature
will help to the leak hunters in the future.

Cheers,
Zoltan

 (끝)

JavaScriptCore를 변형해 쓰기 위해 분석하고 있다. 다음은 JSC에 관한 간단한 클래스 다이어그램이다. 웹킷을 사용하는 엔지니어들에게 도움이 되면 좋겠다.


다음은 JSC관련 객체들의 라이프사이클에 관한 메모이다.

• WebCore::JSDOMWindow 인스턴스는 (다시 말해 JSC::JSGlobalObject 인스턴스는) 페이지를 새로 로드할 때마다 새로 만든다.
• JSC::GlobalData 인스턴스는 application과 life-cycle을 같이 한다 (즉, 한번 만들면 어플리케이션을 종료시킬 때까지 같은 놈을 사용한다).

 (끝)

WebKit을 갖고 작업할 때, 꼭 풀어야 하는 문제중 하나가 커스텀 JS Object를 추가하는 일이다. 관련 자료를 아래와 같이 요약한다.

JS Object 확장 방식

 

 

관련 뉴스그룹 기사

http://www.nabble.com/Extending-webkit-javascript-td21517784.html#a21536928

l  frameLoadDelegate2::didClearWindowObject()가 custom JS object를 JS context에 등록하는 최적의 자리다. 해당 함수는 현재 web 문서의 스크립트가 실행되기 직전에 호출된다.

 

 

커스텀 JS Object 추가 절차 요약

l  $/JavaScriptCore/API/tests/testapi.c 파일과
$/JavaScriptCore/API/JSObjectRef.h 파일에 유용한 정보가 있다.

l  JSClassDefinition 구조체의 staticValues 필드와 staticFunctions 필드를 이용하는 것이 커스텀 속성을 가진 커스텀 JS Object를 정의하는 가장 간단한 방법이다.

l  커스텀 속성을 가진 커스텀 객체를 정의하려면…

n  커스텀 속성을 위한 get 함수와 set 함수를 준비한다 (ingeeGetPropFunc 함수)

n  커스텀 속성 테이블 JSStaticValue 배열을 준비한다 (ingeePorpArr 배열)

n  커스텀 객체를 위한 JSClassDefinition을 정의한다 (ingeeClassDef 변수)

n  적절한 시점에 JSClassCreate() 함수를 호출하여 타입을 등록한다

n  적절한 시점에 JSObjectMake() 함수를 호출하여 객체를 생성한다

 

static JSValueRef ingeeGetPropFunc

( JSContextRef ctx

, JSObjectRef object

, JSStringRef propertyName

, JSValueRef* exception

)

{

return JSValueMakeUndefined(ctx); //undefined-value 리턴 (단지 샘플...)

}

 

static JSStaticValue ingeePorpArr[]=

{ { "prop1", ingeeGetPropFunc, 0, kJSPropertyAttributeNone }

, { "prop2", ingeeGetPropFunc, 0, kJSPropertyAttributeNone }

, { "prop3", ingeeGetPropFunc, 0, kJSPropertyAttributeNone }

, { 0, 0, 0, 0 }

};

 

static JSClassDefinition ingeeClassDef=

{ 0 //ver

, kJSClassAttributeNone //attributes

, "PersonObject" //className

, 0 //parentClass

, ingeePorpArr //staticValues

, 0 //staticFunctions

, 0 //initialize

, 0 //finalize

, 0 //hasProperty

, 0 //getProperty

, 0 //setProperty

, 0 //deleteProperty

, 0 //getPropertyNames

, 0 //callAsFunction

, 0 //callAsConstructor

, 0 //hasInstance

, 0 //convertToType

};

 

JSValue* SomeFuncToCreateJSObject( ExecState* exec )

{

static JSClassRef ingeeClass;

if (!ingeeClass)

ingeeClass= JSClassCreate(&ingeeClassDef);

 

JSContextRef ctx= JSC::toRef(exec);

JSObjectRef objRef= JSObjectMake(ctx, ingeeClass, (void*)0/*someData*/ );

return JSC::toJS(objRef);

}

 

 

(끝)

본 기사는 2008년 12월 버전 (rev. 39476) WebKit win32 port를 기준으로 한다.

http://webkit.org에 존재하는 “WebKit Objective-C Programming Guide” 문서를 보면 다음과 같은 그림이 존재한다.

이 그림에서 aWebFrameView는 폐기됐다 (적어도 windows port에서는…). 지금 현실에 맞게 그림을 재구성하면 다음과 같다.

• WebView는 WebKit 엔진을 담고 있는 main-window를 나타내는 개념이다.
• WebFrame은 WebKit이 표시하는 페이지를 나타내는 개념이다.
• WebView는 1개의 WebFrame을 main-frame 멤버로 갖는다.
• WebFrame은 0개 또는 여러 개의 WebFrame을 children 멤버로 가질 수 있다 (HTML & 태그 처리…).

화면 구성 요소들에 대한 클래스 다이어그램은 다음과 같다.

언제나처럼 이미지를 클릭하면 원본 크기로 볼 수 있다.

 

이전 기사에서 사용자가 URL을 입력했을 때, WebKit이 해당 페이지를 load 하는 시퀀스를 분석했었다. 이번에는 페이지가 load되어 있는 상태에서 사용자가 웹페이지의 HTML Anchor를 클릭했을 때 WebKit이 새로운 페이지를 load 하는 시퀀스를 정리한다. 서론이 다소 길었다. 사실 다음 시퀀스 다이어그램이 전부다. FrameLoader::loadWithDocumentLoader() 이후의 시퀀스는 이전 기사의 FrameLoader::load(docLoader) 호출 이후의 시퀀스와 동일하다.



이미지를 클릭하면 원본 크기로 볼 수 있다.

WebKit의 핵심 시퀀스를 요약하면 아마 다음과 같을 것이다.
- URL 문서를 loading 하는 시퀀스
- loading한 문서를 parsing 하는 시퀀스
- parsing된 내용의 layout을 결정하는 시퀀스
- 구성한 화면을 출력하는 시퀀스

이들중 "URL 문서를 loading하는 시퀀스"를 분석하게 됐다.
WebKit을 갖고 일하는 개발자들에게 조금이라도 보탬이 되면 좋겠다. 혹시나 분석한 내용에 오류가 있다면, 댓글이나 트랙백으로 가르침 주시기 바란다. 분석에 사용한 WebKit은 작년말(2008년 12월) 버전이며 (rev. 39476), cURL을 사용하는 win32 port를 기준으로 하고 있다.

URL을 load 하는 시퀀스를 분석하면서 WebKit에 존재하는 수 많은 종류의 loader들 때문에 골치 아팠다. 대강의 내용을 정리하면 다음과 같다 (클래스 다이어그램에 메모박스로 주석 달아 놓았다).
- FrameLoader : URL-load 과정을 총괄하는 loader (1개의 frame에는 여러개의 web-page가 load될 수 있다).
- DocumentLoader : 1개의 web-page load를 책임지는 loader.
- MainResourceLoader : base-document (HTML 문서) load를 책임지는 loader.
- ResourceLoader : sub-document (CSS, js, image, ...) load를 책임지는 loader.

분석한 내용을 다음 2장의 UML 다이어그램으로 정리한다. 이미지를 클릭하면 원본 크기로 볼 수 있다.


<<URL load 과정에 참여하는 Class 들>>

 

<<URL load 간단 시퀀스 (HTML 파일 1개로만 이루어진 페이지 load 시퀀스)>>

분석을 위해 다음과 같은 뉴스그룹 기사들을 참고했다. 다른 사람들에게도 참고가 되기를 바라며, 해석 없이 그대로 올린다.

---

"문서 load 시퀀스"
from http://osdir.com/ml/opendarwin.webkit.devel/2006-10/msg00041.html
======================================================================

Main resource loaded, started from app via API:

[ WebFrame ] (ObjC, WebKit)
[ FrameLoader ] (C++, WebCore) ---> [ FrameLoaderClient ] (C++ abstract base class, implemented in webkit to deliver delegates)
 [ DocumentLoader ] (C++, WebCore)
[ MainResourceLoader ]  (C++, WebCore)
[ ResourceLoader ] (C++, WebCore)
[ FrameLoader ] (C++, WebCore)

 

Main resource loaded, started from engine via link click or form submission:

[ FrameLoader ] (C++, WebCore) ---> [ FrameLoaderClient ] (C++ abstract base class, implemented in webkit to deliver delegates)
 [ DocumentLoader ] (C++, WebCore)
[ MainResourceLoader ]  (C++, WebCore)
[ ResourceLoader ] (C++, WebCore)
[ FrameLoader ] (C++, WebCore)

Subresource load:

[ DocumentLoader ]  (C++, WebCore)
[ Cache ] (C++, WebCore)
[ FrameLoader ] (C++, WebCore) ---> [ FrameLoaderClient ] (C++ abstract base class, implemented in webkit to deliver delegates)
 [ SubresourceLoader ] (C++, WebCore)
[ ResourceLoader ] (C++, WebCore)
[ Cache ] (C++, WebCore)
[ CachedResource ] (C++ WebCore)

 

"Loader의 종류 및 역할"
from http://www.nabble.com/Role-of-all-loaders-to22115931.html#a22172592
========================================================================

Re: Role of all loaders  
by Darin Adler Feb 24, 2009; 08:28am :: Rate this Message:    (use ratings to moderate[?])

> FrameLoader

Controls the process of loading web pages into a frame. Contains all  
the loading-related functions and data instead of having them all on  
Frame itself. There’s one of these for each frame.

> DocumentLoader

Controls the process of loading one particular web page into a frame.  
When a new page is loaded, the frame loader creates a new document  
loader and then later destroys the old one.

> DocLoader

Part of the caching machinery. Manages the cached loading for a  
particular document. May be merged with DocumentLoader at some point  
in the future, or perhaps renamed.

> MainResourceLoader

FrameLoader and DocumentLoader use ResourceLoader objects to load  
individual resources. The main resource is the HTML file (or SVG file  
or whatever). The ResourceLoader for the main resource is a  
MainResourceLoader.

> Sub resource Loader

The ResourceLoader objects for subresources such as images, scripts,  
and CSS style sheets are SubresourceLoader objects.

     -- Darin

 

"URL loading중 발생하는 frameLoaderClient를 통한 이벤트"
from http://www.nabble.com/FrameLoaderClient-notifications-to16025970.html#a16030339
=====================================================================================
Re: FrameLoaderClient notifications  
by Darin Adler Mar 14, 2008; 02:37am :: Rate this Message:    (use ratings to moderate[?])

> I suppose the following order of loading events for a page with a  
> single frame (please, correct me, if I'm wrong):
>
> page load started
> main document load started
> title received
> icon received
> * main document load finished
> ** resource load started
> resource load finished
> page load finished
...[show rest of quote]

The the FrameLoaderClient functions about the frame (not the ones that  
take DocumentLoader*) are what you want. They are all about this  
cycle. dispatchDidStartProvisionalLoad is the one that goes first, and  
then there are quite a few others, ending with dispatchDidFinishLoad,  
dispatchDidFailLoad or dispatchDidFailProvisionalLoad.

> OK, I see. Is there any other load process other than provisional?

All loads start provisional.

>> dispatchWillSendRequest will be called repeatedly with different  
>> URLs when a server does redirection. This is normal. How it should  
>> be handled depends on what API you've devised.
>
> Is there any separate notification about redirection, or this method  
> is enough?

There is
dispatchDidReceiveServerRedirectForProvisionalLoad for loads of the  
main resource of a frame, but dispatchWillSendRequest alone is all  
that's needed for arbitrary resource loads.

> One more question: is there any method about starting loading of an  
> external resource? Is it dispatchWillSendRequest?  
> dispatchDidReceiveResponse?

assignIdentifierToInitialRequest and dispatchWillSendRequest

     -- Darin

 

"HTTP 스택은 누가 처리하나?"
from http://www.nabble.com/Complicated-Loaders-to18706606.html#a18724848
========================================================================

The sequence of FrameLoader and DocumentLoader functions is indeed complicated
and overloaded.  This is slowly being improved over time, little by little. 
And no, there is no documentation at this time.

I'm not sure of the exact motivation for your question, but you did end on
a very specific note so this might be of use.  The question of "how WebKit is
invoking the HTTP stack" is much simpler - the ResourceRequest, ResourceHandle,
and ResourceResponse classes are all fairly encapsulated and represent
HTTP connections.

~Brady

UML 하면 떠오르는 다이어그램이 무엇일까?
대부분의 사람들이 Class Diagram을 UML의 대표 다이어그램으로 떠올린다. 그래서 UML을 도구로 S/W를 설계할 때 Class Diagram을 먼저 그리려고 애쓰곤 한다. 그런데, Class Diagram은 UML의 모든 다이어그램들 중에서 abstraction degree (추상화 정도)가 가장 높은 다이어그램이다. 순서로 따지자면 S/W 설계시에 가장 마지막에 그려야 할 다이어그램이다.

웹킷을 가지고 작업하면서 WebKit 코어를 헤집어보게 됐다. 분석한 결과를 블로그에 꾸준이 올리려고 한다. 그러기에 앞서 분석을 설명하는 "언어"에 대해 일러두려 한다. UML은 소프트웨어 형상에 관한 자신의 생각을 표현하는 "언어"다. 클래스 다이어그램을 그리는 많은 기법들이 존재하는데, 일러두려고 하는 것은 클래스와 클래스 사이의 association (연관관계) 표기에 관한 것이다.


앞으로 블로그에 올리는 클래스 다이어그램에서는 클래스와 클래스 사이의 관계를 가능한 association-line과 role-name 만으로 표현하려고 한다. 하얀 다이아몬드와 검은 다이아몬드 같은 예쁜 기호는 가능한 사용하지 않으려고 한다. 사용하는 어휘가 많아질수록 오해의 여지가 높아지기 때문이다. 위의 그림에서 표기한 ClassA와 ClassB 사이의 관계를 문장으로 옮기면 "ClassA is role-A of ClassB", "ClassB is role-B of ClassA"와 같다. 이와 같은 표기법은 당연(?)하게도 내 생각이 아니다 (분하다...). 훌륭한 선배 개발자의 경험에서 우러난 가이드이다 (클래스 다이어그램 그리는 법에 관한 책을 통해 배운 방법이다. 그 책의 저자는 임베디드 분야에서 무척 많은 경험을 쌓은 훌륭한 S/W 엔지니어였다).