KR20220132457A - 소스 컴파일러를 구비한 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법 - Google Patents

Abstract

사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법이 개시된다. 본 발명의 일 실시예에 따른 사용자 인터페이스 플랫폼 개발 시스템은, 위지위그 방식의 화면 파일 개발 환경을 제공하여 사용자 인터페이스 플랫폼을 구조화된 컴포넌트로 구성한 화면 파일 소스를 생성하는 개발도구; 상기 개발도구로 화면 파일 개발을 위한 리소스를 제공하고, 개발된 화면 파일 소스가 등록되는 서버; 및 상기 서버에 요청하여 응답받은 상기 화면 파일 소스를 로딩하는 클라이언트 엔진을 포함하고 브라우저 창에서 실행시켜 연계된 디바이스에 상응하는 상기 사용자 인터페이스 플랫폼을 제공하는 클라이언트를 포함하되, 상기 개발도구는 상기 화면 파일 소스를 자바스크립트로 번들링 및 트랜스파일하는 화면 소스 변환 모듈을 포함할 수 있다.

Description

소스 컴파일러를 구비한 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법{User interface platform developing system and method with source complier}

본 발명은 소스 컴파일러를 구비한 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법에 관한 것이다.

디지털 트랜스포메이션(Digital Transformation)은 디지털 기술을 사회 전반에 적용하여 전통적인 사회 구조를 혁신시키는 것이다.

일반적으로 기업에서 사물인터넷(IoT), 클라우드 컴퓨팅, 인공지능(AI), 빅데이터 솔루션 등 정보통신기술(ICT)을 플랫폼으로 구축·활용하여 기존 전통적인 운영 방식과 서비스 등을 혁신하는 것을 의미한다.

모든 비즈니스 프로세스를 디지털화해 혁신하기 위해서는 다음과 같은 2가지 필수요건이 있다.

(1) 시장의 요구에 신속한 대응 및 적극적인 신기술 활용

(2) 다양한 디바이스(Mobile, Wearable, IoT)를 활용한 비즈니스 모델 혁신

신기술(AI, IoT, Cloud, BigData, AR/VR, Mobile)을 적용하고, 오픈소스 생태계를 활용하며, 신속한 개발(Low Coding)에 대응하기 위해서는 웹, 모바일, 웨어러블 디바이스, 앱 개발 등 모든 개발 활동을 통합할 수 있는 다중경험 개발 플랫폼(MXDP, Multiexperience Development Platforms)이 요구된다.

한국공개특허 제10-2018-0058561호 (2018.06.01. 공개) - 하이브리드 앱 개발 플랫폼 및 이를 이용한 개발방법

본 발명은 원 소스 멀티 유즈(OSMU, One Source Multi Use)로 멀티 브라우저, 멀티 디바이스, 멀티 OS를 지원하고, 다양하고 고도화된 컴포넌트를 탑재하고 있으며, 통합 개발 환경을 제공하고, 외부 라이브러리와 유연한 연계가 가능하며, 다양한 웹 환경과 디바이스에 최적의 화면을 제공할 수 있는 웹 표준 기술 기반의 소스 컴파일러를 구비한 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법을 제공하기 위한 것이다.

본 발명은 개발된 화면 파일을 브라우저에 최적화시켜 파일 크기를 감소시키고 로딩 시간을 감소시키며 메모리 사용량을 감소시킨 소스 컴파일러를 구비한 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법을 제공하기 위한 것이다.

본 발명의 이외의 목적들은 하기의 설명을 통해 쉽게 이해될 수 있을 것이다.

본 발명의 일 측면에 따르면, 사용자 인터페이스 플랫폼 개발 시스템으로서, 위지위그 방식의 화면 파일 개발 환경을 제공하여 사용자 인터페이스 플랫폼을 구조화된 컴포넌트로 구성한 화면 파일 소스를 생성하는 개발도구; 상기 개발도구로 화면 파일 개발을 위한 리소스를 제공하고, 개발된 화면 파일 소스가 등록되는 서버; 및 상기 서버에 요청하여 응답받은 상기 화면 파일 소스를 로딩하는 클라이언트 엔진을 포함하고 브라우저 창에서 실행시켜 연계된 디바이스에 상응하는 상기 사용자 인터페이스 플랫폼을 제공하는 클라이언트를 포함하되, 상기 개발도구는 상기 화면 파일 소스를 자바스크립트로 번들링 및 트랜스파일하는 화면 소스 변환 모듈을 포함하는 것을 특징으로 하는 사용자 인터페이스 플랫폼 개발 시스템이 제공된다.

상기 화면 소스 변환 모듈은 상기 화면 파일 소스인 XML과 동일한 정보를 가지고 있는 JSON이 포함된 JS 파일을 생성하여 상기 클라이언트에서 상기 JSON을 파싱하면서 화면을 그리도록 변경하는 작업을 수행할 수 있다.

상기 화면 소스 변환 모듈은 상기 화면 파일 소스를 모니터링하는 모니터부와; 상기 화면 파일 소스를 자바스크립트로 컴파일하는 컴파일러부를 포함할 수 있다.

상기 컴파일러부는, XML 파일을 JS 파일로 변환하는 XML-JS 컨버터와; 추상 구문 트리를 생성하는 트리 생성기와; 생성된 추상 구문 트리를 검증하는 검증부와; 검증에 성공하면 상기 JS 파일을 최적화하는 최적화부와; 최적화된 상기 JS 파일에 대해 코드 난독화를 적용하는 난독화부와; 난독화된 결과에 대해 압축을 통해 최소화시켜 자바스크립트로 출력하는 최소화부를 포함할 수 있다.

상기 컴포넌트에는 페이지(Page) 컴포넌트, 사용자 정의 컴포넌트(UDC), 프로젝트 UDC, MSA UDC 중 하나 이상이 포함될 수 있다.

상기 클라이언트는 마이크로 서비스 아키텍처에 대응하기 위한 MSA 메시지 브로커 및 교차 MSA 자원 공유 기능의 마이크로 프론트엔드 아키텍처를 가질 수 있다.

상기 개발도구는 상기 화면 파일을 단일 페이지 애플리케이션 타입으로 구성되게 할 수 있다.

전술한 것 외의 다른 측면, 특징, 이점이 이하의 도면, 특허청구범위 및 발명의 상세한 설명으로부터 명확해질 것이다.

본 발명의 실시예에 따르면, 원 소스 멀티 유즈로 멀티 브라우저, 멀티 디바이스, 멀티 OS를 지원하고, 다양하고 고도화된 컴포넌트를 탑재하고 있으며, 통합 개발 환경을 제공하고, 외부 라이브러리와 유연한 연계가 가능하며, 다양한 웹 환경과 디바이스에 최적의 화면을 제공할 수 있는 효과가 있다.

또한, 개발된 화면 파일을 브라우저에 최적화시켜 파일 크기를 감소시키고 로딩 시간을 감소시키며 메모리 사용량을 감소시킨 효과도 있다.

도 1은 본 발명의 일 실시예에 따른 사용자 인터페이스 플랫폼 개발 시스템의 아키텍처를 나타낸 도면,
도 2는 본 발명의 일 실시예에 따른 시스템에서 생성되는 XML 코드와 일반적인 HTML 코드의 구조 비교도,
도 3은 메인 화면이 wframe을 중첩 포함하는 경우의 스크립트 수행 순서를 나타낸 도면,
도 4는 본 발명의 일 실시예에 따른 사용자 인터페이스 플랫폼 개발 방법의 순서도,
도 5는 페이지의 컴포넌트화를 설명하기 위한 예시도,
도 6은 다양한 서버 구성 방식을 나타낸 도면,
도 7은 교차 MSA 자원 공유 기능과 MSA 메시지 브로커 기능에 대한 설명을 위한 도면,
도 8은 wframe이 구성된 경우 교차 MSA 공유 구조의 동작을 나타낸 도면,
도 9는 메시지 브로커를 이용한 페이지 컴포넌트 간 데이터 교환 방식을 나타낸 도면,
도 10은 페이지를 이용한 단일 페이지로의 구조화 예시도,
도 11은 전통적인 웹 애플리케이션과 단일 페이지 웹 애플리케이션의 비교도,
도 12는 단일 페이지 애플리케이션의 다양한 구현 예,
도 13은 기존 웹 개발 방식(Iframe) 대비 단일 페이지 웹 애플리케이션 방식의 화면 표시 과정을 나타낸 도면,
도 14는 W-Pack 실행 구조를 나타낸 도면,
도 15는 화면 소스 변환 모듈의 상세 구성도,
도 16은 레이아웃 매니저에서의 해상도 설정 화면과 그리드 레이아웃 매니저의 예시 화면,
도 17은 레이아웃 매니저의 각 디바이스 탭의 예시도,
도 18은 레이아웃 매니저에서 수행되는 화면 개발 방법의 순서도,
도 19는 디자인 시스템의 구성도,
도 20은 스니핏 가이드 및 템플릿 활용 예시도.

본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세하게 설명하고자 한다. 그러나 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.

제1, 제2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다.

