MODEL-DRIVEN ARCHITECTURE FOR USER-CENTERED DESIGN

BACKGROUND

Businesses may increase profits by maximizing quality while at the same time minimizing cost, risk, time-to-market, and time-to-deliver. When developing solutions for customers, businesses may consider factors such as multiple tenants, client security systems, suppliers, geographies, and delivery models.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level diagram of an example computer system which may be implemented for specifying a model-driven architecture for user-centered design.

FIG. 2 is a block diagram of an example modeling language for specifying a model-driven architecture for user-centered design.

FIG. 3 is a block diagram of an example subject-verb-object to specify a UX meta-language.

FIG. 4 is a block diagram of an example runtime platform for executing a model-driven architecture far user-centered design.

FIG. 5 is an illustration showing operation of an example tool chain for service design to execution which may be implemented for specifying a model-driven architecture for user-centered design.

FIG. 5A shows an example system to specify a model-driven architecture for user-centered design.

FIG. 5B shows another example system to specify a model-driven architecture for user-centered design.

FIGS. 6 and 6A are flowcharts illustrating example operations which may be implemented for specifying a model-driven architecture for user-centered design.

DETAILED DESCRIPTION

Businesses constantly face the need to increase profits by maximizing quality while at the same time minimizing cost, risk, time-to-market, and time-to-deliver. Meeting these needs has become especially challenging because of the complexities that must be addressed. These complexities include multiple tenants, client security systems, suppliers, geographies, and delivery models. In addition, solutions have to function together to handle: (a) the complexities of individual solutions; (b) those that arise from interacting information sources and destinations each with their own data representations; (c) composite user interfaces; and (d) variations of system interface protocols (e.g., web services, language-specific APIs, extract/transform/load, real-time, batch). Further, challenges include the need for agility, scalability, and availability. Failure to address these challenges can result in multiple failures in development projects, client contracts, and service line offerings and portfolios.

Management of the design, build, and run of composite, role-based, service-enabled user experiences is complicated. This issue is exacerbated when considering the full range of edge device options in use today, such as web, mobile, and fat client applications. Current approaches rely heavily on manual processes which can cause multiple problems, such as failures to realize opportunities for re-use, delays in producing executable code once designs are complete, and inconsistencies of the patterns used to implement and deploy user interface code. In addition to these issues, current approaches make changing user interface solutions difficult. These problems negatively impact the technical quality and business value of user experience solutions, and result in poorer user interfaces that reduce the productivity and degrade the overall experiences of end users.

Application development has typically utilized a wide variety of development tools applied in an ad hoc manner, for example creating wireframes with whatever design tool each developer prefers. These designs then have to be manually coded, with design patterns for the code left to the developers. This approach causes a lot of unnecessary variability between developers and even between applications by the same developer, which increases the complexity of the deployment, run, and maintenance of application portfolios. This approach also fails to realize the benefits of reusing existing user interface components. Even when following good design practices, the result is an application developed within the context of a specific development environment of a particular run-time platform.

A model-driven tool chain is disclosed that connects business architecture to the design of services and to executable composite services. By standardizing design patterns and automating configuration generation, the systems and methods disclosed herein enable service providers to focus on the value-creating aspects unique to the end-user domain. More generally, systems and methods are disclosed herein for pattern-based, model-driven tool chains that eliminate the manual build phase for user-centered design. The systems and methods significantly reduce cost and implementation time, and dramatically increase quality of the product.

In an example, a method includes defining a meta-language for creating user-centered designs. The method also includes capturing a user-experience for a specified domain. The method also includes exporting a platform-independent representation of the user-centered design. The method also includes transforming the platform-independent representation into a platform-specific representation of the user-centered design that is executable on a targeted runtime platform.

In an example, a system includes a data capture tool to define a meta-language for creating user-centered designs, the data capture tool to capture user-experiences for a specified domain and export a platform-independent representation of the user experiences. The system also includes a transformation tool to transform the platform-independent representation into platform-specific representations of the user-centered design that are executable on targeted runtime platforms.

