Hierarchical User Interface Component Architecture (HUICA)

< Previous110RiotRiot [Piirainen 2015] was developed by Tero Piirainen in 2015. Its most distinct as-pects indeed are its very small code size, its native-looking custom HTML tags, and its compatibility with other DOM-manipulating libraries like jQuery.The most prominent drawback of Riot is that, in contrast to VueJS, Marko and React, it is not using a Virtual DOM rendering approach, and hence it can be slower than its competitors.eBay MarkoMarko [Ebay 2016] was developed by eBay in 2016. Its most distinct aspects indeed are its very small code size, its unobtrusive and concise syntax, its high Virtual DOM based View Mask rendering and update performance, and its optional HTML streaming mode for rendering the View Mask.Although Marko is a very clean and elegant solution, its most prominent draw-backs of Marko are that it deﬁnitely requires the use of a JavaScript module bun-dler and compile-time translation and that it, despite its prominent vendor, is still a niche solution without a large community.VueJSVueJS [You 2014] was developed by Evan You in 2014 and combines the expressive-ness of Angular’s HTML template and Data Binding language with a clean Separa-tion of Concern and React’s Virtual DOM approach.Its most distinct aspect is its good interplay with third-party widgets and even DOM manipulation libraries. With some care, one can even use VueJS and jQuery at the same time to manipulate the DOM.VueJS’s Model-View-Separation approach is based on the MVC pat-tern where the View is based on the VueJS HTML template and Data Bind-ing language and the Controller and Model simple JavaScript classes. In VueJS, the hierarchy-driving Components are the View components.The most prominent drawback of VueJS is its less prominent backing by any large organization. The VueJS ecosystem also contains the prominent Vuex com-panion library for implementing the Presentation Model.VueJS is an elegant ap-proach for bare View Mask rendering and Data Binding.Chapter 6SolutionChapter 6: Solution112Chapter Contents6.1 Hierarchical User Interface Component Architecture (HUICA) ........................................ 1156.2 User Interface Aspects ....................................................... 1166.2.1 Aspect Group: Mask ................................................. 1176.2.2 Aspect Group: Data .................................................. 1186.2.3 Aspect Group: Connectivity ........................................ 1186.2.4 Aspect Group: Dialog ................................................ 1186.3 User Interface Ontology .................................................... 1196.3.1 User Interface Speciﬁcation ........................................ 1196.3.2 User Interface Composition ........................................ 1196.3.3 User Interface Fragment Classiﬁcation ........................... 1216.3.4 User Interface Component Tree ................................... 1216.3.5 User Interface Component Roles .................................. 1216.4 Hierarchical Component Structure ....................................... 1226.4.1 Component Object and Backing Object ......................... 1226.4.2 Component Tree ..................................................... 1236.4.3 Component Path and Component Lookups .................... 1256.5 Hierarchical Component States ........................................... 1266.5.1 Component States ................................................... 1276.5.2 Component Life-Cycle .............................................. 1286.5.3 Component State Transition Invariants .......................... 1296.5.4 Component State Transition Automatism ....................... 1316.5.5 Component State Transition Guards .............................. 1326.5.6 Component Resource Allocation Spooling ...................... 1336.6 Hierarchical Component Communication ............................... 1356.6.1 Fetchable Resource Properties .................................... 1356.6.2 Observable Presentation Models ................................. 1366.6.3 Pluggable User Interface Fragment Sockets ..................... 1386.6.4 Subscribable Information Events .................................. 1416.6.5 Registerable Function Services .................................... 1446.7 Hierarchical Dialog Composition .......................................... 1476.7.1 Logical Decomposition ............................................. 1476.7.2 Physical Recomposition ............................................. 149 1136.8 Hierarchical Dialog Architecture: Model-View-Controller/Component-Tree (MVC/CT) .................. 1506.8.1 Component Tree: Fragment Correlation ......................... 1516.8.2 Component Roles: View, Model, and Controller ................ 1516.8.3 Component Knowledge: White Box vs. Black Box .............. 1526.8.4 Component Triad Variants: Composite vs. Widget .............. 1536.8.5 MVC/CT Architecture Pattern ...................................... 1566.8.6 MVC/CT Step 1: Component Triad ................................. 1576.8.7 MVC/CT Step 2: Component Layers ............................... 1576.8.8 MVC/CT Step 3: Component Aspects ............................. 1586.8.9 MVC/CT Step 4: Presentation Provisioning ...................... 1616.8.10 MVC/CT Step 5: View Mask Data Binding ........................ 1626.8.11 MVC/CT Step 6: Presentation Logic ............................... 1636.8.12 MVC/CT Step 7: Presentation Actioning .......................... 1636.9 Data Binding of Presentation Model ..................................... 1646.9.1 Data Binding Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1646.9.2 Simple Approach: Imperative Code ............................... 1656.9.3 Clean Approach: Declarative External Mappings ............... 1656.9.4 Pragmatic Approach: Declarative Inline Expressions ........... 1676.9.5 Model Read/Write Operations and Binding Updates .......... 1686.10 Data Binding of Business Model ........................................... 1686.10.1 Data Binding Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1686.10.2 Simple Approach: Imperative Code ............................... 1696.10.3 Clean Approach: Declarative External Mappings ............... 1696.10.4 Pragmatic Approach: Declarative Inline Queries ................ 1696.10.5 Model Read/Write Operations and Binding Updates .......... 1706.11 Component Tree Structure Patterns ...................................... 1736.11.1 Alternative View: (V+V)-M .......................................... 1736.11.2 Reusable Widget: V-M ............................................... 1736.11.3 Standalone Controller: C ............................................ 1756.11.4 Headless Pair: M-C ................................................... 1756.11.5 Full Triad: V-M-C ...................................................... 1766.12 Component Tree Behavior Patterns ...................................... 1766.12.1 Controller-Created Descendants .................................. 1766.12.2 Interaction Event Values ............................................ 1766.12.3 Presentation State Logic ............................................ 1776.12.4 Common Ancestor Communication .............................. 1776.12.5 Own Descendant Communication ................................ 178Chapter 6: Solution1146.13 User Interface Run-Time Monitoring ..................................... 1796.13.1 Real-Time Component Tree Visualization ........................ 1796.13.2 Real-Time Component Tree Tracing ............................... 1816.14 User Interface Run-Time Integration ..................................... 1846.14.1 Rich-Client Integration .............................................. 1846.14.2 Thin-Client Integration .............................................. 185Hierarchical User Interface Component Architecture (HUICA)1156.1 Hierarchical User Interface Component Architecture (HUICA)Roll your own solution to your hardest problems, not your easiest ones. — Greg BrockmanThe Hierarchical User Interface Component Architecture (HUICA) is the solution to meet the stated requirements and challenges and is the primary scientiﬁc contri-bution of this dissertation. It can be brieﬂy summarized as follows:Figure 6.1: Hierarchical User Interface Component Architecure OverviewData Binding ofPresentation ModelUser InterfaceAspectsUser InterfaceOntologyHierarchical ComponentStructureHierarchical Component CommunicationHierarchical Component StatesHierarchical DialogArchitectureHierarchical DialogCompositionComponent TreeStructure PatternsComponent TreeBehavior PatternsData Binding ofBusiness ModelUser InterfaceRun-Time MonitoringUser InterfaceRun-Time IntegrationCOREBASEPLUSHierarchical User Interface Component Architecture (HUICA)Chapter 6: Solution116The HUICA consists of distinct building blocks, as shown in the overview Figure 6.1 on page 115. They are clustered into the absolutely mandatory CORE, strongly recommended BASE and optional but useful PLUS building block classes. Each in-dividual building block is documented in the following sections within this chap-ter. For the basics on Software Architecture aspects, see [Clements et al. 2002] [Vogel et al. 2009] [Hasselbring 2009] [Bass et al. 2010] [Taylor et al. 2010] [Fairbanks 2010] [Starke & Hruschka 2011] [Gorton 2011] [Posch et al. 2012] [Gharbi 2014] [Peuker 2014] [Zorner 2015] [Starke 2015] [Toth 2015] [Starke & Hruschka 2016] [Kazman & Cervantes 2016] [Lilienthal 2017].The HUICA consists of both reused, derived and original parts. Those parts, which are fully original brainchildren of Ralf S. Engelschall, are additionally marked with a head/brain icon, as they are part of his personal scientiﬁc contribution.6.2 User Interface AspectsThe most important single aspect of software development is to be clear about what you are trying to build. — Bjarne Stroustrup User Interfaces (UI) are very complex pieces of software, with many diﬀerent as-pects one has to take into account (see Figure 6.2 on page 116 for an overview). Figure 6.2: User Interface Aspects OverviewInterface ThemeInterface InteractionsData BindingInterface WidgetsInterface StatesData ConversionInterface LayoutInterface MaskData ModelInterface EﬀectsInterface EnvironmentData CachingBusiness ModelDialog StructureDialog CommunicationBusiness CommunicationDialog Life-CycleDialog NavigationMaskDataDialogConnectivityusually coveredoften overlookedUser Interface Aspects117Independent of the particular used Technology Stack, all of those aspects have to be covered in practice. Either by using existing libraries and frameworks or by craft-ing them from scratch.When using existing libraries and frameworks, one especially wants to achieve both full coverage and no overlapping according to the UI aspects the library or framework address. Hence, we split the overall functionality of a UI into the mini-mum number of distinct UI aspects for mapping products onto them with maxi-mum clarity. For each aspect, keyword-based hints are given, which indicate the scope of the UI aspect.When mapping these aspects to the existing major frameworks for HTML5 Single-Page-Applications, it becomes evident that the aspects re-lated to Dialog control and Presentation Model often are not in focus or are often even overlooked. In the Hierarchical User Interface Component Architec-ture (HUICA) they are instead essential and mandatory.6.2.1 Aspect Group: MaskThe ﬁrst and most prominent group of aspects deals with the UI mask, the particu-lar visual appearance of the UI.Aspect NameAspect ScopeInterface ThemeStyle Reset, Shape, Color, Gradient, Shadow, Font, Icon.Interface WidgetsIcon, Label, Text Paragraph, Image, Form, Text-Field, Text-Area, Date Picker, Toggle, Radio Button, Checkbox, Select List, Slider, Progress Bar, Hyperlink, Popup Menu, Dropdown Menu, Toolbar, Tooltip, Tab, Pill, Breadcrumb, Pagination, Badge, Alert, Panel, Modal, Table, Scrollbar, Carousel.Interface LayoutResponsive Design, Media Query, Frame, Grid, Padding, Border, Margin, Alignment, Force, Magnetism.Interface EﬀectsTransition, Transformation, Keyframes, Easing Function, Sound Eﬀect, Physics.Interface InteractionsMouse, Keyboard, Touch-screen, Gesture, Clipboard, Drag & Drop.Interface StatesRendered, Enabled, Visible, Focused, Warning, Error, Floating.Interface MaskMarkup Loading, Markup Generation, Virtual DOM, Text, Bitmaps, Vectors, 2D/3D Canvas, Accessibility.Interface EnvironmentFeature Detection, Feature Polyﬁll.Every particular Technol-ogy Stack has to cover all 18 User Interface Aspects.Chapter 6: Solution1186.2.2 Aspect Group: DataThe second group of aspects deals with the domain and state data which is behind the UI mask. This data forms a so-called Presentation Model and is the essential ab-straction of the UI.Aspect NameAspect ScopeData BindingReactive, Observer, Unidirectional, Bidirectional, Incre-mental.Data ConversionValue Formatting, Value Parsing, Localization (L10N), Internationalization (I18N).Data ModelParameter Value, Command Value, State Value, Data Value, Event Value, Value Validation.Data CachingLocal Storage, Cookies.6.2.3 Aspect Group: ConnectivityThe third group of aspects deals with the connectivity of the UI to the Back End business services, the origin and single point of truth for all persistent data.Aspect NameAspect ScopeBusiness ModelEntity, Field, Relationship, Universally Unique Identiﬁers (UUID).Business CommunicationRequest/Response, Synchronization, Push, Pull, Pulled-Push, REST, GraphQL.6.2.4 Aspect Group: DialogThe forth group of aspects deals with the management of the individual UI dialogs. Aspect NameAspect ScopeDialog StructureHierarchical Composition, Component Tree, Compo-nent Roles.Dialog Life-CycleStates, State Transitions.Dialog CommunicationEvents, Services, Hooks, Models, Sockets, Properties.Dialog NavigationRouting, URL.User Interface Ontology1196.3 User Interface OntologyIf we spoke a diﬀerent language, we would perceive a somewhat diﬀerent world. — Ludwig Wittgenstein It is reasonable to have a common understanding and terminology in the context of User Interfaces (UI). This can be achieved with an Ontology [Busse et al. 2012] [Busse et al. 2015]: a Taxonomy of terms plus their relationships. An overview of the UI Ontology is shown in Figure 6.3 on page 120. The individual areas are explained in the following.6.3.1 User Interface SpeciﬁcationDuring the speciﬁcation of a User Interface, a Storyboard of Wireframes is usually sketched [Jacobson 2011] [Kusano et al. 2013] [Nichols & Chesnut 2014] [Grewenig 2014]. The individual Wireframes of User Interface Composites are then linked through Interactions. The corresponding taxonomy excerpt is: ■Storyboard: Visual speciﬁcation of an application as a whole, de-ﬁned with the help of one or more Wireframes. ■Wireframe: High-level visual speciﬁcation of a Panel or Dialog Composite, intentionally drawn in sketch-style. ■Area: Mid-level visual area of a Wireframe, functionally corre-sponding to a Panel or Dialog Composite or a Container, Control or Visual Widget. ■Interaction: User action on an Area, causing arbitrary domain-speciﬁc functionality to run and resulting in the appearance of another Area or whole Wireframe.6.3.2 User Interface CompositionThe Storyboard, Wireframes, and Areas of the User Interface Speciﬁcation have to be mapped onto the conceptual items: User Interface and Fragment. The corre-sponding taxonomy excerpt is: ■User Interface: Visual presentation and interaction surface of an applica-tion as a whole, consisting of one or more Fragments. ■Fragment: Visual UI part, optionally consisting of other nested Fragments.A wireframe is a visual schematic that repre-sents the skeleton of a UI through sketched widg-ets and a rough layout. Its optical appearance in-tentionally tries to focus on just the essential UI aspects.Next >