본 명세서에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 명세서에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

또한, 각 도면을 참조하여 설명하는 실시예의 구성 요소가 해당 실시예에만 제한적으로 적용되는 것은 아니며, 본 발명의 기술적 사상이 유지되는 범위 내에서 다른 실시예에 포함되도록 구현될 수 있으며, 또한 별도의 설명이 생략될지라도 복수의 실시예가 통합된 하나의 실시예로 다시 구현될 수도 있음은 당연하다.

또한, 첨부 도면을 참조하여 설명함에 있어, 도면 부호에 관계없이 동일한 구성 요소는 동일하거나 관련된 참조부호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다. 본 발명을 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다.

또한, 명세서에 기재된 "…부", "…유닛", "…모듈", "…기" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어나 소프트웨어 또는 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다.

도 1은 본 발명의 일 실시예에 따른 사용자 인터페이스 플랫폼 개발 시스템의 아키텍처를 나타낸 도면이고, 도 2는 본 발명의 일 실시예에 따른 시스템에서 생성되는 XML 코드와 일반적인 HTML 코드의 구조 비교도이며, 도 3은 메인 화면이 wframe을 중첩 포함하는 경우의 스크립트 수행 순서를 나타낸 도면이고, 도 4는 본 발명의 일 실시예에 따른 사용자 인터페이스 플랫폼 개발 방법의 순서도이며, 도 5는 페이지의 컴포넌트화를 설명하기 위한 예시도이다.

본 발명의 일 실시예에 따른 사용자 인터페이스 플랫폼 개발 시스템(100)은 클라이언트의 다양한 스마트 기기 및 웹 브라우저 환경을 지원하며, 서버 환경은 J2EE(Java 2 Enterprise Edition)를 지원하는 임의의 웹 애플리케이션 서버(WAS, Web Application Server), 임의의 프레임워크(Framework), 임의의 OS 등에 대해서도 플랫폼 독립성을 지원한다.

이하에서는 본 실시예에 따른 사용자 인터페이스 플랫폼 개발 소프트웨어를 본 출원인이 개발하여 판매하는 웹스퀘어(WebSquare)라고 칭하기로 한다.

사용자 인터페이스 플랫폼 개발 시스템(100)은 사용자가 사용하는 클라이언트(130), 개발자가 사용하는 개발도구(120)('스튜디오'라고 칭하기도 함), 클라이언트(130)의 요청에 응답하고 개발도구(120)에 웹스퀘어 화면 파일 개발이 가능하게 하는 서버(110)를 포함한다.

개발도구(120)는 개발자가 업무 시스템에 관한 웹스퀘어 화면 파일을 개발할 수 있는 환경을 제공한다. 클라이언트(130)에는 클라이언트 엔진이 설치되며, 클라이언트 엔진은 웹스퀘어 화면 파일을 브라우저에 표시한다.

클라이언트(130)는 자바스크립트로 만들어지며, AJAX 아키텍처를 기반으로 한다. 그리드, 차트 등의 UI 컴포넌트를 동적으로 실행되도록 지원한다. 통신 및 기타 UI와 관련된 유틸리티를 포함할 수 있다.

클라이언트(130)에 포함되는 클라이언트 엔진은 단일 페이지 애플리케이션(SPA, Single Page Application) 구조를 가질 수 있다.

클라이언트 엔진에는 UDC, 페이지 컴포넌트, 프로젝트 컴포넌트, MSA 컴포넌트, 그리드 레이아웃, UI 컴포넌트, MSA 메시지 허브, 교차 MSA 자원 공유, 데이터 컬렉션, 모듈 로더, 프라미스 워크플로우, 로깅/디버깅 등의 모듈이 포함될 수 있다.

컴포넌트는 기본 파일로서, 페이지(Page), 프로젝트 UDC, MSA UDC, UDC, TTC를 개발하는데 사용할 수 있다. 업무시스템의 모든 화면을 구조화된 컴포넌트로 구성해 어디서나 재사용 가능한 효율적인 운영을 지원할 수 있다.

웹스퀘어 페이지 컴포넌트는 컴포넌트 형태로 사용되는 기본 화면 파일이다. 새롭게 추가된 프로젝트 UDC, MSA UDC, UDC, TTC를 지원한다. 확장자는 xml을 사용한다.

UDC는 User Defined Component의 약자로, 스튜디오의 팔레트에 등록된 사용자 정의 컴포넌트이다.

TTC는 Trust Third-part Component의 약자로, 외부 솔루션을 웹스퀘어 페이지 컴포넌트로 사용할 수 있도록 지원한다.

프로젝트 UDC(Project UDC)는 프로젝트 전체에서 사용되는 공통 기능이 포함된 공통 기능 파일이다. 웹스퀘어 환경 설정에 정의되고, 웹스퀘어 엔진 로딩 시 자동으로 로딩된다.

MSA UDC는 마이크로 프론트엔드(Micro Frontend)를 지원하기 위한 공통 기능이 포함된 공통 기능 파일이다. 웹스퀘어 환경 설정에 정의되고, 관련된 웹스퀘어 엔진 로딩 시 마이크로서비스가 동작하는 서버에서 리소스를 로딩한다.

컴포넌트는 크게 내장 컴포넌트, SP4 UDC 컴포넌트, 웹스퀘어 컴포넌트를 포함한다.

내장 컴포넌트로는 그리드뷰(gridView)가 있으며, 그리드(Grid), 테이블(Table), 콤보(Combo), 입력(Input), 탭컨트롤(tabControl) 등이 포함된다. 웹스퀘어에서 기본 제공되는 컴포넌트이다.

SP4 UDC 컴포넌트로는 SP4 UDC와 SPC TTC가 있다. 사용자 정의 컴포넌트 표준으로, 개발자가 직접 추가할 수 있는 UDC이다. 그리고 컴포넌트 제품을 솔루션 제작사와 협업을 통하여 추가한 TTC이다.

웹스퀘어 컴포넌트로는 UDC, TTC, 프로젝트 UDC, MSA UDC가 있다. UDC와 TTC는 개발자가 개발한 UI 요소(Page)의 재사용성을 높이기 위해 도입된 Page 기반 사용자 정의 컴포넌트이다. 기존 Page(XML)를 단순화/구조화해서 모든 Page를 컴포넌트로 개발할 수 있다. Page 간 결합도를 낮춰 모듈화할 수 있다.

프로젝트 UDC는 전역 UDC로서, 모든 화면에서 호출할 수 있는 컴포넌트이다. 공통업무 UDC 개발에 사용해 재사용을 극대화할 수 있다.

MSA UDC는 마이크로 프론트엔드 구현을 위한 UDC로서, MSA를 적용하고 크로스도메인 처리가 가능하게 한다.

데이터 컬렉션(Data Collection)은 테이블 형태의 직관적인 데이터 관리와 일관성 있고 편리한 데이터 관리를 위한 모듈이다. 그리드 컴포넌트와 유사한 API를 제공하여 개발자가 손쉽게 그리드 형태로 조작할 수 있다.

프라미스 워크플로우(Promise Workflow)는 HTML5로 개발시 복잡하고 어려웠떤 비동기 처리 프로그래밍을 직관적인 GUI 방식을 통해 단순하고 손쉽게 프로그래밍할 수 있도록 한다.

서버(110)는 애플리케이션 리소스(이미지, HTML, JS, CSS, XML 등)를 보관한다. 서버 아키텍처는 어댑터, 파일 업로드/다운로드, 엑셀 I/E(import/export), 라이선스 관리 등을 위한 유틸리티를 포함한다. 또한, 프레임워크 인터페이스를 위한 모듈로서, 비즈니스 공통, 비즈니스 모듈, DBIO, 시스템 공통 모듈을 포함할 수 있다.

서버(110)는 OS, DBMS, WAS에 독립적으로 구현되어, 플랫폼 독립성을 지원할 수 있다.

개발도구(120)는 위지위그(WYSIWYG) 방식의 통합 개발 환경을 제공하며, 개발자에게 쉬운 개발을 지원해 줄 수 있다. 개발자는 개발도구(120)를 통해 컴포넌트 그리기, 스크립트 추가, 화면 확인, 디버깅 등을 한번에 수행할 수 있다.

또한, 개발도구(120)는 SVN/CVS/Git 등으로 형상관리(SCM, Software Configuration Management)를 수행할 수 있다. 상용 형상관리 솔루션은 벤더에서 제공하는 벤더 플러그인으로 연동할 수 있다.

개발도구(120)에는 W-Pack(소스 컴파일러), 디자인 시스템, 스니핏(Snippet), Git/SVN, MSA 메시지 허브 에디터, WRM 컴포넌트, 그리드 레이아웃 에디터, 레이아웃 매니저, 페이지 컴포넌트 에디터, 디자인 에디터, 코드 에디터, 메시지 인터페이스 등의 모듈이 포함될 수 있다. 또한, 재사용이 가능한 공통업무 UDC를 지원한다.