In an example, a computer program product is embodied as computer-readable instructions stored on non-transient computer-readable media and executable by a processor to define a meta-language for specifying user-centered designs, generate a platform-independent representation of the user-centered designs, and transform the platform-independent representation into platform-specific representations of the user-centered designs that are executable on targeted runtime platforms.

It can be seen that the systems and methods disclosed herein implement a design-to-execution tool chain for service integration, following a model-driven meta-pattern, which defines a platform-independent design, from which platform-specific implementations can be generated. The systems and methods are transformative to the application design and development space for user-centered designs.

The systems and methods described herein formalize the design capture, encourage reuse, automatically generate the code with standard design patterns, and simplify deployment and maintenance of a standard user interface portfolio. In addition, the end-product is platform independent and can be used to generate code which is executable on multiple operating systems and devices.

Before continuing, it is noted that as used herein, the terms “includes” and “including” mean, but are not limited to, “includes” or “including” and “includes at least” or “including at least.” The term “based on” means “based on” and “based at least in part on.”

FIG. 1 is a high-level diagram of an example computer system 100 which may be implemented for specifying a model-driven architecture for user-centered design. System 100 may be implemented with any of a wide variety of computing devices, such as, but not limited to, stand-alone computers and computer servers, to name only a few examples. Each of the computing devices may include memory, storage, and a degree of data processing capability at least sufficient to manage a communications connection either directly with one another or indirectly (e.g., via a network). At least one of the computing devices is also configured with sufficient processing capability to execute the program code described herein.

In an example, the system 100 may include a client interface 110 for a user 101 at client computing device 120 to access a tool chain 130 for service design to execution. It is noted that the client interface 110 may access the tool chain 130 via a network 140, or may be directly connected. In addition, the computing devices of the client interface 110 and the tool chain 130 are not limited to any particular type of devices.

Prior approaches utilize a tiered approach, sometimes tightly aligned with the developer's proprietary data modeling methodologies. The systems and methods described herein for managing a user experience is part of a more general approach to managing service-centric composite solutions. This approach decouples layers of the architecture to separate concerns, loosely coupling user experiences, automated workflows, composite service orchestrations, conceptual service integrations, and point solution service implementations.

In an example, the system 100 includes program code 150 to implement the tool chain 130. In an example, the program code 150 may be executed by any suitable computing device (e.g., client computing device 120 and/or server computer 160).

The system 100 combines model-driven architecture and user-centered design methodologies to solve traditional problems of managing user experience solutions according to a platform-independent meta-language for specifying user-centered designs. The methodology captures user experience designs in a formal representation meta-language, then applies a fixed tool chain to generate and package the code that implements these designs into the variety of edge device solutions. Continuous delivery methods can be used to deploy these solutions, including setting up authorization delegation support and service access control, as well as the ongoing service management of the collection of user experience solutions.

The system 100 is general and covers all aspects of the management of design, build, and run of composite user experience solutions. The approach is flexible in that it can be used to build solutions for a variety of user interface frameworks running on any end user devices that implement these frameworks. For example, code can be generated to run on traditional operating systems, and/or can be incorporated in a full Services Composition Framework.

It is noted that the operations described herein may be executed by program code residing on any number and/or type of computing device. The components shown in FIG. 1 are provided only for purposes of illustration of an example operating environment, and are not intended to limit implementation to any particular system. In addition, it is contemplated that the execution of program code may be performed on a separate computing system (e.g., a server bank) having more processing capability than an individual computing device.

In an example, the program code 150 may be implemented as machine-readable instructions (such as but not limited to, software or firmware). The machine-readable instructions may be stored on a non-transient computer readable medium 165, and are executable by one or more processors (e.g., of the server computer 160) to perform the operations described herein. The program code 150 may include application programming interfaces (APIs) and related support infrastructure to implement the operations described herein.

In an example, the program code 150 executes the function of a model-driven meta-pattern. The model-driven meta-pattern defines a platform-independent design, from which platform-specific implementations can be generated. In an example, the program code includes self-contained modules to implement a design-to-execution tool chain for service integration. These modules can be integrated within a self-standing tool, or may be implemented as agents that run on top of or interact with existing program code. In FIG. 1, the program code 150 is shown as it may include an architecture methodology module 151, a modeling language module 152, a modeling tools module 153, a configuration generator 154, and a runtime platform 155.

