중소기업정보기술융합학회논문지제 3 권제 1 호 pp. 1-6, 2013 ACME 를이용한멀티플랫폼지원아키텍처표현 박재진 1, 고재철 1, 홍장의 1* 1 충북대학교컴퓨터과학과 Architectural Representation to Support Multi-Platform Applications Using ACME Jae-Jin Park 1, Jae-Chul Ko 1, Jang-eui Hong 1* 1 Department of Computer Science, Chungbuk University 요약소프트웨어품질이중요시되고있는최근소프트웨어아키텍처에대한연구는활발하게진행되고있다. 또한스마트폰의단말플랫폼의다양화로인하여, 다양한플랫폼에탑재하는서비스를제공하기위해어플리케이션의개발에대한노력이증가되었다. 그러나이러한다양한플랫폼지원에대한노력을감소시키기위하여다양한솔루션들이제시되었고, 이중의대표적인것이 FireMonkey 프레임워크이다. 본연구에서는 FireMonkey 프레임워크의아키텍처를 ACME 로표현하여, 소프트웨어개발자가다양한플랫폼을대상으로어떻게어플리케이션을개발해야하는지에대한가이드라인을제공할수있도록하였다. 이를통해소프트웨어아키텍처가멀티플랫폼을지원하기위하여어떠한관점을고려해야하는지알수있게하였다. Abstract As the important of software quality has being emphasized, the studies on software architecture also have being performed actively. On the other hand, due to the diversification of Smartphone platforms, the effort was increased to develop the application for supporting those multiple platforms. However several solutions are suggested to reduce the effort, and a representative solution is FireMonkey framework. In this paper, we represent the FireMonkey framework using ACME which is a language to describe software architecture. Such representation can provide the guideline to develop the application for the multiple platforms. Also it supports the information of that which perspectives are critical to develop such applications. Key Words : ACME, Multi platform, Software Architecture Perspective 1. 서론 최근복잡하고다양한소프트웨어시스템을개발하는데있어높은수준의추상화를나타내는소프트웨어아키텍처는소프트웨어개발에참여하는사람들의의사소통과설계결정에중요한정보를제공하고있다 [1]. 또한소프트웨어시스템에요구되는품질은그시스템의소프 트웨어아키텍처에의해결정되기때문에아키텍처의중요성은날로증가하고있다 [2]. 오늘날스마트폰의보급과더불어다양한플랫폼을대상으로어플리케이션을개발해야하는경우가많아졌다 [3]. 이는소프트웨어개발도구가특정플랫폼에한정적이지않은멀티플랫폼을대상으로할수있어야한다 이논문은 2013 년도정부 ( 교육부 ) 의재원으로한국연구재단기초연구사업지원을받아수행된것임 (2011-0010396). Received 2013-3-18 Revised 2013-3-28 Accepted 2013-4-10 * Corresponding author : Jang-Eui Hong (jehong@chungbuk.ac.kr) 1
중소기업정보기술융합학회논문지제 3 권제 1 호 는말과같다. 멀티플랫폼을지원하는대표적인프레임워크는 FireMonkey 이다 [4]. FireMonkey는 Native Code 를변경없이그대로사용할수있는편리함이제공하기위해제안된프레임워크이다. 그림 1은 FireMonkey 의특징을나타내고있다. 그림 1을보면 FireMonkey 프레임워크가응용개발을 C++ 나델파이언어를그대로사용할수있으며, Windows, MAC, ios, Android 등의모든플랫폼을지원할수있음을보여준다. 2.1 소프트웨어아키텍처소프트웨어아키텍처는소프트웨어개발에참여하는사람들간의의사소통을원활하게지원하고시스템설계결정에대한합리적인판단을지원하는높은수준의추상화모델이다 [6]. 또한시스템의구성요소와구성요소들사이의연결관계, 시스템의설계와진화를통제하는원칙과가이드라인등으로구성되어있다 [7]. 소프트웨어아키텍처를기술하는기법은비주얼한모델로나타내는방법과텍스트형태의서술방식으로모두표현가능하다. Fig. 1. FireMonkey Framework 본논문에서는 FireMonkey 프레임워크를대상으로멀티플랫폼아키텍처를표현한다. 멀티플랫폼아키텍처를표현하기위하여 ADL(Architecture Description Language) 중하나인 Acme[5] 를사용한다. Acme를이용한 FireMonkey의표현은해당프레임워크의소프트웨어아키텍처를복원하는것이며, 이러한아키텍처의개발을통해멀티플랫폼을지원하는소프트웨어가지녀야할속성은무엇인가를확인할수있도록한다. 본논문의구성은다음과같다. 2장에서는관련된연구들을살펴보고 3장에서는 Acme 의구성요소를알아본다. 4장은 Acme 로 FireMonkey 아키텍처를표현하고 5 장은멀티플랫폼지원방안을소개한다. 마지막으로 6장은결론및향후연구로써멀티플랫폼을대상으로소프트웨어를개발할때고려해야할요소들과추후연구할사항에대해기술한다. 2. 관련연구본논문은 FireMonkey 아키텍처를 Acme로표현하고자한다. 이를위해소프트웨어아키텍처를먼저이해하고, Acme 에대한기존연구를살펴본다. 2.2 Acme 시스템의구조를표현하기위해 UML과같은언어들을사용할수있지만, 복잡하고큰시스템을표현하기에는한계가존재한다. 아키텍처를보다정확하고명확하게설계및분석을위해서는 ADL(Architecture Description Language) 를사용해야한다. ADL 중하나인 ACME 는다수의 ADL을활용할수있도록서로다른 ADL로표현된아키텍처들을상호변환과공유할수있도록지원하는언어이다 [8]. ACME에서는구조, 성질, 제약사항, 타입과스타일의네가지를정의하고있다 [9]. 각각의정의에대해간략히살펴보면다음과같다. 구조는컴포넌트, 커넥터, 시스템, 포트역할, 표현, 표현맵을정의한다. 부가적인정보를표현하는성질은모든디자인요소가가질수있는정의로, 메시지요청이나소스코드의위치, 상호작용프로토콜등을정의할수있다. 또한제약사항은모든디자인요소가정의할수있는부분으로미리정의된 predicate함수를이용한다 [10]. 마지막으로스타일은디자인요소타입의집합으로디자인전문지식의패키징, 분석및코드생성도구, 아키텍처표준적합성검증등에이용된다 [5]. 3. ACME 구성요소 ACME로 FireMonkey 아키텍처를표현하기위해간단하게 ACME 의구성요소에대해설명한다. ACME 는아키텍처를명세하기위해크게 5개의요소로이루어져있고그림 2와같이아키텍처를표현할수있다. 컴포넌트 (Component) 는시스템의핵심적인연산요소와데이터를표현할수있다. 커넥터 (Connector) 는컴 2
ACME 를이용한멀티플랫폼지원아키텍처표현 Fig. 2. Elements of an Acme Description 포넌트사이의관계를표현해주고시스템 (System) 은컴포넌트와커넥터의환경을표현한다. 특성 (Property) 은컴포넌트에모두표기할수없는정보들의표현을지원한다. 표현맵 (RepMap) 은해당컴포넌트가시스템의외부에서어떻게사용되는지표현할수있다. 았다. Acme 로표현된 FireMonkey 아키텍처는그림 3과같다. 그림 3을보면, 7개의컴포넌트와다수의 Rep-Map 및관계가존재하는것을알수있다. ACME 를이용하여표현된 FireMonkey 프레임워크의아키텍처에대하여구체적으로살펴보겠다. 그림 4는 application 컴포넌트로써어플리케이션의시작, 종료, 그리고진행을관리할수있다. control 컴포넌트는그림 5와같이구성되며어플리케이션화면에사용되는 UI 컴포넌트들을가지고있다. 해당내용이너무방대하기때문에본논문에서는세부사항을표현하지않고, 추상화하여나타내었다. Component application = { Ports { run; terminate; Fig. 4. application component 4. FireMonkey 아키텍처 기존의 FireMonkey 프레임워크의소스코드를바탕으로분석한소프트웨어아키텍처를 Acme 로표현해보 Component control = { Ports { input_event_proc, draw_text, hide_app Fig. 5. control component Fig. 3. FireMonkey Architecture 3
중소기업정보기술융합학회논문지제 3 권제 1 호 form 컴포넌트는그림 6과같이구성되며어플리케이션의출력화면을담당하는특징이있다. Component form = { Ports { create; destroy; input_event paint Fig. 6. form component Component context = { Ports { render; Representation context_windows_xp = { System = context_windows_xp_system = { Component dx9 = { Ports { render; Representation context_windows_vista = { System = context_windows_vista_system = { Component dx10 = { Ports { render; Representation context_mac = { System = context_mac_system = { Component opengl = { Ports { render; Bindings {dx9.render to context.render Bindings {dx10.render to context.render Bindings {opengl.render to context.render Fig. 7. context component context 컴포넌트는그림 7과같이구성된다. context 컴포넌트는 3D 그래픽을담당하는컴포넌트로써, 다양한 3D 표현을지원하고있다. canvas 컴포넌트는그림 8과같이구성된다. 해당컴포넌트는 context 컴포넌트와비슷하게 2D 그래픽을담당하는컴포넌트로써, 다양한 2D 표현을지원해준다. platform 컴포넌트는그림 9와같이구성된다. platform 컴포넌트는플랫폼에종속적인기능을다루고있는여러컴포넌트들을가지고있다. 또한 Control, Form 컴포넌트들이플랫폼에종속적인기능을사용하기위해서는이컴포넌트를통해다른컴포넌트들에접근해야한다. Component canvas = { Ports { paint; Representation canvas_windows_xp = { System = canvas_windows_xp_system = { Component gdiplus = { Ports { paint; Representation canvas_windows_vista = { System = canvas_windows_vista_system = { Component d2d = { Ports { paint; Representation canvas_mac = { System = canvas_mac_system = { Component quartz = { Ports { paint; Bindings {gdiplus.paint to canvas.paint Bindings {d2d.paint to canvas.paint Bindings {quartz.paint to canvas.paint Fig. 8. canvas component 그림 10의 text_layout 컴포넌트는전반적으로표현되는모든텍스트들을관리하며대표적로텍스트의크기측정, 포맷및출력을담당한다. Component platform = { Representation platform_windows = { System platform_windows_system = { Component application_service = { Ports { run; terminate; handle_message; Component windows_service = { Ports { create; destroy; ; Representation platform_mac = { System platform_mac_system = { Component application_service = { Ports { run; terminate; handle_message; 4
ACME 를이용한멀티플랫폼지원아키텍처표현 Component windows_service = { Ports { create; destroy; Component hide_app_service = { Ports { hide; Ports {input; application_intf; window_intf; hide_app;; Bindings { application_service.run to application_intf; application_service.terminate to application_intf; application_service.handle_message to input; window_service.create to window_intf; window_service.destory to window_intf; hide_app_service.hide to hide_app; Fig. 9. platform component Component text_layout { Ports { render; Representation text_layout_windows_xp = { System = text_layout_windows_xp_system = { Component gdiplus = { Ports { render; Representation text_layout_windows_vista = { System = text_layout_windows_vista_system = { Component dwrite = { Ports { render; Representation text_layout_mac = { System = text_layout_mac_system = { Component core_text = { Ports { render; Bindings {gdiplus.render to text_layout.render Bindings {dwrite.render to text_layout.render Bindings {core_text.render to text_layout.render Fig. 10. text_layout component 5. 멀티플랫폼지원방안소프트웨어개발시멀티플랫폼을지원하기위해서는비즈니스로직의중요성보다는플랫폼과의인터페이스나전체적인소프트웨어의형상이저중요하게인식되고있다. 또한플랫폼별로표현되는방식과구동원리가다르기때문에 UI가중요한요소중의하나가될수있다. 따라서멀티플랫폼을지원하는소프트웨어개발툴은다양한 UI를플랫폼별로관리하여다양한플랫폼에탑재가능한소프트웨어를개발할수있는아키텍처가필요로하게된다. FireMonkey 아키텍처를 Acme 를통해표현한결과멀티플랫폼을지원하기위한아키텍처는어떻게표현돼야하는지알수있었다. 비즈니스로직의경우개발자가선호하는프로그래밍언어를사용하여개발하면되기때문에큰문제가존재하지않지만, 플랫폼의독립적인특성을극복하기위해서는다양한플랫폼을대상으로 UI 관련데이터들을끌어와사용할있도록지원해야한다. 그림 2의 platform 컴포넌트는이러한필요성에따라도출된것이다. 또한부가적으로 2D와 3D 그래픽, 텍스트를처리하기위해그림 2에서사용된 canvas 컴포넌트, context 컴포넌트, text_layout 컴포넌트와같은컴포넌트들이필요로하게된다. 6. 결론본연구에서는멀티플랫폼의소프트웨어개발을지원하는 FireMonkey 프레임워크를 Acme를통해아키텍처로표현해보았다. 총 7개의컴포넌트가존재했고, 각각의컴포넌트는멀티플랫폼을지원하기위한관계를가지고있었으며, 플랫폼종속적인내용은 platform 컴포넌트를통해일괄적으로처리해주는것을확인할수있었다. 현재데스크톱플랫폼기준으로 Windows 계열과 Mac만을제공하고있지만추후모바일플랫폼을지원하기위해 Android 와 ios의종속적인정보들을 platform 컴포넌트를기준으로추가하여기능을확장하고자한다. FireMonkey 아키텍처는 Acme로표현되었기때문에다른 ADL로변경이용이한점을활용하여다양한분석을실시할수있다. 5
중소기업정보기술융합학회논문지제 3 권제 1 호 REFERENCES [1] P. Clements, R. Kazman, M, Klein, Evaluating Software Architecture: Methods and Case Studies, Addision-Wesley, 2002. [2] J. Bosch, Design and Use of Software Architecture, Addison-Wesley, 2000. [3] Wojtczyk, Martin, and Alois Knoll, A cross platform development workflow for C/C++ applications, Proceeding on Software Engineering Advances, 2008. [4] Embarcadero Technologies, FireMonkey, http://www.embarcadero-inf o.com/firemonkey, 2012. [5] D. Garlan, R. Monroe, D. Wile, Acme: an architecture description interchange language, Proceeding on conference of the Centre for Advanced Studies on Collaborative research, 1997. [6] A. Dragomir, H, Lichter, Model-based Software Architecture Evloution and Evaluation, Proceeding on conference of the Asia-Pacific Software Engineering, 2012. [7] X. Cui, Y. Sun, S. Xiao, H. Mei, Architecture Design for the Large-Sacle Software-Intensive Systems: A Decision-Oriented Approach and the Experience, Proceeding on conference of the International Conference on Engineering of Complex Computer Systems, 2009. [8] F. Buschmann, K. Henney, Douglas C. Schmidt, Pattern-oriented Software Architecture: On Patterns and Pattern Languages, John Wiley and Sons, 2007. [9] M. Rong, C. Liu, G. Zhang, Modeling Aspect- oriented Software Architecture Based on ACME, Proceeding on conference of the International Conference on Computer Science & Education, 2011. [10] Z. He, K. Ben, Z. Zhang, Software Architectural Reflection Mechanism for Runtime Adaptation, Proceeding on conference of the International Conference for Young Computer Scientists, 2008. 저자소개박재진 (Jae-Jin Park) [ 정회원 ] 2012년 8월 : 충북대학교컴퓨터공학부 ( 학사 ) 2012년 9월 ~ 현재 : 충북대학교컴퓨터과학과 ( 석사과정 ) < 관심분야 > : 소프트웨어품질, 코드리팩토링, 소프트웨어아키텍처, 객체지향모델링고재철 (Jae-Cheol Ko) [ 정회원 ] 1998년 2월 : 충북대학교컴퓨터공학부 ( 학사 ) 2010년 2월 ~ 현재 : 충북대학교컴퓨터과학과 ( 석사과정 ) < 관심분야 > : 소프트웨어아키텍처, 소프트웨어품질, 객체지향프로그래밍홍장의 (Jang-Eui Hong) [ 정회원 ] 2001년 2월 : KAIST 전산학과 ( 공학박사 ) 2001년 2월 ~ 2002년 9월 : 국방과학연구소선임연구원 2002년 10월 ~ 2004년 8월 : ( 주 ) 솔루션링크기술연구소장 2004년 9월 ~ 현재 : 충북대학교소프트웨어학과교수 < 관심분야 > : 소프트웨어품질공학, 모델기반검증분석, 소프트웨어아키텍처, 소프트웨어프로세스개선 6