다양한 디바이스(PC, 태블릿, 스마트폰, 스마트TV 등)에 설치된 클라이언트(130)에서 서버(110)에 요청(HTTP REST API(JSON/XML))할 경우, 웹 서버(110)에서 리소스를 찾고 웹 애플리케이션 서버(110)와 데이터를 주고 받으며, 클라이언트(130)에 요청에 상응하는 응답(HTTP REST API(JSON/XML))을 전송할 수 있다. 웹 서버(110)와 개발도구(120) 사이의 연결관계에서 JS 화면 소스가 배포될 수 있다.

본 실시예에서는 마이크로 서비스 아키텍처(MSA)에 대응하기 위해 MSA 메시지 브로커, 교차 MSA 자원 공유(Cross MSA Resource Sharing) 기능의 마이크로 프론트엔드 아키텍처를 가질 수 있다.

또한, 단일 페이지 애플리케이션(SPA), 엔진 최적화(Engine Optimizer), 자원 최적화(W-Pack), 대용량 데이터 처리 지원 등을 통해 성능 향상을 도모할 수 있다.

오픈 아키텍처를 통해 임의의 웹 애플리케이션 서버, 임의의 프레임워크, 임의의 OS를 지원하고, 오픈소스 재활용을 통한 개발 생산성 향상을 지원할 수 있다. 또한, 다양한 오픈/상용 라이브러리의 손쉬운 연계를 지원하고, 다양한 보안솔루션 연계도 지원할 수 있다.

웹스퀘어로 생성되는 XML 코드와 일반적인 HTML 코드 구조가 도 2의 (a)와 (b)에서 비교되고 있다.

웹스퀘어 XML 코드의 구성요소는 크게 <head>와 <body>로 구분된다.

<head>에는 <xf:model>, <script>, <style> 요소가 포함된다.

<xf:model>에는 <w2:dataCollection>, <xf:workflow>, <xf:submission> 영역이 포함된다.

<w2:dataCollection>은 데이터 객체를 정의하는 영역으로, DataMap, DataList, LinkedDataList가 포함된다. 서버 통신을 위한 요청(request), 응답(response) 데이터와 화면에서 사용할 데이터를 정의한다.

<xf:workflow>는 submit, submitDone의 실행 순서가 정의된다. 여러 개의 Submission을 실행할 경우 사용한다. 실행 순서, 결과 처리 순서, 결과에 따른 이후 Submission의 실행 여부 등을 정의한다. 조회(Select) 용도의 통신에 사용할 것이 권장된다.

<xf:submission>은 서비스 호출에 필요한 submit을 정의한다. 각 submit은 고유 ID를 포함한다. 서버 통신을 위한 인터페이스로서, 용도 별로 여러 개 정의가 가능하다. 통신 방식(동기/비동기) 선택이 가능하고, 통신 전/후에 실행할 함수 정의도 가능하다. 전송할 데이터(request 혹은 ref)와 수신할 데이터(response 혹은 target)를 설정할 수 있다.

<script>는 글로벌 스크립트와 컴포넌트의 이벤트 함수를 정의하여 업무 로직을 구성할 수 있다.

<style>은 스타일을 지정한다.

<body>는 컴포넌트, 컴포넌트 속성, 화면 UI 정보를 포함한다. 화면 UI 정보로서, 컴포넌트 배치 및 구성, 각 컴포넌트의 속성에 관한 정보가 포함될 수 있다.

본 실시예에서 웹스퀘어 페이지 컴포넌트를 생성할 경우, 스크립트의 실행 순서는 외부 JS 파일 -> 로컬 스크립트 -> <initScript> -> onpageload -> <postSCript> 이다.

메인 화면이 WFrame을 중첩 포함하고 있는 경우, 스크립트 수행 순서는 도 3에 도시된 것과 같다.

소스 컴파일러인 W-Pack은 화면 소스를 자바스크립트(JavaScript)로 빌드할 수 있다. 개발도구(120)에서 개발한 화면 파일은 XML 형식으로 생성되며, W-Pack은 이를 브라우저 환경에 최적화된 자바스크립트 파일로 변환한다.

압축 및 최소화(Minify) 기능을 제공하여, 기존 XML 형식과 비교하여 파일 크기가 감소할 수 있다. 난독화(Obfuscation)를 통해 소스 코드의 보안성을 높일 수 있다. 웹 환경에 최적화된 JS 파일은 XML과 비교하여 로딩 시간이 짧고 메모리 사용량이 적어, 클라이언트 엔진은 JS 파일을 이용하여 더욱 빨리 화면을 브라우저에 그릴 수 있다.

개발도구(120)에서 작성한 화면은 XML 파일로 생성되며, W-Pack에 의해 JS 파일로 변환되며, 브라우저는 XML 파일명이 표시되지만, 화면을 표시할 때 실제로 사용하는 파일은 JS 파일이다.

화면의 브라우저 호출 순서는 다음과 같다.

(1) 브라우저에서 화면을 호출함

(2) 서버 쪽 웹스퀘어 엔진의 websquare.html 파일이 호출됨

(3) Websquare 엔진이 구동됨

(4) 화면에 해당하는 XML 파일을 URL로 호출함

(5) W-Pack에 의해 변환된 JS 파일이 로딩됨

(6) 해당 화면이 브라우저에 표시됨

본 실시예에 따른 사용자 인터페이스 플랫폼 개발 시스템(100)은 다양한 공통 개발용 리소스를 제공한다. 즉시 사용 가능한 완성도 높은 리소스로서, 썸네일 이미지 형태로 제공할 수 있다. 개발자들은 직관적으로 템플릿을 확인하고, 코딩 과정 없이 마우스 클릭 만으로 해당 리소스를 손쉽게 사용할 수 있다.

공통 개발용 리소스에는 페이지 템플릿(화면 파일 생성 시 선택 가능), 레이아웃 템플릿(화면 파일 생성 시 선택 가능), 스니핏(디자인 시스템에서 썸네일 이미지를 통해 제공) 등이 포함될 수 있다.

도 4를 참조하면, 본 시스템에서는 개발 프로세스에 따라 단계별로 위저드, 매니저, 에디터 등을 제공하고, 각 단계에 적합한 공통 리소스를 제공할 수 있다. 개발 프로세스를 준수하여 디자인 일관성을 유지할 수 있고 공통 리소스를 최대한 재사용할 수 있다.

또한, 본 실시예에서는 모듈화된 개발이 가능하다. 개발하는 화면 파일은 컴포넌트 형태로 사용할 수 있다. 특정 화면을 UDC나 프로젝트 컴포넌트로 등록하여 사용할 경우, 재사용이 가능하다. 등록한 UDC를 수정할 경우, 변경사항이 일괄 반영되어 개발 생산성과 유지보수 효율성이 뛰어나다.

본 시스템에서 개발하는 화면 파일은 컴포넌트 형태로 사용될 수 있고(페이지 컴포넌트), 기존의 페이지 파일의 모든 기능을 지원한다. 페이지를 UDC로 등록하여 공통 컴포넌트로 사용할 경우, UDC의 API에 대한 주석을 기반으로 UDC 설명 문서를 작성할 수 있으며, 스크립트 에디터에서 UDC의 API에 대한 자동 완성 기능을 사용할 수 있다.

모든 페이지는 컴포넌트로 등록 가능하며, 컴포넌트로 등록된 페이지는 간단한 클릭만으로 다른 화면 개발에서 사용할 수 있다.

도 5에는 페이지 A와 페이지 B를 컴포넌트화하여 페이지 C에 사용하는 페이지의 컴포넌트화가 도시되어 있다.

본 실시예에서 디자인 시스템은 공통 개발에 사용하는 스니핏을 포함한 디자인 관련 리소스를 썸네일 형태로 스튜디오(개발도구)에 표시할 수 있다. 개발자는 손쉽게 디자인을 확인하고, 원하는 디자인을 화면에 추가하여 사용할 수 있다.

공통 개발에 사용하는 각종 샘플 및 템플릿 등의 리소스를 쉽게 사용하고 관리할 수 있다. 리소스는 종류별로 분류되어 서로 다른 폴더에 저장되어 있으며, 개발자는 해당 폴더를 직접 관리할 수 있다. 또한, 각종 리소스를 화면 개발 과정에서 반영되어 썸네일 이미지 형태로 제공되며, 개발자는 각 개발 단계 별로 가용한 리소스를 편리하게 선택하여 이용할 수 있다.

또한, 서버 및 클라이언트 환경을 모두 스튜디오 상에서 설정할 수 있는 GUI를 제공한다. 설정 항목에 대한 지식 없이도 에디터가 제공하는 설명을 참고하여 직접 편집할 수 있다((1) client.config.xml, (2) server.config.xml).

스튜디오의 디자인 시스템은 개발자와 퍼블리셔 간의 유기적인 협업을 위한 모듈이다. 디자인 관련 리소스를 썸네일 이미지로 표시한다. 개발자는 직관적으로 디자인을 확인할 수 있고, 클릭만으로 원하는 디자인 리소스를 화면 파일에 복사할 수 있다.