The architecture methodology module 151 may be executed with the modeling language module 152 to define a user experience (UX) meta-language. For example, the UX meta-language may be specified in a table utilizing subjects (of verbs), verbs, and objects (of verbs) to represent relationships between the elements in a user experience, as shown in FIG. 3.

The modeling tools module 153 may include a data capture tool. In an example, the data capture tool may be implemented in a spreadsheet with a meta-language and data entry template. The data capture tool receives user input defining objects and roles of those objects.

The configuration generator 154 may be executed to define the user experience (UX) behavior using the UX meta-language and data received by the data capture tool. The configuration generator 154 takes as input the data from the data capture tool, and based on the UX meta-language, outputs a platform-independent representation (e.g., a diagram and/or XML document) of the objects and roles of those objects.

In an example, the configuration generator 154 may implement a transformation tool. The transformation tool receives the platform-independent representation as input, and transforms the platform-independent representation into an executable for a targeted runtime platform (e.g., compiled application code, or a configuration file). The runtime platform 155 may deploy the executable in a target environment.

The program code described generally above can be better understood with reference to FIGS. 2-6A and the following discussion of various example functions. It is noted, however, that the operations described herein are not limited to any specific implementation with any particular type of program code.

FIG. 2 is a block diagram of an example modeling language 200 for specifying a model-driven architecture for user-centered design. In an example, the modeling language may be implemented as a Role-Based Domain Architecture (RDA) methodology. The RDA methodology is a formal and disciplined architecture methodology for modeling service-oriented architectures, separating the design space into layered viewpoints that are relevant to various domains of concerns. The RDA methodology provides the ability to assemble composite, user-centered, designs from a wide array of available services.

The RDA methodology may incorporate new modeling “languages,” incorporate and synthesize standard modeling “languages” (e.g., BPEL, BPMN, XSD, XSL, and WSDL), and introduce new modeling languages, e.g., authoriZation-Based Access Control (ZBAC), User Centered Design (UCD), and the Conceptual Services Implementation Platform (CSIP). In an example, the RDA methodology includes domains (e.g., the implementation requirements) and associated layers for modeling the domains (e.g., service implementation).

The RDA methodology can be implemented as a meta-model modeling language 200 that defines specific object types 210, relationship types 220, and the relationships 230 between layers.

FIG. 3 is a block diagram of an example subject 310, verb 320, and object 330, to specify a UX meta-language. Example subjects 310 may include a User Role (which may include an Employee and a Manager in a human resources example). Example objects 330 may include an Action (which may include a Submit Promotion Request in an HR example). Example verbs 320 may include Performs, which defines a relationship between a User Role subject 310 and an Action object 330. This standardization of the user centered design meta-language makes it possible to perform automated traceability and consistency checking, and is a first step in establishing executable user-centered designs.

In an example, the methodology may include a workflow. A “workflow” is a set of tasks (manual and/or automated), and the logic and/or sequencing between the tasks. By way of example, a workflow implemented by a human resources (HR) department to promote employees may include the manager submitting a promotion request, and the manager's manager reviewing and approving the promotion request.

The methodology may also include orchestration of a collection of references to individual services and the logic by which they are collected. In the HR example, this may include creating a new case of employee promotion workflow, including the details of the employee in question, and then executing the employee promotion (after approval).

The methodology may also include implementing the user experience. The user experience may include a set of user screens and activities that link the screens for carrying out a manual task in a workflow. In the HR example, the employee's manager may utilize a manager self-service screen (e.g., to select “promote employee”), a manager select employee screen, and a confirm employee selection screen (e.g., for entering a new job code and reason for promotion).

The methodology may gather input for each manual task in a workflow to define the user experience for that task. This information may then be implemented to generate an executable user experience design.

FIG. 4 is a block diagram of an example runtime platform 400 for executing a model-driven architecture for user-centered design. The runtime platform 400 may include modules 410-440.

