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

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

Info

Publication number
WO2022203387A1
WO2022203387A1 PCT/KR2022/004057 KR2022004057W WO2022203387A1 WO 2022203387 A1 WO2022203387 A1 WO 2022203387A1 KR 2022004057 W KR2022004057 W KR 2022004057W WO 2022203387 A1 WO2022203387 A1 WO 2022203387A1
Authority
WO
WIPO (PCT)
Prior art keywords
screen
file
user interface
development
page
Prior art date
Application number
PCT/KR2022/004057
Other languages
English (en)
French (fr)
Inventor
어세룡
김욱래
Original Assignee
(주)인스웨이브시스템즈
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020220035234A external-priority patent/KR20220132457A/ko
Application filed by (주)인스웨이브시스템즈 filed Critical (주)인스웨이브시스템즈
Publication of WO2022203387A1 publication Critical patent/WO2022203387A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/103—Formatting, i.e. changing of presentation of documents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/14—Tree-structured documents
    • G06F40/143—Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/166—Editing, e.g. inserting or deleting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/34—Graphical or visual programming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/35—Creation or generation of source code model driven
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/38—Creation or generation of source code for implementing user interfaces

Definitions

  • the present invention relates to a user interface platform integrated development system and method having a source compiler.
  • Digital transformation is the application of digital technology to society as a whole to innovate the traditional social structure.
  • ICT information and communication technologies
  • IoT Internet of Things
  • AI artificial intelligence
  • big data solutions as a platform in a company.
  • the present invention supports multi-browser, multi-device, and multi-OS with One Source Multi Use (OSMU), is equipped with various and advanced components, provides an integrated development environment, and flexibly links with external libraries. This is to provide a user interface platform integrated development system and method having a web standard technology-based microservice architecture that can provide an optimal screen for various web environments and devices.
  • OSMU One Source Multi Use
  • An object of the present invention is to provide a user interface platform integrated development system and method having a source compiler that reduces a file size, reduces a loading time, and reduces memory usage by optimizing a developed screen file for a browser.
  • a user interface platform development system comprising: a development tool that provides a screen file development environment of the WYSIWIG method to generate a screen file source composed of a user interface platform with structured components; a server that provides a resource for developing a screen file with the development tool and registers a developed screen file source; and a client including a client engine that requests and loads the source of the screen file received in response to the server and executes it in a browser window to provide the user interface platform corresponding to the associated device, wherein the development tool includes the screen file
  • a user interface platform development system comprising a screen source conversion module for bundling and transpiling the source into JavaScript.
  • the screen source conversion module may generate a JS file including JSON having the same information as XML, which is the screen file source, and change the client to draw a screen while parsing the JSON.
  • the screen source conversion module includes: a monitor unit for monitoring the screen file source; It may include a compiler unit that compiles the screen file source into JavaScript.
  • the compiler unit includes: an XML-JS converter for converting an XML file into a JS file; a tree generator for generating an abstract syntax tree; a verification unit that verifies the generated abstract syntax tree; an optimization unit that optimizes the JS file if the verification is successful; an obfuscation unit that applies code obfuscation to the optimized JS file; It may include a minimization unit that minimizes the obfuscated result through compression and outputs it as JavaScript.
  • the component may include one or more of a page component, a user-defined component (UDC), a project UDC, and an MSA UDC.
  • a page component a user-defined component (UDC)
  • UDC user-defined component
  • MSA UDC MSA UDC
  • the client may have a micro front-end architecture of MSA message broker and cross-MSA resource sharing function to correspond to the micro service architecture.
  • the development tool may configure the screen file as a single page application type.
  • one-source multi-use supports multi-browser, multi-device, and multi-OS, is equipped with various and advanced components, provides an integrated development environment, and flexible connection with external libraries is possible. , it has the effect of providing an optimal screen for various web environments and devices.
  • FIG. 1 is a diagram showing the architecture of a user interface platform development system according to an embodiment of the present invention
  • FIG. 2 is a structure comparison diagram of XML code and general HTML code generated by the system according to an embodiment of the present invention
  • 3 is a view showing the script execution sequence when the main screen overlaps wframe
  • FIG. 4 is a flowchart of a user interface platform development method according to an embodiment of the present invention.
  • FIG. 5 is an exemplary diagram for explaining the componentization of a page
  • FIG. 6 is a view showing various server configuration methods
  • FIG. 7 is a diagram for explaining the cross-MSA resource sharing function and the MSA message broker function
  • FIG. 8 is a diagram showing the operation of the cross-MSA sharing structure when wframe is configured
  • FIG. 9 is a diagram illustrating a data exchange method between page components using a message broker
  • FIG. 10 is an exemplary diagram of a structure into a single page using a page
  • FIG. 11 is a comparison diagram of a traditional web application and a single page web application
  • FIG. 13 is a view showing a screen display process of a single page web application method compared to the existing web development method (Iframe);
  • 16 is an example screen of a resolution setting screen and a grid layout manager in the layout manager;
  • 20 is an example of using a snippet guide and template.
  • FIG. 1 is a diagram showing the architecture of a user interface platform development system according to an embodiment of the present invention
  • FIG. 2 is a structure comparison diagram of XML code and general HTML code generated in the system according to an embodiment of the present invention
  • 3 is a diagram illustrating a script execution sequence when the main screen includes a wframe overlapping
  • FIG. 4 is a flowchart of a user interface platform development method according to an embodiment of the present invention
  • FIG. 5 is a diagram illustrating componentization of a page It is an example for doing.
  • the user interface platform development system 100 supports various smart devices and web browser environments of clients, and the server environment is any web application server (WAS) supporting Java 2 Enterprise Edition (J2EE). , Web Application Server), arbitrary frameworks, and arbitrary OS support platform independence.
  • WAS web application server
  • J2EE Java 2 Enterprise Edition
  • Web Application Server Web Application Server
  • frameworks arbitrary frameworks
  • OS support platform independence any web application server (WAS) supporting Java 2 Enterprise Edition (J2EE).
  • WebSquare developed and sold by the present applicant.
  • the user interface platform development system 100 responds to requests from the client 130 used by the user, the development tool 120 used by the developer (also referred to as 'studio'), and the client 130, and the development tool 120 ) includes a server 110 that enables websquare screen file development.
  • the development tool 120 provides an environment in which a developer can develop a WebSquare screen file related to a business system.
  • a client engine is installed in the client 130 , and the client engine displays the WebSquare screen file in the browser.
  • the client 130 is made of JavaScript and is based on the AJAX architecture. Supports dynamic execution of UI components such as grids and charts. It may contain utilities related to communications and other UIs.
  • the client engine included in the client 130 may have a single page application (SPA, Single Page Application) structure.
  • SPA Single Page Application
  • the client engine can include modules such as UDC, Page Component, Project Component, MSA Component, Grid Layout, UI Component, MSA Message Hub, Cross MSA Resource Sharing, Data Collection, Module Loader, Promise Workflow, Logging/Debugging, etc. .
  • Component is a basic file and can be used to develop Page, Project UDC, MSA UDC, UDC, and TTC. By composing all screens of the business system into structured components, it can support efficient operation that can be reused anywhere.
  • WebSquare page component is a basic screen file used in the form of a component. Supports newly added project UDC, MSA UDC, UDC and TTC. The extension uses xml.
  • UDC is an abbreviation of User Defined Component, which is a user-defined component registered in the palette of the studio.
  • TTC is an abbreviation of Trust Third-part Component, and supports the use of external solutions as WebSquare page components.
  • Project UDC is a common function file containing common functions used throughout the project. It is defined in WebSquare environment settings and is automatically loaded when WebSquare engine is loaded.
  • MSA UDC is a common function file containing common functions to support Micro Frontend. It is defined in the WebSquare environment setting and loads resources from the server where the microservice runs when the related WebSquare engine is loaded.
  • Components largely include built-in components, SP4 UDC components, and Websquare components.
  • GridView which includes Grid, Table, Combo, Input, and TabControl. This is a component provided by WebSquare.
  • SP4 UDC components include SP4 UDC and SPC TTC. As a user-defined component standard, it is a UDC that developers can add directly. And it is TTC, which added component products through collaboration with solution manufacturers.
  • WebSquare components include UDC, TTC, Project UDC, and MSA UDC.
  • UDC and TTC are Page-based custom components introduced to increase the reusability of UI elements (Page) developed by developers. By simplifying/structuring the existing Page (XML), all Pages can be developed as components. It can be modularized by lowering the degree of coupling between pages.
  • Project UDC is a global UDC, a component that can be called in all screens. Reuse can be maximized by using it for common task UDC development.
  • MSA UDC is a UDC for micro front-end implementation, which applies MSA and enables cross-domain processing.
  • Data Collection is a module for intuitive data management in the form of tables and consistent and convenient data management. By providing an API similar to the grid component, developers can easily manipulate it in the form of a grid.
  • the server 110 stores application resources (images, HTML, JS, CSS, XML, etc.).
  • the server architecture includes utilities for adapters, file upload/download, Excel I/E (import/export), license management, and more.
  • a module for the framework interface a common business module, a business module, a DBIO, and a system common module may be included.
  • the server 110 may be implemented independently of the OS, DBMS, and WAS to support platform independence.
  • the development tool 120 provides an integrated development environment of a WYSIWYG method, and can support easy development for developers. A developer can draw a component, add a script, check a screen, debug, etc. at once through the development tool 120 .
  • the development tool 120 may perform configuration management (SCM, Software Configuration Management) using SVN/CVS/Git or the like.
  • SCM Software Configuration Management
  • Commercial configuration management solutions can be linked with vendor plug-ins provided by vendors.
  • the development tool 120 includes W-Pack (source compiler), design system, snippet, Git/SVN, MSA message hub editor, WRM component, grid layout editor, layout manager, page component editor, design editor, code Modules such as editors and message interfaces may be included. In addition, it supports reusable common task UDC.
  • W-Pack source compiler
  • design system design system
  • snippet snippet
  • Git/SVN MSA message hub editor
  • WRM component grid layout editor
  • layout manager layout manager
  • page component editor design editor
  • code Modules such as editors and message interfaces
  • HTTP REST API JSON/XML
  • the web server 110 finds a resource and Data is exchanged with the application server 110 , and a response (HTTP REST API (JSON/XML)) corresponding to the request may be transmitted to the client 130 .
  • a JS screen source may be distributed in a connection relationship between the web server 110 and the development tool 120 .
  • the microservice architecture in order to correspond to the microservice architecture (MSA), it may have a micro front-end architecture of an MSA message broker and a cross MSA resource sharing function.
  • performance can be improved through single page application (SPA), engine optimization (Engine Optimizer), resource optimization (W-Pack), and large data processing support.
  • SPA single page application
  • Engine Optimizer engine optimization
  • W-Pack resource optimization
  • the XML code generated by WebSquare and the general HTML code structure are compared in (a) and (b) of FIG. 2 .
  • WebSquare XML code The components of WebSquare XML code are largely divided into ⁇ head> and ⁇ body>.
  • ⁇ head> contains ⁇ xf:model>, ⁇ script>, and ⁇ style> elements.
  • ⁇ xf:model> contains ⁇ w2:dataCollection>, ⁇ xf:workflow>, and ⁇ xf:submission> areas.
  • ⁇ w2:dataCollection> is an area defining a data object, and includes DataMap, DataList, and LinkedDataList. Defines request and response data for server communication and data to be used in the screen.
  • ⁇ xf:workflow> defines the execution order of submit and submitDone. It is used when executing multiple submissions. It defines the execution order, the result processing order, and whether or not to execute the submission after the result. It is recommended to use it for communication for select purposes.
  • ⁇ xf:submission> defines submit required for service call. Each submit contains a unique ID.
  • Communication method synchronous/asynchronous
  • functions to be executed before/after communication can be defined. You can set the data to transmit (request or ref) and the data to receive (response or target).
  • ⁇ script> defines global scripts and event functions of components to configure business logic.
  • ⁇ body> includes components, component properties, and screen UI information.
  • screen UI information information about component arrangement and configuration, and properties of each component may be included.
  • the script execution order is external JS file -> local script -> ⁇ initScript> -> onpageload -> ⁇ postSCript>.
  • the script execution sequence is as shown in FIG. 3 .
  • the source compiler, W-Pack can build the screen source in JavaScript.
  • the screen file developed by the development tool 120 is generated in XML format, and W-Pack converts it into a JavaScript file optimized for the browser environment.
  • the file size can be reduced compared to the existing XML format.
  • the security of the source code can be increased through obfuscation.
  • JS files optimized for the web environment have a shorter loading time and less memory usage compared to XML, so the client engine can draw the screen faster in the browser using the JS files.
  • the screen created by the development tool 120 is generated as an XML file, converted into a JS file by W-Pack, and the browser displays the XML file name, but the file actually used when displaying the screen is the JS file.
  • the order of browser calls on the screen is as follows.
  • the user interface platform development system 100 provides various resources for common development. As a highly complete resource that can be used immediately, it can be provided in the form of a thumbnail image. Developers can intuitively check the template and use the resource easily with a click of the mouse without any coding process.
  • Common development resources may include page templates (selectable when creating a screen file), layout templates (selectable when creating a screen file), snippets (provided through thumbnail images in the design system), and the like.
  • the present system may provide a wizard, a manager, an editor, etc. for each stage according to the development process, and provide a common resource suitable for each stage.
  • design consistency can be maintained and common resources can be reused as much as possible.
  • the screen file to be developed can be used in the form of a component. If a specific screen is registered and used as a UDC or project component, it can be reused. When a registered UDC is modified, the changes are collectively reflected, resulting in excellent development productivity and maintenance efficiency.
  • the screen file developed in this system can be used in the form of a component (page component), and all functions of the existing page file are supported. If a page is registered as UDC and used as a common component, a UDC description document can be created based on the comments on the UDC API, and the auto-completion function for the UDC API can be used in the script editor.
  • All pages can be registered as components, and pages registered as components can be used in other screen development with a simple click.
  • FIG. 5 illustrates componentization of a page used for page C by componentizing page A and page B.
  • the design system may display design-related resources including snippets used for common development in the form of thumbnails in the studio (development tool). Developers can easily check the design and use it by adding the design they want to the screen.
  • Resources such as various samples and templates used for common development can be easily used and managed. Resources are classified by type and stored in different folders, and the developer can directly manage the folders. In addition, various resources are reflected in the screen development process and provided in the form of thumbnail images, and the developer can conveniently select and use available resources for each development stage.
  • the studio's design system is a module for organic collaboration between developers and publishers. Design-related resources are displayed as thumbnail images. Developers can intuitively check the design and copy the desired design resource to the screen file with just a click.
  • the screen of the development tool provides the component design space of the WYSIWYG method, so that the selected component can be drawn in the palette view. And you can edit the properties, configuration, and style of the component in the Property, Component, and Style views.
  • All components include id, style, and css attributes. Developers can extend each component style using CSS syntax.
  • the screen file sets the properties, functions, and events of about 80 basic components provided by WebSquare and common development components such as UDC, and provides common design resources (page templates, layout templates, snippets) provided by WebSquare. It can be developed using the development tool 120 .
  • a single page application refers to a web application or site that attempts a single page operation for rapid page switching. Web applications or sites to which SPA is applied do not download repeated HTML codes again, so page movement speed is fast and resource management is possible.
  • Page movement speed is improved, and WebSquare resources (engine files, CSS, image files, etc.) and already loaded external JS files are reused.
  • the user interface platform development system is a multi-experience UI platform, and has the following characteristics.
  • MSA Message Broker a UI architecture for implementing a micro frontend without direct reference between pages, is implemented.
  • all pages are componentized, and component architectures such as project UDC, global component architecture for screen modularization, MSA UDC, and micro front-end support component architecture are implemented.
  • the design system is an intuitive developer/designer collaboration tool for maintaining design consistency.
  • the script editor supports the latest JavaScript syntax, supports auto-completion (IntelliSense), and can provide basic VS Code functions.
  • It also has a performance optimization feature that optimizes the loading speed by upgrading the SPA structure, and improves the user experience performance by improving the initial loading speed of IE through W-Pack and screen browser optimization.
  • FIG. 6 is a diagram showing various server configuration methods
  • FIG. 7 is a diagram for explaining the cross-MSA resource sharing function and the MSA message broker function
  • FIG. 8 is a diagram showing the operation of the cross-MSA sharing structure when wframe is configured.
  • FIG. 9 is a diagram illustrating a data exchange method between page components using a message broker.
  • the server may be configured in a microservices architecture (MSA) method. Even in this case, it is common to configure the web-based UI in a monolithic way.
  • MSA microservices architecture
  • microservices architecture starts to process data and logic on the server side, but in many cases the UI is still handled monolithically (Fig. 6(b)).
  • the application UI is designed according to the micro service. That is, the microservice is deployed on the server, and the monolithic client app has a composite UI generated from the microservice instead of using the microservice (Fig. 6(c)). In this way, microservices can be completed using both logical and visual representations.
  • the micro frontend supports a two-step process.
  • Step 1 Individual UI configuration by microservice using wframe and MSA UDC
  • Step 2 Support to operate different versions of the client engine and project UDC used in the screen area composed of microservices
  • the client engine removes (minimizes) the dependency between the cross-MSA resource sharing module having the function of composing the screen by fetching the necessary resources from multiple servers, and the UI element (Page). ) while exchanging data between services (MSA message broker) may include an MSA component.
  • Main domain Indicates the host address part of the URL of the current page. If the current page is http://store.company.com/dir2/other.html, then store.company.com is the current domain. It is the same value as document.domain which has not been changed by script.
  • Service domain Indicates the host address of the server running the MSA service.
  • cross-MSA resource sharing module it can be implemented to meet the following functional requirements to fetch resources from multiple servers.
  • a page component located in the service domain should be able to be loaded into wframe. If there is no separate setting (msaName, etc.), CSS and JS referenced in the page component located in the service domain must be loaded from the corresponding service domain. If there is no separate setting (msaName, etc.), UDC and wframe loaded from the page component located in the service domain must be loaded in the corresponding service domain. If there is no separate setting (msaName, etc.), the submission called by the page component loaded from the service domain must send a request to the corresponding service domain. If there is no special setting (msaName, etc.), $p.ajax should send a request to the service domain of $p.
  • the MSA UDC in the client configuration file must be loaded from the specified service domain. It should be able to load page components from other service domains or main domains. You should be able to call submission and $p.ajax in other service domains or main domains. In order to minimize source code changes in the development/test/production environment, the addresses of the main domain and service domain should be stored in the client configuration file.
  • the cross-MSA resource sharing structure is as follows.
  • the request domain of the page component and submission is selected according to the following principle.
  • msaName does not exist, the service domain of the parent page is used (msaName is searched from child to parent page).
  • the top-level page uses the same domain as the html file, and is referred to as the main domain.
  • msaName is set, set the service domain by referring to msaServer in config.xml.
  • C sends a request to http://sub1.inswave.com according to B's msaName.
  • Additional HTTP header settings are required for CORS access. Additional information required for the HTTP request header is set by the client engine, but the HTTP response header must be set directly in the project.
  • the cross-MSA resource sharing function settings are as follows.
  • multiple msa can be set under the msa server, and each domain can be set through the msa node.
  • the msaCommon node is a setting to load MSA UDC, a common module provided by the MSA server, and consists of name, resource path, and MSA server name.
  • the msaStylesheet node is a setting to load CSS provided by the MSA server, and consists of a resource path and MSA server name.
  • the css set in msaStylesheet is loaded in the order in which the files are set.
  • the method of downloading the page component (xml) using the cross-MSA resource sharing function is as follows.
  • the resource download method using the cross-MSA resource sharing function is as follows. Download a resource of a type belonging to the list in the following table required for screen rendering.
  • Image processing defined inside CSS is as follows.
  • Sass (Syntactically Awesome StyleSheets) is a CSS pre-processor. It is an extension of CSS to create CSS that is more readable and advantageous for code reuse by compensating for limitations and shortcomings of CSS.
  • SASS support modules can add functionality to W-Pack modules.
  • Cross-MSA resource sharing function supports Ajax communication. You can support directly setting msaName in $p.ajax, submission.
  • $p.ajax Use the service domain that created the $p object (the MSA address used to download the page component, set in /msaServer/msa@baseUrl). However, when executing $p.submission in external JS, the request is delivered to the main domain.
  • the MSA message broker consists of a message channel, a message publisher, a message subscriber, and other APIs.
  • the message channel is registered in the page component to be used as the project UDC. Message channels registered in page components other than project UDCs are ignored.
  • Message publishers and message subscribers can register in any page component.
  • a message subscriber raises an onmessage event.
  • the message publisher can be accessed through the message publisher id, and the send method is provided.
  • the message hub is set in /head/msa/messageChannel of the PCC file and can be registered/modified/deleted in the outline view of the development tool.
  • the page component In order to receive messages from the MSA message broker, the page component must subscribe to the message channel.
  • Message channel subscription information is created in /head/MSA/subscribers/subscribe node, message subscriber id, message channel id (channel id to subscribe to message), message occurrence event (register event handler to handle when a message is generated), etc. properties are required.
  • message publisher id To publish a message to the MSA message broker, you must first register as a message publisher and then publish the message using the message publisher id.
  • Message publisher properties are created in the /head/MSA/publishers/publisher node, message publisher id, message channel id (channel id to subscribe to messages, global variables used when accessing project UDC or MSA UDC and channel registration) Attributes such as used id are combined) are required.
  • the API used to manage the message channel can be accessed in the project UDC and MSA UDC internal scripts that created the message channel.
  • the methods provided are as follows.
  • FIG. 10 is a diagram illustrating the structure of a single page using a page
  • FIG. 11 is a comparison diagram of a traditional web application and a single page web application
  • FIG. 12 is an example of various implementations of a single page application
  • FIG. 13 is an existing web development method It is a diagram showing the screen display process of the single page web application method compared to (Iframe).
  • the browser default memory increases in proportion to the number of screens, and the application memory increases due to overlapping screen resource loading, which may cause errors due to memory leak. Yes (screen whitening).
  • An embodiment of the present invention utilizes a single page application (SPA) to solve this problem. Rather than requesting the entire page to the server after it is loaded in the browser, it is a web application that can be used by changing only the data after loading the entire page for the first time.
  • SPA single page application
  • a screen is developed in the SPA method using the Page function, it operates as a single page (One HTML Page) regardless of the number of screens. There is no redundant loading of screen resources, so fast output and performance are guaranteed, and stable system operation can be possible with less memory usage.
  • the development tool 120 configures the screen file as a single page application type.
  • a screen file distinguishes between static and dynamic resources that make up a web page.
  • Static resources may include browser windows, client engines, common scripts, and common resources.
  • the dynamic resource is various contents included in a web page, and may be a screen resource.
  • the static resource may be set to be downloaded by the first request.
  • the dynamic resource is a part of the content including a part to be displayed on the current screen through partial region rendering, and may be set to be displayed through script execution after the resource is loaded and rendered only when there is a request.
  • Pages is a web technology that loads pages without screen transitions.
  • a page is composed of a single page, and compared to a traditional dynamic web page (Traditional Web), it is possible to provide an improved user experience (UX) by quickly switching between pages, reducing server traffic, and maintaining the flow of site use.
  • UX user experience
  • SPAs single page applications
  • Static resources are downloaded only once. Changes only the content without moving the page, and existing resources can be recycled. Since it is sufficient to request only resources that do not exist, traffic is reduced and loading times are reduced.
  • the SPA screen can be developed using a Page rather than an iframe.
  • the Scope option can solve the problem of duplication of global object names between pages dynamically added using Page.
  • Scope is a function to set the effective scope for all unit screens composing a web page. Because all screens exist in units of scope, objects and scripts included in scope are valid only within scope.
  • IFrames are used in units of frames, but since the browser is reloaded every time IFrames are used, the memory load increases. WFrame operating as an independent unit can replace the existing IFrame, and the developer can improve the overall performance of the web application by minimizing the use of IFrame.
  • Scope related APIs are as follows.
  • $p item main returns the scope object corresponding to the top-level page in the current window.
  • an id selector is received, if a Websquare object with the corresponding id exists on the page, it is converted to the actual id of the Websquare object and then the function is executed.
  • getScope receives the dom object as an argument and returns the scope object of the page where the dom is located.
  • getFrame receives the dom object as an argument and returns the WFrame id of the page where the dom is located.
  • getWindow returns the Scope object of the WFrame.
  • Objects in the WFrame screen can be accessed through the corresponding object.
  • getWindow returns the Scope object of the tab corresponding to idx.
  • idx must be a valid tabID or tabIndex value.
  • getFrame returns the frame object (iframe or wframe) of the window corresponding to the windowId.
  • getWindow returns the Scope object of WFrame. To access an object in the wframe screen, you must call this function.
  • getSrc returns the address of the page currently included in the WFrame. setSrc dynamically changes the WFrame screen to the screen corresponding to the url. remove completely removes the wframe.
  • Page When Page is applied, improved performance can be obtained by reducing the client's memory usage, which is used for browser window creation, Websquare engine, common script, and loading and execution of common resources.
  • the drawing compares the loading method in the iframe mode and the loading method in the Page (WFrame) mode.
  • the screen execution process performed on the client includes creating a browser window (step 1), loading the Websquare engine (step 2), running the Websquare engine (step 3), loading Websquare resources (step 4), and loading a common script (step 5). ), common script execution (step 6), common resource loading (CSS) (step 7), screen resource loading (step 8), screen rendering (step 9), and screen script execution (step 10) are sequentially included.
  • the screen loading speed may be improved and memory usage may be reduced.
  • FIG. 14 is a diagram showing the W-Pack execution structure
  • FIG. 15 is a detailed configuration diagram of the screen source conversion module.
  • the source compiler, W-Pack is a screen source conversion module that bundles and transpiles screen source (XML) into JavaScript. Script conversion, obfuscation, and minimization functions can be provided so that the WebSquare engine can draw the screen using JavaScript.
  • the screen source conversion module 1500 generates a JS file including JSON having the same information as XML, which is a screen source, and changes it so that the WebSquare engine draws the screen while parsing the JSON.
  • the screen source conversion module 1500 traverses the XML node and changes the XML node to the JSON format.
  • the screen source conversion module 1500 may include a monitor unit 1510 for monitoring a screen source to be converted, and a compiler unit 1520 for compiling a screen source to be converted into JavaScript. have.
  • the monitor unit 1510 includes a monitor such as a file input/output monitor, an SVN monitor, and a GIT monitor, an asynchronous queue in which a screen source monitored through the monitor is queued, and a worker to which a screen source of the asynchronous queue is delivered. .
  • the worker transmits an XML-type screen source to the compiler unit 1520 .
  • the compiler unit 1520 includes an XML-JS converter that converts an XML file into a JS file, a tree generator (AST) that generates an abstract syntax tree, a validator that validates the generated abstract syntax tree, and If successful, the optimizer optimizes the JS file, the obfuscator applies code obfuscation to the optimized JS file, and minimizes the obfuscated result through compression and outputs it as JavaScript. Includes a Minifier.
  • FIG. 16 is an example screen of a resolution setting screen and a grid layout manager in the layout manager
  • FIG. 17 is an exemplary diagram of each device tab of the layout manager
  • FIG. 18 is a flowchart of a screen development method performed in the layout manager.
  • the system of this embodiment particularly the development tool 120, includes a layout manager for implementing a responsive/adaptive web. You can set the resolution optimized for your business system and choose from various types of layout templates.
  • the layout manager supports to easily compose the layout through the grid layout component. It can support screen editing and multiple resolutions using the CSS3 grid layout standard so that developers can easily edit the screen while complying with web standards.
  • Media information may include resolution.
  • the resolution can be set in the layout component file. It can be implemented as a multi-design tab supporting the layout component specified in the page.
  • Layout information may be stored in a page component file, and a layout file and area to be used for screen rendering may be designated.
  • WebSquare page component supports screen editing in consideration of device resolution and page component size by creating design tabs as many as the number of layout items defined in the layout information.
  • the layout manager creates a device tab corresponding to the number of devices to be developed.
  • Devices to be screen development targets may be individually assigned to each of the device tabs.
  • the arrangement of components to be applied to the work system may be displayed as if it were actually displayed on the screen of the device in accordance with the resolution of the device assigned to the device tab. Developers can identify and correct errors in the screen composition of the work system currently being developed through the screen of the device tab.
  • the components implemented on the screen of all device tabs have the same identity. However, there is a difference in the way of expression depending on the resolution of the device.
  • the layout manager may modify the layout of any component on the screen of the first device tab. In this case, such modifications may be applied in conjunction with other device taps (second to Nth device taps) in the same manner.
  • the screen does not maintain the intended layout due to different supported resolutions in one or more of the other device tabs. There may be problems with the configuration.
  • the developer can check the screens of each tab and modify them one by one while selecting each device tab sequentially.
  • a problem may occur in the first device tab that has been modified without any problems before.
  • the layout manager automatically applies the same change to other device tabs (step S1810).
  • step S1820 it is determined whether a problem occurs in one or more of the other device taps.
  • the device tabs of (a), (c), and (d) all components are arranged and displayed without any problem, but in the device tab of (b), four blocks arranged in the center of the screen are not aligned. It can be confirmed that there is In this case, it can be determined that a problem has occurred in the device tab of (b).
  • the possibility of occurrence of a problem in relation to the component to be changed in the screen of the first device tab viewed by the developer may be displayed in a designated manner to be recognized (step S1830).
  • the specified method may be to display the corresponding component in a pre-specified color (eg, red), make the corresponding component blink, or cause the size of the corresponding component to repeat expansion and contraction.
  • the developer can recognize that a problem may occur in the layout in other devices other than the first device in relation to the component currently being edited, and can immediately and collectively correct the problem (step S1840).
  • FIG. 19 is a configuration diagram of a design system
  • FIG. 20 is an example diagram of a snippet guide and template use.
  • the design system is a module for strengthening collaboration between developers and designers. It is a system in which design style rules and guidelines required to maintain design consistency in web and services and commonly used colors, fonts, layouts, and UI components are gathered.
  • the design system contains various resources needed by relevant stakeholders such as planners, designers, and developers. Among them, there are elements used by all stakeholders, such as design patterns and design guides, but by providing elements such as CSS, components, layouts, and templates that are mainly used by developers and publishers, development productivity can be further improved.
  • CSS is a common CSS required to maintain design consistency, and is provided in the form of CSS or SCSS.
  • Components provide source codes such as HTML, web-components, React, and Vue like buttons and input forms.
  • Layout provides source code related to screen layout such as Flex, Grid, and Stack. Templates provide source code related to frequently used screen types.
  • the design system module 1900 collects functions necessary for publishers and developers to develop WebSquare while maintaining design consistency.
  • the design system module 1900 is a function of WebSquare Studio to help develop applications.
  • the design system module 1900 is composed of elements of a design system view, common CS, UDC, snippets, and templates.
  • the design system view supports to express UDC and snippet related parts by embedding them in WebSquare Studio.
  • Design System View is a built-in web browser that can load web pages with visual images and descriptions by visually representing UDC and snippets. You can save html and related resources with visual images and descriptions of UDCs and snippets in your project and have them loaded into the design system view.
  • the design system view is a dependent function of the Eclipse project, and the design system view can be displayed using the resources defined in the project including the currently active WebSquare editor.
  • the resources in the design system view associated with file A are the same as when editing file A (scroll position, page Link movement, etc.) can be kept as it is.
  • the web page for the design system can exist locally or remotely.
  • the snippet guide document is converted into a web page for the design system, and can be provided to be displayed in the design system view when UI common templates and basic template support are set.
  • the design system's resources can be downloaded to the studio.
  • Web and Eclipse (RCP) communication for the design system uses JSON-formatted messages.
  • the msgType of the request message called to the RCP in the web page of the design system view is "REQUEST”, and the function to be processed in the RCP is defined in the action. Additional information for each type of action is delivered using the req object. All requests can be made asynchronously.
  • the msgType of the response message delivered from the RCP to the web page of the design system view is "RESPONSE", the action uses the value delivered when requested, and the detailed response message is delivered using the res object.
  • Snippets are fragment templates, which can be used to maximize code reuse to improve development productivity and maintenance efficiency. By registering and recycling frequently used or complex source codes in advance, developers can prevent duplicate development and standardize source codes to improve development convenience and development productivity.
  • a developer UI standard guide (Snippets Guide) for a screen that a developer wants to develop may be displayed.
  • Content group It is an area for each section within the content area.
  • the development tool 120 allows the developer to view the screen being developed through the design editor 1910 .
  • the design editor 1910 is connected to the design system view 1920 .
  • the design system view 1920 may include functional modules such as search, bookmark, preview, snippet, template, UDC, CSS, FONT, and COLOR.
  • the design system view 1920 may inquire design standards and resources from the connected design system server 1930 .
  • the design system view 1920 allows the design based on the design standard and resources retrieved from the design system server 1930 to be applied to the screen being edited in the design editor 1910 .
  • Computer-readable media can be any available media that can be accessed by a computer and includes both volatile and nonvolatile media, removable and non-removable media.
  • Computer-readable media may include computer storage media.
  • Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
  • the above-described screen development method may be executed by an application basically installed in the terminal (which may include a program included in a platform or operating system basically mounted in the terminal), and the user may use an application store server, an application, or a corresponding service. It may be executed by an application (ie, a program) installed directly on the master terminal through an application providing server such as a web server related to the .
  • the screen development method described above may be implemented as an application (ie, a program) installed by default in a terminal or directly installed by a user and recorded in a computer-readable recording medium such as a terminal.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Computational Linguistics (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Artificial Intelligence (AREA)
  • Human Computer Interaction (AREA)
  • Stored Programmes (AREA)

Abstract

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

Description

소스 컴파일러를 구비한 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법
본 발명은 소스 컴파일러를 구비한 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법에 관한 것이다.
디지털 트랜스포메이션(Digital Transformation)은 디지털 기술을 사회 전반에 적용하여 전통적인 사회 구조를 혁신시키는 것이다.
일반적으로 기업에서 사물인터넷(IoT), 클라우드 컴퓨팅, 인공지능(AI), 빅데이터 솔루션 등 정보통신기술(ICT)을 플랫폼으로 구축·활용하여 기존 전통적인 운영 방식과 서비스 등을 혁신하는 것을 의미한다.
모든 비즈니스 프로세스를 디지털화해 혁신하기 위해서는 다음과 같은 2가지 필수요건이 있다.
(1) 시장의 요구에 신속한 대응 및 적극적인 신기술 활용
(2) 다양한 디바이스(Mobile, Wearable, IoT)를 활용한 비즈니스 모델 혁신
신기술(AI, IoT, Cloud, BigData, AR/VR, Mobile)을 적용하고, 오픈소스 생태계를 활용하며, 신속한 개발(Low Coding)에 대응하기 위해서는 웹, 모바일, 웨어러블 디바이스, 앱 개발 등 모든 개발 활동을 통합할 수 있는 다중경험 개발 플랫폼(MXDP, Multiexperience Development Platforms)이 요구된다.
본 발명은 원 소스 멀티 유즈(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는 파일이 설정된 순서에 따라 로드된다.
Figure PCTKR2022004057-appb-I000001
Figure PCTKR2022004057-appb-I000002
교차 MSA 자원 공유 기능을 이용한 페이지 컴포넌트(xml)의 다운로드 방법은 다음과 같다.
Figure PCTKR2022004057-appb-I000003
교차 MSA 자원 공유 기능을 이용한 자원의 다운로드 방법은 다음과 같다. 화면 렌더링에 필요한 다음 표의 목록에 속하는 유형의 자원을 다운로드한다.
Figure PCTKR2022004057-appb-I000004
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에 접근할 수 있다. 제공되는 메소드는 다음과 같다.
Figure PCTKR2022004057-appb-I000005
도 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)에서 편집 중인 화면에 적용되게 한다.
전술한 화면 개발 방법은, 컴퓨터에 의해 실행되는 애플리케이션이나 프로그램 모듈과 같은 컴퓨터에 의해 실행가능한 명령어를 포함하는 기록매체의 형태로도 구현될 수 있다. 컴퓨터 판독 가능 매체는 컴퓨터에 의해 액세스될 수 있는 임의의 가용 매체일 수 있고, 휘발성 및 비휘발성 매체, 분리형 및 비분리형 매체를 모두 포함한다. 또한, 컴퓨터 판독 가능 매체는 컴퓨터 저장 매체를 포함할 수 있다. 컴퓨터 저장 매체는 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현된 휘발성 및 비휘발성, 분리형 및 비분리형 매체를 모두 포함한다.
전술한 화면 개발 방법은, 단말기에 기본적으로 설치된 애플리케이션(이는 단말기에 기본적으로 탑재된 플랫폼이나 운영체제 등에 포함된 프로그램을 포함할 수 있음)에 의해 실행될 수 있고, 사용자가 애플리케이션 스토어 서버, 애플리케이션 또는 해당 서비스와 관련된 웹 서버 등의 애플리케이션 제공 서버를 통해 마스터 단말기에 직접 설치한 애플리케이션(즉, 프로그램)에 의해 실행될 수도 있다. 이러한 의미에서, 전술한 화면 개발 방법은 단말기에 기본적으로 설치되거나 사용자에 의해 직접 설치된 애플리케이션(즉, 프로그램)으로 구현되고 단말기 등의 컴퓨터로 읽을 수 있는 기록매체에 기록될 수 있다.
상기에서는 본 발명의 실시예를 참조하여 설명하였지만, 해당 기술 분야에서 통상의 지식을 가진 자라면 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

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항에 있어서,
    상기 개발도구는 상기 화면 파일을 단일 페이지 애플리케이션 타입으로 구성되게 하는 것을 특징으로 하는 사용자 인터페이스 플랫폼 개발 시스템.
PCT/KR2022/004057 2021-03-23 2022-03-23 소스 컴파일러를 구비한 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법 WO2022203387A1 (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR10-2021-0037429 2021-03-23
KR20210037429 2021-03-23
KR10-2022-0035234 2022-03-22
KR1020220035234A KR20220132457A (ko) 2021-03-23 2022-03-22 소스 컴파일러를 구비한 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법

Publications (1)

Publication Number Publication Date
WO2022203387A1 true WO2022203387A1 (ko) 2022-09-29

Family

ID=83397732

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/004057 WO2022203387A1 (ko) 2021-03-23 2022-03-23 소스 컴파일러를 구비한 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법

Country Status (1)

Country Link
WO (1) WO2022203387A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116843879A (zh) * 2023-07-18 2023-10-03 数元科技(广州)有限公司 一种跨引擎vr编辑场景生成方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120042291A (ko) * 2010-10-25 2012-05-03 주식회사 엠오투커뮤니케이션 모바일 웹페이지를 효율적으로 개발하기 위한 크로스 플랫폼 솔루션 및 크로스 플랫폼 모바일 소스 생성 시스템
KR20140055004A (ko) * 2012-10-30 2014-05-09 주식회사 케이티 웹 페이지를 생성하는 장치 및 방법 그리고, 서버
KR20150078840A (ko) * 2013-12-31 2015-07-08 서경대학교 산학협력단 모바일 유저인터페이스 개발을 위한 통합 플랫폼을 기록한 저장 매체, 이를 구현하는 플랫폼 제공방법, 및 이를 제공하는 시스템
KR101807897B1 (ko) * 2010-04-15 2017-12-11 제트아이에이치 코프. 크로스―플랫폼 어플리케이션 프레임워크
KR102124499B1 (ko) * 2018-11-30 2020-06-19 주식회사 코레토 클라우드 서비스 기반의 어플리케이션 서비스 제공 방법, 장치 및 컴퓨터-판독가능 매체

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101807897B1 (ko) * 2010-04-15 2017-12-11 제트아이에이치 코프. 크로스―플랫폼 어플리케이션 프레임워크
KR20120042291A (ko) * 2010-10-25 2012-05-03 주식회사 엠오투커뮤니케이션 모바일 웹페이지를 효율적으로 개발하기 위한 크로스 플랫폼 솔루션 및 크로스 플랫폼 모바일 소스 생성 시스템
KR20140055004A (ko) * 2012-10-30 2014-05-09 주식회사 케이티 웹 페이지를 생성하는 장치 및 방법 그리고, 서버
KR20150078840A (ko) * 2013-12-31 2015-07-08 서경대학교 산학협력단 모바일 유저인터페이스 개발을 위한 통합 플랫폼을 기록한 저장 매체, 이를 구현하는 플랫폼 제공방법, 및 이를 제공하는 시스템
KR102124499B1 (ko) * 2018-11-30 2020-06-19 주식회사 코레토 클라우드 서비스 기반의 어플리케이션 서비스 제공 방법, 장치 및 컴퓨터-판독가능 매체

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116843879A (zh) * 2023-07-18 2023-10-03 数元科技(广州)有限公司 一种跨引擎vr编辑场景生成方法及系统
CN116843879B (zh) * 2023-07-18 2024-01-19 数元科技(广州)有限公司 一种跨引擎vr编辑场景生成方法及系统

Similar Documents

Publication Publication Date Title
WO2020044290A1 (ko) 특허 문서 작성 장치, 방법, 컴퓨터 프로그램, 컴퓨터로 판독 가능한 기록매체, 서버 및 시스템
WO2019100638A1 (zh) 数据同步方法、装置、设备及存储介质
WO2014116005A1 (ko) 애플리케이션 개발 환경 제공 방법 및 그 장치
WO2011122724A1 (ko) 아밥 소스코드의 코드 검사를 수행하는 코드검사 수행시스템
WO2010087635A2 (en) Method and apparatus for processing user interface composed of component objects
WO2014025186A1 (en) Method for providing message function and electronic device thereof
WO2022203387A1 (ko) 소스 컴파일러를 구비한 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법
WO2013017037A1 (zh) 一种soc芯片的验证方法及系统
KR20220132455A (ko) 마이크로 서비스 아키텍처를 가지는 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법
WO2018149190A1 (zh) 组件调试方法、装置、设备和计算机可读存储介质
WO2019075973A1 (zh) 应用程序的测试方法及装置
WO2020218870A1 (en) Electronic apparatus and method for controlling thereof
EP2443539A2 (en) Widget activation and communication method
WO2017111197A1 (ko) 학습 분석에서 빅데이터 시각화 시스템 및 방법
WO2022203381A1 (ko) 단일 페이지 애플리케이션 방식의 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법
WO2022203392A1 (ko) 디자인 시스템을 구비한 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법
WO2022203377A1 (ko) 마이크로 서비스 아키텍처를 가지는 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법
WO2022203391A1 (ko) 반응형 또는 적응형 웹 구현을 위한 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법
WO2017023049A1 (en) Electronic device and server related to rendering of web content and controlling method thereof
WO2019080401A1 (zh) 脚本语句转换方法、装置及计算机可读存储介质
WO2018105804A1 (ko) Bpm 기반의 iot diy 시스템 및 이의 구현방법
WO2015119361A1 (ko) 클라우드 스트리밍 서비스 시스템, 클라우드 스트리밍 서비스 제공 방법 및 이를 위한 장치
WO2021010558A1 (ko) 단말기, 이의 제어 방법 및 상기 방법을 구현하기 위한 프로그램을 기록한 기록 매체
WO2011111926A2 (ko) 통신 단말기의 웹 기반 사용자 인터페이스 구현 장치 및 그 방법
WO2015126043A1 (ko) 광고 표시 방법 및 광고 제공 방법, 그리고 이에 적용되는 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22776087

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18551873

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22776087

Country of ref document: EP

Kind code of ref document: A1