개발도구의 화면에서는 위지위그 방식의 컴포넌트 디자인 공간을 제공하여, 팔레트 뷰에서 선택한 컴포넌트를 그릴 수 있다. 그리고 해당 컴포넌트의 속성, 구성, 스타일을 Property, Component, Style 뷰에서 편집할 수 있다.

컴포넌트를 그릴 때, 스태틱(Static) 모드와 앱솔루트(Absolute) 모드를 제공한다.

스태틱 모드에서는 클릭 앤 클릭 방식으로, 팔레트 뷰에서 추가할 컴포넌트를 선택하고 디자인 뷰에서 추가할 위치를 지정하고 클릭하여 그리기를 수행한다. 디자인 뷰에서 선택한 컴포넌트를 기준으로 새로운 컴포넌트의 위치가 결정된다. 컴포넌트 생성 시 지정한 위치에 따라 렌더링 순서가 결정된다.

앱솔루트 모드에서는 클릭 앤 드래그 방식으로, 팔레트 뷰에서 추가할 컴포넌트를 선택하고 디자인 뷰에서 컴포넌트를 직접 드래그하여 그리기를 수행한다. 디자인 뷰에서 드래그하여 직접 위치를 결정하고, 렌더링 순서는 컴포넌트를 그린 순서를 따라간다.

모든 컴포넌트는 id, style, css 속성을 포함한다. 개발자는 CSS 문법을 사용하여 각 컴포넌트 스타일을 확장할 수 있다.

화면 파일은 웹스퀘어가 제공하는 80여개의 기본 컴포넌트와 UDC와 같은 공통 개발 컴포넌트의 속성, 함수, 이벤트 등을 설정하고, 웹스퀘어가 제공하는 공통 디자인 리소스(페이지 템플릿, 레이아웃 템플릿, 스니핏)를 이용하여 개발도구(120)를 통해 개발할 수 있다.

단일 페이지 애플리케이션(SPA)은 신속한 페이지 전환을 위해 단일 페이지 동작을 시도하는 웹 애플리케이션이나 사이트를 의미한다. SPA를 적용한 웹 애플리케이션이나 사이트는 반복되는 HTML 코드를 다시 다운받지 않기 때문에 페이지 이동 속도가 빠르고 효율적인 자원 관리가 가능하다.

페이지 이동 속도가 향상되며, 웹스퀘어 자원(엔진파일, CSS, 이미지 파일 등) 및 이미 로딩한 외부 JS 파일을 재사용한다.

본 실시예에 따른 사용자 인터페이스 플랫폼 개발 시스템은 다중경험 UI 플랫폼으로, 다음과 같은 특징을 가진다.

마이크로 아키텍처를 이용한 아키텍처 고도화 특징을 가진다. 페이지간 직접 레퍼런스 없이 마이크로 프론트엔드를 구현하기 위한 UI 아키텍처인 MSA 메시지 브로커가 구현된다. 또한, 모든 페이지를 컴포넌트화하고, 프로젝트 UDC, 화면 모듈화를 위한 전역 컴포넌트 아키텍처와, MSA UDC, 마이크로 프론트엔드 지원 컴포넌트 아키텍처 등의 컴포넌트 아키텍처가 구현된다.

스튜디오(특히, 레이아웃 매니저, 디자인 시스템, 스크립터 에디터 등)를 이용한 개발 생산성 기능 개선 특징도 가진다. 디자인 시스템은 디자인 일관성 유지를 위한 직관적인 개발자/디자이너 협업 도구이다. 스크립터 에디터는 최신 자바스크립트 문법을 지원하고, 자동완성을 지원하며(IntelliSense), VS Code 기본 기능을 제공할 수 있다.

SPA 구조 고도화로 로딩 속도를 최적화하고, W-Pack, 화면 브라우저 최적화를 통해 IE 초기 로딩 속도를 개선하는 사용자 체감 성능을 개선하는 성능 최적화 특징도 가진다.

재사용 가능한 공통업무 UDC 및 WRM을 제공하여 코딩을 줄이고 속성, 메서드, 이벤트 설정을 통해 공통개발 모듈화를 수행하며, 개발 현장에 즉시 적용 가능한 완성도 높은 공통 컴포넌트로 공통개발자 공수 절감 특징도 가진다.

도 6은 다양한 서버 구성 방식을 나타낸 도면이며, 도 7은 교차 MSA 자원 공유 기능과 MSA 메시지 브로커 기능에 대한 설명을 위한 도면이고, 도 8은 wframe이 구성된 경우 교차 MSA 공유 구조의 동작을 나타낸 도면이며, 도 9는 메시지 브로커를 이용한 페이지 컴포넌트 간 데이터 교환 방식을 나타낸 도면이다.

본 실시예에서는 마이크로 서비스 아키텍처(MSA) 방식으로 서버를 구성할 수 있다. 이 경우에도 웹 기반의 UI는 모놀리식한 방식으로 구성하는 것이 일반적이다.

마이크로 서비스 아키텍처는 서버 쪽에서 데이터 및 논리를 처리하기 시작하지만, 많은 경우 UI는 여전히 모놀리식으로 처리된다(도 6의 (b)). 하지만, 마이크로 프론트엔드 기법에서는 마이크로 서비스에 따라 애플리케이션 UI를 디자인한다. 즉, 서버에 마이크로 서비스를 배치하고, 모놀리식 클라이언트 앱이 마이크로 서비스를 사용하는 대신 마이크로 서비스에서 생성되는 복합 UI를 가진다(도 6의 (c)). 이 방법으로 마이크로 서비스는 논리 및 시각적 표현 모두를 사용하여 완료될 수 있다.

본 실시예에서 마이크로 프론트엔드는 2단계 과정을 지원한다.

1단계: wframe과 MSA UDC를 이용한 마이크로 서비스에 의한 개별 UI 구성

2단계: 마이크로 서비스로 구성된 화면 영역에서 사용되는 클라이언트 엔진과 프로젝트 UDC의 버전을 다르게 운영할 수 있도록 지원

도 7을 참조하면, MSA로 구성된 시스템을 구현하기 위해, 클라이언트 엔진은 여러 서버에서 필요한 리소스를 가져와 화면을 구성하는 기능을 가지는 교차 MSA 자원 공유 모듈과, UI 요소(Page)간 종속성을 제거(최소화)하면서 서비스간 데이터를 교환하는 기능(MSA 메시지 브로커)을 가지는 MSA 컴포넌트를 포함할 수 있다.

이하는 발명의 이해와 설명의 편의를 위한 용어의 정의이다.

메인 도메인: 현재 페이지의 URL 중 호스트 주소 부분을 나타낸다. 현재 페이지가 http://store.company.com/dir2/other.html 인 경우 store.company.com이 현재 도메인이다. 스크립트로 변경하지 않은 document.domain과 동일한 값이다.

서비스 도메인: MSA 서비스가 실행되는 서버의 호스트 주소를 나타낸다.

교차 MSA 자원 공유 모듈의 경우, 여러 서버에서 리소스를 가져오기 위해서 다음과 같은 기능 요구사항을 충족하도록 구현될 수 있다.

서비스 도메인에 위치한 페이지 컴포넌트를 wframe에 로드할 수 있어야 한다. 별도 설정(msaName 등)이 없는 경우 서비스 도메인에 위치한 페이지 컴포넌트에서 참조하고 있는 CSS, JS는 해당 서비스 도메인에서 로드하여야 한다. 별도 설정(msaName 등)이 없는 경우 서비스 도메인에 위치한 페이지 컴포넌트에서 로드한 UDC, wframe은 해당 서비스 도메인에서 로드하여야 한다. 별도 설정(msaName 등)이 없는 경우 서비스 도메인에서 로드한 페이지 컴포넌트에서 호출한 submission은 해당 서비스 도메인으로 요청을 보내야 한다. 별도 설정(msaName 등)이 없는 경우 $p.ajax는 $p의 서비스 도메인으로 요청을 보내야 한다.

이미지, CSS, JS도 모두 해당된다.

클라이언트 환경 설정 파일의 MSA UDC는 지정된 서비스 도메인에서 로드하여야 한다. 다른 서비스 도메인이나 메인 도메인의 페이지 컴포넌트를 로드할 수 있어야 한다. 다른 서비스 도메인이나 메인 도메인에 submission과 $p.ajax를 호출할 수 있어야 한다. 개발/테스트/운영 환경에서 소스 코드 변경을 최소화하기 위하여 메인 도메인, 서비스 도메인의 주소는 클라이언트 환경 설정 파일에 저장되어야 한다.

종속성을 최소화하면서 서비스간 데이터를 교환하기 위한 MSA 메시지 브로커 기능에 대한 기능 요구사항은 다음과 같다.

서로 다른 서비스 사이에서 데이터를 교환하기 위하여 pub-sub 모델을 기반으로 다음 기능을 제공하여야 한다. 모든 서비스에서 접근할 수 있는 전역 메시지 허브를 제공하여야 한다. 전역 메시지 허브에 메시지 채널을 등록하는 작업은 전역에서 접근할 수 있는 프로젝트 UDC, MSA UDC만 허용한다. 데이터는 비동기 방식의 메시지로 전달되어야 한다. 보안 및 메모리 누수 이슈를 방지하기 위하여 메시지는 텍스트 형태만 허용한다(JSON Object가 아닌 문자열 변환(stringfy)된 JSON 문자열만 허용). 각각의 서비스는 메시지 채널 구독, 메시지 발행 방식으로 데이터를 교환한다.