The target runtime platform 400 is a general purpose system configured to deploy the executable generated to implement the user experience design. In an example, the target runtime platform 400 is a domain-independent, configuration-driven environment designed to execute the composite service designs produced above.

By way of illustration, the runtime platform 400 may be a Service Composition Framework (SCF) Runtime Platform. The runtime platform 400 may include APIs such as a User Experience Manager 410, an Orchestration Manager 420, an Integration Manager 430, and a Service Implementation API 440. In an example, an Integration Manager 430 may also be provided for use on a standard operating platform. During operation, the runtime platform 400 accepts the executable implementation of the user experience design to be executed by the User Experience Manager 410.

FIG. 5 is an illustration showing operation of an example tool chain 500 for service design to execution which may be implemented for specifying a model-driven architecture for user-centered design. For purposes of illustration, the tool chain described with reference to FIG. 5 provides extract-transform-load capability from the domain model (e.g., RDA-based) to a Runtime Platform (e.g., SCF).

In an example, the tool chain 500 may be implemented as a system having computer-readable instructions stored on non-transient computer-readable media and executable by a processor to specify a model-driven architecture for user-centered design. In an example, the architectural type may be selected from Business Contextual Architecture (BCA), Conceptual Service Architecture (CSA), Logical Design Architecture (LDA), Physical Technology Architecture (PTA), Workflow Architecture, User Experience Architecture, and Orchestration Architecture.

In an example, the tool chain 500 may include a data capture tool 510 to define a domain model 520 of the user centered design architectural type. The data capture tool 510 defines a user experience (UX) meta-language and also identifies object types and relationship types for the user centered design architectural type.

By way of illustration, QuickRDA is a lightweight, spreadsheet-based tool for capturing domain models. It includes data capture spreadsheets, diagram generation using GraphViz, and an API allowing model data to be exported for downstream uses such as reporting or configuration and code generation.

The data capture tool 510 may collect data in any suitable form, such as a generated diagram 530. Data from the generated diagram 530 may be exported to a platform-independent representation 535 of the domain model. The platform-independent representation 535 of the domain model may be an XML representation,

The platform independent-representation 535 is input to a transformation tool 540 to undergo a transformation.

In an example, the transformation tool 540 may be implemented as a QuickRDA plugin to extract model data into XML format. The transformation tool transforms the XML file into configuration files, XSD, and XSL for the Integration Manager (430 in FIG. 4), and for the workflow in the Orchestration Manager (420 in FIG. 4).

The transformation tool 540 transforms the platform-independent representation 535 of the domain model 520 into an executable 545 (e.g., compiled code or configuration file) for a targeted runtime platform 550. In an example, the executable 545 may be a custom code implementation for a SCF runtime platform 550. The runtime platform 550 can process the executable 545 to enable the domain model 520.

This approach eliminates the manual build phase for any user-centered design to which the methodology is applied, significantly reducing cost and implementation time, and dramatically increasing quality. These benefits come from treating solution designs as configuration data for application programs. The methodology can be applied to application modernization, as well as application development and maintenance, and fundamentally changes the way application products are developed.

In an example, a given user interface referred to herein as a user-centered design, assumes a single Cascading Style Sheet (CSS) template and a small number (5 to 10) of screen templates, each with a defined screen layout and navigation patterns. To illustrate, consider a simplified version of a user experience meta-language. The meta-language has the following classes: User Role, Key User Task, Screen, Screen Template, Screen Component, Action, and Operation. A Screen can be a screen in a mobile application or a page in a web application.

The following example is provided for purposes of illustration. In this example, a meta-language defines the following relationships:

TABLE 1

Subject
Verb
Object

User Role
Performs
Key User Task

Key User Task
Has Screen
Screen

Screen
Uses Screen Template
Screen Template

Screen
Has Screen Component
Screen component

Screen Component
Has Action
Action

Action
Goes To
Target Screen

Action
Calls
Operation

In an example, spreadsheet-based user-centered design capture tool may be implemented to define the user experience for an employee manager. The capture tool may be implemented as a Java® plug-in that enables a meta-language template using hidden rows and a configuration file. Data entered in a row of the table determines the specific instances of the relationships in Table 1.