교차 MSA 자원 공유 구조는 다음과 같다.

config.xml의 msaCommon 설정을 통해 MSA를 지원하는 아키텍처를 제공한다. 본 시스템에서 제공하는 wframe, windowContainer(MDI), tabControl, widgetContainer, popup(frameMode='wframe'), MSA UD, UDC 컴포넌트에서 기능을 제공한다.

페이지 컴포넌트 및 submission의 요청 도메인은 다음과 같은 원칙으로 선택된다.

- 도메인 선택 원칙

msaName이 없는 경우 상위 Page의 서비스 도메인을 사용한다(msaName은 하위에서 상위 Page로 검색).

최상위 페이지는 html 파일과 동일한 도메인을 사용하며, 메인 도메인이라고 지칭한다.

msaName이 설정된 경우 config.xml의 msaServer를 참고하여 서비스 도메인을 설정한다.

- 도메인 선택 원칙 적용 대상

wframe, windowContainer 등 msaName를 지원하는 개별 컴포넌트

JS, CSS 등 리소스를 시스템에서 제공한 방식으로 로드하는 경우

submission, $p.ajax 등 서버에 요청을 보내는 경우

도 8과 같이 wframe이 구성된 경우 동작은 다음과 같다.

A, B, D의 경우 자신의 Page에 msaName이 설정되어 있어 설정된 도메인으로 요청을 전송한다.

C와 같이 msaName이 지정되어 있지 않은 경우 msaName이 지정된 상위의 Page를 검색하고 지정된 msaName을 통해 해당 도메인에서 페이지 컴포넌트(xml 파일)을 로드하고 해당 도메인으로 submission 요청을 보낸다. 따라서, C는 B의 msaName을 따라 http://sub1.inswave.com으로 요청을 전송하게 된다.

CORS 접근을 위해서는 추가 HTTP 헤더 설정이 필요하다. HTTP 요청 헤더에 필요한 추가 정보는 클라이언트 엔진에서 설정하지만, HTTP 응답 헤더는 해당 프로젝트에서 직접 설정하여야 한다.

교차 MSA 자원 공유 기능 설정은 다음과 같다.

msaServer 노드는 하위에 다건의 msa를 설정할 수 있으며, msa 노드를 통해 각각의 도메인을 설정할 수 있다.

msaCommon 노드는 MSA 서버에서 제공하는 공통 모듈인 MSA UDC를 로드하기 위한 설정으로 이름, 리소스 경로, MSA 서버명으로 구성된다.

msaStylesheet 노드는 MSA 서버에서 제공하는 CSS를 로드하기 위한 설정으로 리소스 경로, MSA 서버명으로 구성된다. msaStylesheet에 설정된 css는 파일이 설정된 순서에 따라 로드된다.

교차 MSA 자원 공유 기능을 이용한 페이지 컴포넌트(xml)의 다운로드 방법은 다음과 같다.

교차 MSA 자원 공유 기능을 이용한 자원의 다운로드 방법은 다음과 같다. 화면 렌더링에 필요한 다음 표의 목록에 속하는 유형의 자원을 다운로드한다.

CSS 내부에 정의된 이미지 처리는 다음과 같다.

다른 도메인에 있는 css를 다운로드하는 경우 css 내부에 이미지를 호출하게 되면 css를 요청한 서버에서 이미지를 찾게 되어 404 오류가 발생한다. 이런 경우 이미지 경로를 제어할 수 없어 css를 컴파일 하는 기술을 적용해야 한다. SASS를 통해 css 컴파일 기능을 제공할 수 있다.

Sass(Syntactically Awesome StyleSheets)는 CSS 전처리기(pre-processor)로서, CSS의 한계와 단점을 보완하여 보다 가독성이 높고 코드의 재사용에 유리한 CSS를 생성하기 위한 CSS의 확장(extension)이다. SASS 지원 모듈은 W-Pack 모듈에 기능을 추가할 수 있다.

교차 MSA 자원 공유 기능은 Ajax 통신을 지원한다. $p.ajax, submission에 msaName을 직접 설정하도록 지원할 수 있다.

만약 msaName 설정이 안된 경우 동작은 다음과 같다.

submission: 서비스 도메인(페이지 컴포넌트를 다운받는데 사용한 MSA 주소로 /msaServer/msa@baseUrl에 설정되어 있음)을 사용. 동적으로 생성하는 경우에도 동일하게 동작한다. 단, 외부 JS에서 subsmission을 동적으로 생성하는 경우 메인 도메인으로 요청을 전달한다.

$p.ajax: $p 객체를 생성한 서비스 도메인(페이지 컴포넌트를 다운받는데 사용한 MSA 주소로 /msaServer/msa@baseUrl에 설정되어 있음)을 사용. 단, 외부 JS에서 $p.submission을 실행하는 경우 메인 도메인으로 요청을 전달한다.

서비스 도메인을 사용하여 wq 요청 및 jsp 요청을 전달하여 엑셀, 파일 업/다운로드 등의 서블릿(servelet)을 지원할 수 있다. 단, 외부 JS에서 컴포넌트를 동적으로 생성하거나 외부 JS에서 $p.download와 같이 wq를 호출하는 API를 실행하는 경우에는 메인 도메인으로 요청을 전달한다.

다음으로 MSA 메시지 브로커의 구현 방법은 다음과 같다. 전역 DataCollection 기능은 제공하지 않는다.

허브 앤 스포크(Hub-and-Spoke) 방식의 MSA 메시지 브로커를 제공한다.

MSA 메시지 브로커는 메시지 채널, 메시지 발행자(publisher), 메시지 구독자(subscriber)와 기타 API로 구성된다.

메시지 채널은 프로젝트 UDC로 사용될 페이지 컴포넌트에서 등록한다. 프로젝트 UDC가 아닌 페이지 컴포넌트에 등록된 메시지 채널은 무시된다.

메시지 발행자, 메시지 구독자는 모든 페이지 컴포넌트에서 등록할 수 있다.

메시지 구독자는 onmessage 이벤트를 발생시킨다.

메시지 발행자는 메시지 발행자 id를 통하여 접근할 수 있고, send 메소드를 제공한다.

메시지 허브는 PCC 파일의 /head/msa/messageChannel에 설정하며 개발도구의 아웃라인뷰에서 등록/수정/삭제할 수 있다.

(a) 메시지 채널 등록 (Channel registration)

프로젝트 UDC, MSA UDC에서 메시지 채널을 생성한다. 메시지 채널로 /head/MSA/channels/channel 노드에 생성되며, 메시지 채널 id(메시지 구독, 발행에 사용되는 채널) 속성이 요구된다.

(b) 메시지 채널 구독 (Subscription)

MSA 메시지 브로커에서 메시지를 전달받기 위해서는 페이지 컴포넌트에서 메시지 채널을 구독하여야 한다. 메시지 채널 구독 정보는 /head/MSA/subscribers/subscribe 노드에 생성되며, 메시지 구독자 id, 메시지 채널 id(메시지를 구독할 채널 id), 메시지 발생 이벤트(메시지가 발생되었을 때 처리할 이벤트 핸들러 등록) 등의 속성이 요구된다.

(c) 메시지 발행자 등록 (Publisher registration) 및 메시지 발행 (publish event)

MSA 메시지 브로커에 메시지를 발행하기 위해서는 먼저 메시지 발행자로 등록한 다음 메시지 발행자 id를 이용하여 메시지를 발행하여야 한다. 메시지 발행자 등록 정보는 /head/MSA/publishers/publisher 노드에 생성되며, 메시지 발행자 id, 메시지 채널 id(메시지를 구독할 채널 id로 프로젝트 UDC 또는 MSA UDC에 접근할 때 사용하는 전역 변수와 채널 등록에 사용된 id가 결합된 형태임) 등의 속성이 요구된다.

(d) 관리 API

메시지 채널을 생성한 프로젝트 UDC, MSA UDC 내부 스크립트에는 메시지 채널을 관리하는데 사용되는 API에 접근할 수 있다. 제공되는 메소드는 다음과 같다.

도 10은 페이지를 이용한 단일 페이지로의 구조화 예시도이며, 도 11은 전통적인 웹 애플리케이션과 단일 페이지 웹 애플리케이션의 비교도이고, 도 12는 단일 페이지 애플리케이션의 다양한 구현 예이며, 도 13은 기존 웹 개발 방식(Iframe) 대비 단일 페이지 웹 애플리케이션 방식의 화면 표시 과정을 나타낸 도면이다.

기존 웹 개발방식(iframe mode)으로 화면을 개발하면 화면의 수에 비례하여 브라우저 기본 사용 메모리가 증가하고, 화면 리소스 중복 로딩으로 애플리케이션 사용 메모리가 증가하여 메모리 누수(memory leak)에 의한 오류가 발생할 수 있다(화면 백화 현상).

본 발명의 실시예에서는 이를 해결하기 위해 단일 페이지 애플리케이션(SPA)을 활용한다. 브라우저에 로드되고 난 뒤에 페이지 전체를 서버에 요청하는 것이 아니라 최초 한번 페이지 전체를 로딩한 후 이후부터는 데이터만 변경해서 사용할 수 있는 웹 애플리케이션이다.

페이지(Page) 기능을 사용하여 SPA 방식으로 화면을 개발하면, 화면의 수와는 관계없이 단일 페이지(One HTML Page)로 동작한다. 화면 리소스 중복 로딩이 없어 빠른 출력과 성능을 보장하고, 적은 메모리 사용으로 안정적인 시스템 운영이 가능할 수 있다.

개발도구(120)는 개발자가 화면 파일을 개발할 때, 해당 화면 파일을 단일 페이지 애플리케이션 타입으로 구성되게 한다.

화면 파일은 웹 페이지를 구성하는 정적 리소스와 동적 리소스를 구분한다. 정적 리소스는 브라우저 창, 클라이언트 엔진, 공통 스크립트, 공통 리소스를 포함할 수 있다. 동적 리소스는 웹 페이지 내에 포함되는 다양한 컨텐츠들로서, 화면 리소스일 수 있다.

브라우저에서 해당 웹 페이지를 로딩할 경우, 정적 리소스는 최초 1회의 요청에 의해 다운로드가 진행되게 설정될 수 있다.

그리고 동적 리소스는 부분 영역 렌더링을 통해 현재 화면에 표시되어야 하는 부분을 포함하는 컨텐츠 일부로서, 요청이 있을 경우에 한해 리소스가 로딩되고 렌더링된 후 스크립트 실행을 통해 표시되게 설정될 수 있다.

페이지는 화면 전환 없이 페이지를 로딩하는 웹 기술이다. 페이지는 단일 페이지로 구성되며, 전통적인 동적 웹 페이지(Traditional Web)와 비교하여 페이지간 빠른 전환, 서버의 트래픽 감소, 사이트 이용의 흐름을 유지하여 향상된 사용자 경험(UX)을 제공할 수 있다.

전통적인 동적 웹 페이지의 경우, 전체 페이지를 새로 고침한다. 요청시마다 정적 리소스를 다운로드하여 트래픽이 증가하고 로딩시간이 증가한다.

이에 비해, 단일 페이지 애플리케이션(SPA)의 경우, 부분 영역을 렌더링한다. 정적 리소스는 한번만 다운로드한다. 페이지 이동 없이 컨텐츠만 변경하며, 기존 리소스를 재활용할 수 있다. 기존에 없는 리소스만 요청하면 충분하므로, 트래픽이 감소하고 로딩시간이 감소된다.

동적으로 컨텐츠를 추가하는 컴포넌트의 경우, iframe이 아닌 Page를 이용하여 SPA 화면을 개발할 수 있다.

Scope 옵션은 Page를 사용하여 동적으로 추가된 페이지 간의 전역 객체 명 중복 문제를 해결해줄 수 있다.

Scope는 웹 페이지를 구성하는 모든 단위 화면에 유효 범위(scope)를 설정하는 기능이다. 모든 화면은 Scope 단위로 존재하기 때문에, Scope에 포함된 객체 및 스크립트는 Scope 내에서만 유효하다.

Scope 기능을 사용할 경우 개발자는 웹페이지 전체를 하나의 단일 페이지(Single Page)로 구현할 수 있다. 보통의 경우 IFrame을 프레임 단위로 사용하지만, IFrame은 매번 사용할 때마다 브라우저가 다시 로딩되기 때문에 메모리 부하가 증가하는 단점이 있다. 독립된 단위로 동작하는 WFrame은 기존의 IFrame을 대체할 수 있으며, 개발자는 IFrame 사용을 최소화하여 웹 애플리케이션의 전반적인 성능을 개선할 수 있다.

Scope 관련 API는 다음과 같다.

$p 항목에서 main은 현재 윈도우 내의 최상위 페이지에 해당하는 scope 객체를 반환한다. $는 jQuery selector를 인자로 받아 jQuery 객체를 반환하고, id selector를 인자로 받은 경우 해당 id의 웹스퀘어 객체가 페이지에 있는 경우 웹스퀘어 객체의 실제 id로 변환한 다음 함수를 실행한다.

$p.debug 항목에서 getScope는 dom 객체를 인자로 받아 해당 dom이 위치한 페이지의 scope 객체를 반환한다. getFrame은 dom 객체를 인자로 받아 해당 dom이 위치한 페이지의 WFrame id를 반환한다.

WFrame 항목에서 getWindow는 WFrame의 Scope 객체를 반환한다. 해당 객체를 통해 WFrame 화면 안의 객체에 접근할 수 있다.

TabControl 항목에서 getWindow는 idx에 해당하는 탭의 Scope 객체를 반환한다. idx는 유효한 tabID 또는 tabIndex 값이어야 한다.

WindowContainer 항목에서 getFrame은 windowId에 해당하는 window의 frame 객체(iframe 또는 wframe)를 반환한다.

WFrame의 주요 API는 다음과 같다.

getWindow는 WFrame의 Scope 객체를 반환한다. wframe 화면 안의 객체를 접근하려면 이 함수를 호출해야 한다. getSrc는 현재 WFrame이 포함하고 있는 페이지의 주소를 반환한다. setSrc는 WFrame 화면을 url에 해당하는 화면으로 동적으로 변경한다. remove는 wframe을 완전히 제거한다.

Page가 적용되면 브라우저 창 생성, 웹스퀘어 엔진, 공통 스크립트, 공통 리소스의 로딩과 실행 시 사용되는 클라이언트의 자원(Memory) 사용을 줄일 수 있어 향상된 성능을 얻을 수 있다.

도면에는 iframe 모드에서의 로딩 방식과 Page(WFrame) 모드에서의 로딩 방식이 비교되어 있다.

클라이언트에서 수행되는 화면 실행 과정에는, 브라우저 창 생성(단계 1), 웹스퀘어 엔진 로딩(단계 2), 웹스퀘어 엔진 실행(단계 3), 웹스퀘어 리소스 로딩(단계 4), 공통 스크립트 로딩(단계 5), 공통 스크립트 실행(단계 6), 공통 리소스 로딩(CSS)(단계 7), 화면 리소스 로딩(단계 8), 화면 렌더링(단계 9), 화면 스크립트 실행(단계 10)이 순차적으로 포함된다.

iframe 모드에서는 (화면 개수+1) 개의 브라우저 창(main window, iframe window, popup window), (화면 개수+1) 개의 웹스퀘어 엔진이 필요하게 된다.

이에 비해, WFrame 모드에서는 단계 1~단계 7이 최초 1회만 실행되면 충분하므로, 1개의 브라우저 창(main window), 1개의 웹스퀘어 엔진이면 충분하다.

따라서, 화면 로딩 속도가 향상되고 메모리 사용량이 감소할 수 있다.

도 14는 W-Pack 실행 구조를 나타낸 도면이고, 도 15는 화면 소스 변환 모듈의 상세 구성도이다.

소스 컴파일러인 W-Pack는 화면 소스(XML)를 자바스크립트로 번들링(bundling) 및 트랜스파일(transpile)하는 화면 소스 변환 모듈이다. 웹스퀘어 엔진이 자바스크립트를 이용하여 화면을 그릴 수 있도록 스크립트 변환, 난독화, 최소화 기능을 제공할 수 있다.

화면 소스 변환 모듈(1500)은 화면 소스인 XML과 동일한 정보를 가지고 있는 JSON이 포함된 JS 파일을 생성하여 웹스퀘어 엔진이 JSON을 파싱하면서 화면을 그리도록 변경한다. 화면 소스 변환 모듈(1500)은 XML 노드를 순회하면서 JSON 형태로 변경하는 작업을 수행한다.

도 15를 참조하면, 화면 소스 변환 모듈(1500)은 변환 대상이 되는 화면 소스를 모니터링하는 모니터부(1510)와, 변환하고자 하는 화면 소스를 자바스크립트로 컴파일하는 컴파일러부(1520)를 포함할 수 있다.

모니터부(1510)에는 파일 입출력 모니터, SVN 모니터, GIT 모니터와 같은 모니터와, 모니터를 통해 모니터링된 화면 소스가 큐잉되는 비동기 큐와, 비동기 큐의 화면 소스가 각각 전달되는 워커(Worker)를 포함한다. 워커에서는 컴파일러부(1520)로 XML 타입의 화면 소스를 전달한다.

컴파일러부(1520)는 XML 파일을 JS 파일로 변환하는 XML-JS 컨버터와, 추상 구문 트리를 생성하는 트리 생성기(AST)와, 생성된 추상 구문 트리를 검증하는 검증부(Validator)와, 검증에 성공하면 JS 파일을 최적화하는 최적화부(Optimizer)와, 최적화된 JS 파일에 대해 코드 난독화를 적용하는 난독화부(Obfuscator)와, 난독화된 결과에 대해 압축을 통해 최소화시켜 자바스크립트로 출력하는 최소화부(Minifier)를 포함한다.