In an example, the Employee Manager performs the following Key User Tasks: Login, Manage Employees, Request Employee Promotion, Receive Notification of Denied Promotion, Rework Promotion Request, and Notify Employee of Promotion. Each of these Key User Tasks has one or more user screens. For example, the Request Employee Promotion may have the following screens: Select Employee Screen, Select New Job Code Screen, Review & Submit Promotion Request Screen, and Promotion Request Confirmation Submit. Screen. Each of these Screens may have several actions which call various HTTP GET and POST Operations, and then go to the specified Target Screens. From this formal design specification the tool chain described herein can generate an Employee Manager's User Interface.

FIG. 5A shows an example system 505 to specify a model-driven architecture for user-centered design. In an example, the system 505 has computer-readable instructions stored on non-transient computer-readable media and executable by a processor. The system 505 includes a data capture tool 510 to define 515a a meta-language for user-centered design. The data capture tool may also capture 515b a user experience design for a specified domain and export a platform-independent representation 535 of the user experience design. A transformation tool 540 may transform the platform-independent representation 535 into a platform-specific representation 545 of the user experience design that is executable on a targeted runtime platform 550.

FIG. 5B shows an example computer program product 560 to specify a model-driven architecture for user-centered design. In an example, computer program product 560 may be embodied as computer-readable instructions stored on non-transient computer-readable media and executable by a processor. When executed by a processor, the computer-readable instructions define 561 a meta-language for user-centered design. The computer-readable instructions also capture 562 a user experience design. The computer-readable instructions also generate 563 a platform-independent representation of the user experience design. The computer-readable instructions also transform 564 the platform-independent representation of the user experience design into a platform-specific representation of the user experience design that is executable on a targeted runtime platform.

Before continuing, it should be noted that the examples described above are provided for purposes of illustration, and are not intended to be limiting. Other devices and/or device configurations may be utilized to carry out the operations described herein.

FIGS. 6 and 6A are flowcharts illustrating example operations which may be implemented for specifying a model-driven architecture for user-centered design. Operations 600 and 650 may be embodied as logic instructions on one or more computer-readable media. When executed on a processor, the logic instructions cause a general purpose computing device to be programmed as a special-purpose machine that implements the described operations. In an example, the components and connections depicted in the figures may be used.

In the example shown in FIG. 6, operation 610 includes defining a meta-language for user-centered design. Operation 620 includes capturing a user-experience for a specified domain. Operation 630 includes exporting a platform-independent representation of the use entered design. Operation 640 includes transforming (e.g., by applying a tool chain) the platform-independent representation into a platform-specific representation of the user-centered design that is executable on a targeted runtime platform. Operation 650 includes executing the platform-independent representation of the domain model on a runtime platform.

The operations shown and described herein are provided to illustrate example implementations. It is noted that the operations are not limited to the ordering shown. Still other operations may also be implemented.

Further example operations may include operation 611 using a capture tool that encodes the meta-language for user-centered design. Further operations may also include operation 612 identifying object types of the meta-language for user-centered design. The object types may include at least a user role. Operations may also include operation 613 identifying relationship types of the meta-language for user-centered design. The relationship types include at least a Key User Task performed by a User Role.

In the example shown in FIG. 6A, operation 615 includes defining a meta-language for user-centered design. Operation 625 includes capturing a user-experience for a specified domain. Operation 635 includes exporting a platform-independent representation of the user experience. Operation 645 includes transforming the platform-independent representation into a platform-specific representation of the user experience that is executable on a targeted runtime platform.

The operations may be implemented at least in part using an end-user interface (e.g., web-based interface). In an example, the end-user is able to make predetermined selections, and the operations described above are implemented on a back-end device to present results to a user. The user can then make further selections. It is also noted that various of the operations described herein may be automated or partially automated.

It is noted that the examples shown and described are provided for purposes of illustration and are not intended to be limiting. Still other examples are also contemplated.

MODEL-DRIVEN ARCHITECTURE FOR USER-CENTERED DESIGN

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims

PCT Information