도 16은 레이아웃 매니저에서의 해상도 설정 화면과 그리드 레이아웃 매니저의 예시 화면이며, 도 17은 레이아웃 매니저의 각 디바이스 탭의 예시도이고, 도 18은 레이아웃 매니저에서 수행되는 화면 개발 방법의 순서도이다.

본 실시예의 시스템, 특히 개발도구(120)에는 반응형/적응형 웹을 구현하기 위한 레이아웃 매니저가 포함된다. 업무 시스템에 최적화된 해상도를 설정하고, 다양한 유형의 레이아웃 템플릿을 선택할 수 있다.

레이아웃 매니저는 그리드 레이아웃 컴포넌트를 통해 레이아웃을 쉽게 구성할 수 있도록 지원한다. 웹 표준을 준수하면서 개발자가 화면을 쉽게 편집할 수 있도록 CSS3 그리드 레이아웃 표준을 이용한 화면 편집 및 다중 해상도를 지원할 수 있다.

다양한 디바이스를 고려한 레이아웃을 표현하기 위해 해상도 정보와 레이아웃 정보를 설정하고 사용할 수 있도록 한다. 이를 위해 클라이언트 환경 설정에 해상도 정보를 위한 미디어 정보(media info)를 설정하고, 웹스퀘어 레이아웃에는 스튜디오에서 필요한 레이아웃 정보(layout info)를 설정해야 할 수 있다.

미디어 정보에는 해상도가 포함될 수 있다. 해상도는 레이아웃 컴포넌트 파일에 설정될 수 있다. 페이지에 지정된 레이아웃 컴포넌트 지원 멀티 디자인 탭으로 구현될 수 있다.

레이아웃 정보는 페이지 컴포넌트 파일에 저장될 수 있으며, 화면 렌더링에 사용될 레이아웃 파일과 영역을 지정할 수 있다.

웹스퀘어 페이지 컴포넌트는 레이아웃 정보에 정의된 레이아웃 항목 개수만큼 디자인 탭을 생성하여 디바이스 해상도와 페이지 컴포넌트의 크기를 고려하여 화면을 편집할 수 있도록 지원한다.

레이아웃 매니저는 개발 대상이 되는 디바이스의 개수에 상응하는 디바이스 탭을 생성한다. 디바이스 탭 각각에는 화면 개발 대상이 되는 디바이스들이 개별적으로 할당될 수 있다.

디바이스 탭의 화면에서는 업무 시스템에 적용할 컴포넌트들이 배치된 모습이 해당 디바이스 탭에 할당된 디바이스의 해상도에 맞춰 실제 해당 디바이스의 화면에서 표시될 때와 같이 표시될 수 있다. 개발자는 디바이스 탭의 화면을 통해 현재 개발 중인 업무 시스템의 화면 구성에서 오류 여부를 파악하고 수정할 수 있다.

OSMU 원칙에 따라, 모든 디바이스 탭의 화면에 구현되는 컴포넌트는 서로 동일성을 가지고 있다. 다만, 디바이스의 해상도에 따라 표현되는 방식에서 차이가 있는 것이다.

레이아웃 매니저는 제1 디바이스 탭의 화면에서 임의의 컴포넌트에 대해 그 레이아웃을 수정할 수 있다. 이 경우 이러한 수정사항은 다른 디바이스 탭(제2 내지 제N 디바이스 탭)에도 연동되어 동일하게 적용될 수 있다.

다만, 이 때 제1 디바이스 탭의 화면에서는 문제없이 적정 위치로 이동되거나 적정 크기로 수정된 컴포넌트라 할지라도, 다른 디바이스 탭 중 하나 이상에서는 서로 다른 지원 해상도로 인해 의도한 레이아웃을 유지하지 못하고 벗어나 화면 구성에 문제가 발생할 수 있다.

이에 대해 개발자는 각 디바이스 탭을 순차적으로 선택하면서 각 탭의 화면을 확인하고 일일이 수정해 줄 수도 있다. 하지만, 이 과정에서 앞서 문제없이 수정한 제1 디바이스 탭에서 문제가 발생할 수도 있다.

따라서, 제1 디바이스 탭의 화면에서 레이아웃을 조정하는 중에 컴포넌트에 변경사항이 발생한 경우(단계 S1800), 레이아웃 매니저는 타 디바이스 탭에 대해서도 동일한 변경사항을 자동 적용한다(단계 S1810).

그리고 타 디바이스 탭 중 하나 이상에서 문제가 발생하는지 판단한다(단계 S1820). 도 17을 참조하면, (a), (c), (d)의 디바이스 탭에서는 모든 컴포넌트가 문제없이 배치되어 표시되고 있지만, (b)의 디바이스 탭에서는 화면 가운데 배치되는 4개의 블록이 정렬되지 못하고 있음을 확인할 수 있다. 이 경우 (b)의 디바이스 탭에서 문제가 발생한 것으로 판단할 수 있다.

만약 문제가 발생하는 것으로 판단된 경우, 개발자가 보고 있는 제1 디바이스 탭의 화면 내에서 변경하고자 한 컴포넌트와 관련하여 문제 발생 가능성에 대해 인지할 수 있게 지정된 방식으로 표시할 수 있다(단계 S1830). 지정된 방식은 미리 지정된 색상(예. 빨강)으로 해당 컴포넌트가 표시되게 하거나, 해당 컴포넌트를 점멸되게 하거나, 해당 컴포넌트의 크기가 신축을 반복하게 하는 것일 수 있다.

이러한 표시에 의해 개발자는 현재 편집 중인 컴포넌트와 관련하여, 제1 디바이스 이외에 타 디바이스에서 레이아웃에 문제가 발생할 수 있음을 인지하고, 즉각적으로 그리고 일괄적으로 바르게 교정할 수 있다(단계 S1840).

도 19는 디자인 시스템의 구성도이며, 도 20은 스니핏 가이드 및 템플릿 활용 예시도이다.

디자인 시스템은 개발자와 디자이너 협업 강화를 위한 모듈이다. 웹이나 서비스에서 디자인의 일관성을 유지하는데 필요한 디자인 스타일의 규칙이나 가이드라인과 공통으로 사용되는 컬러, 폰트, 레이아웃, UI 컴포넌트 등이 모여 있는 시스템이다.

디자인 시스템에는 기획자, 디자이너, 개발자 등 관련 이해 당사자들이 필요로 하는 다양한 리소스가 포함되어 있다. 그 중에는 디자인 패턴 및 디자인 가이드와 같이 모든 이해 당사자가 사용하는 요소도 있지만, 개발자와 퍼블리셔가 주로 사용하는 CSS, 컴포넌트, 레이아웃, 템플릿과 같은 요소도 제공함으로써 개발 생산성을 더욱 향상시킬 수 있다.

CSS는 디자인의 일관성을 유지하는데 필요한 공통 CSS로, CSS 또는 SCSS 형태로 제공된다. 컴포넌트는 버튼, 입력폼과 같이 HTML, web-components, React, Vue 등의 소스 코드를 제공한다. 레이아웃은 Flex, Grid, Stack 등 화면의 배치와 관련된 소스 코드를 제공한다. 템플릿은 자주 사용되는 화면 유형과 관련된 소스 코드를 제공한다.

디자인 시스템 모듈(1900)은 퍼블리셔 및 개발자가 디자인의 일관성을 유지하면서 웹스퀘어로 개발하는데 필요한 기능들이 모여 있다. 디자인 시스템 모듈(1900)은 애플리케이션을 개발하는데 도움을 주기 위한 웹스퀘어 스튜디오의 기능이다.

디자인 시스템 모듈(1900)은 디자인 시스템 뷰, 공통 CS, UDC, 스니핏, 템플릿의 요소로 구성된다. 특히, 디자인 시스템 뷰는 UDC, 스니핏 관련 부분을 웹스퀘어 스튜디오에 내장하여 표현할 수 있도록 지원한다.

디자인 시스템 뷰는 UDC, 스니핏을 시각적으로 표현하여 비주얼한 이미지와 설명이 포함된 웹페이지를 로드할 수 있는 내장 웹 브라우저이다. UDC, 스니핏에 대한 비주얼한 이미지와 설명이 포함된 html 및 관련 리소스를 프로젝트에 저장하고, 디자인 시스템 뷰에 로드되게 할 수 있다.

디자인 시스템 뷰는 이클립스 프로젝트의 종속적인 기능으로, 현재 활성화된 웹스퀘어 에디터가 포함된 프로젝트에 정의된 리소스를 이용하여 디자인 시스템 뷰를 표시할 수 있다. 여러 프로젝트의 파일을 동시에 편집하는 경우 A 파일을 편집하다가 다른 파일을 편집하고 다시 A 파일을 편집할 때 A 파일과 연관된 디자인 시스템 뷰의 리소스가 처음 A 파일을 편집할 때의 상태(스크롤 위치, 페이지 링크 이동 등)가 그대로 유지되게 할 수 있다.

CSS, UDC, 스니핏, TTC, 기본 컴포넌트를 디자인 데이터에 추가할 수 있다. 스니핏 추가를 위한 insertSnippet, UDC, TTC, 내장 컴포넌트 추가를 위한 insertComponent, 스니핏을 다운로드하여 프로젝트에 반영하기 위한 updateSnippetResource, UDC를 다운로드하여 프로젝트에 반영하기 위한 updateUDC 등이 API가 있다.

디자인 시스템을 위한 웹페이지는 로컬 또는 리모트에 존재할 수 있다. 스니핏 가이드 문서는 디자인 시스템용 웹페이지로 변환되어, UI 공통 템플릿 및 기본 템플릿 지원 설정 시 디자인 시스템 뷰에 표시되게 제공할 수 있다.

디자인 시스템의 리소스는 스튜디오로 다운로드할 수 있다.

디자인 시스템을 위한 웹과 이클립스(RCP)의 통신은 JSON 형식의 메시지를 사용한다. 디자인 시스템 뷰의 웹페이지에서 RCP로 호출하는 요청 메시지의 msgType은 "REQUEST"이고, action에서 RCP에서 처리할 기능을 정의한다. action의 종류별 추가 정보는 req 객체를 이용하여 전달한다. 모든 요청은 비동기 방식으로 동작할 수 있다.

RCP에서 디자인 시스템 뷰의 웹페이지로 전달하는 응답 메시지의 msgType은 "RESPONSE"이고, action은 요청시 전달한 값을 그대로 사용하고 상세 응답 메시지는 res 객체를 이용하여 전달한다.

스니핏은 조각 템플릿으로, 이를 이용하여 코드 재활용을 극대화함으로써 개발 생산성 및 유지보수 효율성을 향상시킬 수 있다. 개발자가 자주 사용하거나 복잡하게 작성된 소스 코드를 미리 등록하여 재활용함으로써 중복 개발을 막고 소스 코드를 표준화하여 개발 편의성 및 개발 생산성을 향상시킬 수 있다.

도 20에 도시된 것과 같이, 디자인 시스템 뷰에서는 개발자가 개발하고자 하는 화면에 관한 개발자 UI 표준 지침서(Snippets Guide)를 표시할 수 있다.

① 컨텐츠 영역: 화면을 그리기 위한 처음 단계이며, 컨텐츠 전체 영역임

② 페이지 타이틀: 화면 최상단 화면 경로 + 우측의 버튼 영역으로 구성되고, 최상단 페이지 타이틀은 공통 wframe으로 사용함

③ 컨텐츠 그룹: 컨텐츠 영역 내 섹션별 영역임

④ 그리드: 기본 그리드

⑤ 분할 영역: 컨텐츠 영역을 일정 비율(예: 3:7)의 크기로 2분할한 레이아웃 사용함

그리고 개발자 UI 표준 지침서에 따라 스니핏 뷰를 통해 템플릿을 활용할 수 있다.

도 19를 참조하면, 개발도구(120)에서는 디자인 편집기(1910)를 통해 개발자가 개발 중인 화면을 볼 수 있게 한다.

디자인 편집기(1910)는 디자인 시스템 뷰(1920)와 연결된다. 디자인 시스템 뷰(1920)에는 검색, 즐겨찾기, 미리보기, 스니핏, 템플릿, UDC, CSS, FONT, COLOR 등의 기능 모듈이 포함될 수 있다.

디자인 시스템 뷰(1920)는 연결된 디자인 시스템 서버(1930)로부터 디자인 표준 및 리소스를 조회할 수 있다.

디자인 시스템 뷰(1920)는 디자인 시스템 서버(1930)에서 조회한 디자인 표준 및 리소스에 기초한 디자인이 디자인 편집기(1910)에서 편집 중인 화면에 적용되게 한다.

전술한 화면 개발 방법은, 컴퓨터에 의해 실행되는 애플리케이션이나 프로그램 모듈과 같은 컴퓨터에 의해 실행가능한 명령어를 포함하는 기록매체의 형태로도 구현될 수 있다. 컴퓨터 판독 가능 매체는 컴퓨터에 의해 액세스될 수 있는 임의의 가용 매체일 수 있고, 휘발성 및 비휘발성 매체, 분리형 및 비분리형 매체를 모두 포함한다. 또한, 컴퓨터 판독 가능 매체는 컴퓨터 저장 매체를 포함할 수 있다. 컴퓨터 저장 매체는 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현된 휘발성 및 비휘발성, 분리형 및 비분리형 매체를 모두 포함한다.

전술한 화면 개발 방법은, 단말기에 기본적으로 설치된 애플리케이션(이는 단말기에 기본적으로 탑재된 플랫폼이나 운영체제 등에 포함된 프로그램을 포함할 수 있음)에 의해 실행될 수 있고, 사용자가 애플리케이션 스토어 서버, 애플리케이션 또는 해당 서비스와 관련된 웹 서버 등의 애플리케이션 제공 서버를 통해 마스터 단말기에 직접 설치한 애플리케이션(즉, 프로그램)에 의해 실행될 수도 있다. 이러한 의미에서, 전술한 화면 개발 방법은 단말기에 기본적으로 설치되거나 사용자에 의해 직접 설치된 애플리케이션(즉, 프로그램)으로 구현되고 단말기 등의 컴퓨터로 읽을 수 있는 기록매체에 기록될 수 있다.

상기에서는 본 발명의 실시예를 참조하여 설명하였지만, 해당 기술 분야에서 통상의 지식을 가진 자라면 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

100: 사용자 인터페이스 플랫폼 개발 시스템
110: 서버 120: 개발도구
130: 클라이언트 140: 디바이스

Claims (7)

1. 사용자 인터페이스 플랫폼 개발 시스템으로서,
   위지위그 방식의 화면 파일 개발 환경을 제공하여 사용자 인터페이스 플랫폼을 구조화된 컴포넌트로 구성한 화면 파일 소스를 생성하는 개발도구;
   상기 개발도구로 화면 파일 개발을 위한 리소스를 제공하고, 개발된 화면 파일 소스가 등록되는 서버; 및
   상기 서버에 요청하여 응답받은 상기 화면 파일 소스를 로딩하는 클라이언트 엔진을 포함하고 브라우저 창에서 실행시켜 연계된 디바이스에 상응하는 상기 사용자 인터페이스 플랫폼을 제공하는 클라이언트를 포함하되, 상기 개발도구는 상기 화면 파일 소스를 자바스크립트로 번들링 및 트랜스파일하는 화면 소스 변환 모듈을 포함하는 것을 특징으로 하는 사용자 인터페이스 플랫폼 개발 시스템.
   
2. 제1항에 있어서,
   상기 화면 소스 변환 모듈은 상기 화면 파일 소스인 XML과 동일한 정보를 가지고 있는 JSON이 포함된 JS 파일을 생성하여 상기 클라이언트에서 상기 JSON을 파싱하면서 화면을 그리도록 변경하는 작업을 수행하는 것을 특징으로 하는 사용자 인터페이스 플랫폼 개발 시스템.
   
3. 제2항에 있어서,
   상기 화면 소스 변환 모듈은 상기 화면 파일 소스를 모니터링하는 모니터부와; 상기 화면 파일 소스를 자바스크립트로 컴파일하는 컴파일러부를 포함하는 것을 특징으로 하는 사용자 인터페이스 플랫폼 개발 시스템.
   
4. 제3항에 있어서,
   상기 컴파일러부는, XML 파일을 JS 파일로 변환하는 XML-JS 컨버터와; 추상 구문 트리를 생성하는 트리 생성기와; 생성된 추상 구문 트리를 검증하는 검증부와; 검증에 성공하면 상기 JS 파일을 최적화하는 최적화부와; 최적화된 상기 JS 파일에 대해 코드 난독화를 적용하는 난독화부와; 난독화된 결과에 대해 압축을 통해 최소화시켜 자바스크립트로 출력하는 최소화부를 포함하는 것을 특징으로 하는 사용자 인터페이스 플랫폼 개발 시스템.
   
5. 제1항에 있어서,
   상기 컴포넌트에는 페이지(Page) 컴포넌트, 사용자 정의 컴포넌트(UDC), 프로젝트 UDC, MSA UDC 중 하나 이상이 포함되는 것을 특징으로 하는 사용자 인터페이스 플랫폼 개발 시스템.
   
6. 제1항에 있어서,
   상기 클라이언트는 마이크로 서비스 아키텍처에 대응하기 위한 MSA 메시지 브로커 및 교차 MSA 자원 공유 기능의 마이크로 프론트엔드 아키텍처를 가지는 것을 특징으로 하는 사용자 인터페이스 플랫폼 개발 시스템.
   
7. 제1항에 있어서,
   상기 개발도구는 상기 화면 파일을 단일 페이지 애플리케이션 타입으로 구성되게 하는 것을 특징으로 하는 사용자 인터페이스 플랫폼 개발 시스템.
   

Images