< PreviousChapter 10: Evaluation280Figure 10.1: Upstream Author Evaluation of HUICA0%1-19%20-39%40-59%60-79%80-99%100%NOT AT ALLVERY POOR POORACCEPTABLEGOODVERY GOODPERFECTNDNA0123456Section Ref.REQ-F1Complete User Interface Aspect Coverage6.2REQ-F2Complete User Interface Ontology6.3REQ-F3Separation of Mask, Style, and Behaviour6.8REQ-F4Separation of Controls, Interactions, and Events6.8, 6.9REQ-F5Dialog-Level Structuring6.4, 6.7, 6.11REQ-F6Dialog Life-Cycle and States6.5REQ-C1HTML5 Single-Page-Application Approach6.6, 6.8REQ-C2Strict Language Separation6.2REQ-C3Potential Offline Operation6.10REQ-C4Near-Real-Time Updates6.9, 6.10REQ-A1Separation of Model, View, and Control6.8REQ-A2Distinguished Presentation Model6.8, 6.9, 6.10REQ-A3Dialog Instantiation and Reusability6.4REQ-A4Dialog-Level Component-Orientation6.4, 6.7REQ-A5Hierarchical Dialog Communication6.6REQ-A6Transitive Dialog Communication6.6REQ-A7Structure and Behaviour Patterns6.11, 6.12REQ-A8Microservice User Interface Integration6.14REQ-A9Run-Time Tracing and Architecture Constraints6.13REQ-D1Server-Side Component Model Alignment6.4, 6.5REQ-D2Hierarchical Development-Time Dialog De-Composition6.4, 6.7REQ-D3Distributed Orchestration of Run-Time Dialog Re-Composition6.7REQ-D4Event-Driven Architecture6.8, 6.9, 6.10REQ-D5Adequate Technology Complexity6.7REQ-D6Object-Oriented Programming Flavors6.4REQ-D7Different Programming Models6.8REQ-E1Potential Web Technology Independence6.8REQ-E2Third-Party Integration and Extensibility6.8REQ-E3Run-Time Debugging and Visualization6.13REQ-E4Head-Less Run-Time Testing6.8REQ-E5Massive Dialog Scalability6.4, 6.5, 6.6, 6.7REQ-E6Team Delegation and Responsibilities6.6, 6.7REQUIREMENT ATTAINMENTNOT DETERMINABLENOT APPLICABLEAcademic Evaluation281Composition” on page 147 and Section “6.11 Component Tree Structure Patterns” on page 173 for details. ■[REQ-F6] Dialog Life-Cycle and States: PERFECT. The rationale is that HUICA, by design, completely fulfills the requirement. See Section “6.5 Hierarchical Component States” on page 126 for details. ■[REQ-C1] HTML5 Single-Page-Application Approach: PERFECT. The rationale is that HUICA, by design, completely fulfills the require-ment. See Section “6.6 Hierarchical Component Communication” on page 135 and Section “6.8 Hierarchical Dialog Architecture: Model-View-Controller/Component-Tree (MVC/CT)” on page 150 for de-tails. ■[REQ-C2] Strict Language Separation: GOOD. The rationale is that the User Interface Aspects of HUICA are the clear prerequisite for a strict language separation, but HUICA itself does nothing more on the conceptual side. See Section “6.2 User Interface Aspects” on page 116 for details. ■[REQ-C3] Potential Offline Operation: GOOD. The rationale is that a Pres-entation Model and the data binding for the Business Model are the clear prerequisites for offline operations, but, as the Business Model is outside the scope of HUICA, there is no further explicit support for offline opera-tions in HUICA. See Section “6.10 Data Binding of Business Model” on page 168 for details. ■[REQ-C4] Near-Real-Time Updates: VERY GOOD. The rationale is that the data binding for both the Presentation Model and the Business Model are clear prerequisites for near-real-time updates, but the actual near-real-time Back-End communication is outside the conceptual scope of HUICA. See Section “6.9 Data Binding of Presentation Model” on page 164 and Section “6.10 Data Binding of Business Model” on page 168 for details. ■[REQ-A1] Separation of Model, View, and Control: PERFECT. The rationale is that HUICA, by design, completely fulfills the re-quirement. See Section “6.8 Hierarchical Dialog Architecture: Model-View-Controller/Component-Tree (MVC/CT)” on page 150 for de-tails. ■[REQ-A2] Distinguished Presentation Model: PERFECT. The ra-tionale is that HUICA, by design, completely fulfills the re-quirement. See Section “6.8 Hierarchical Dialog Architecture: Model-View-Controller/Component-Tree (MVC/CT)” on page 150, Section “6.9 Data Binding of Presentation Model” on page 164 and Section “6.10 Data Binding of Business Model” on page 168 for details. ■[REQ-A3] Dialog Instantiation and Reusability: PERFECT. The rationale is that HUICA, by design, completely fulfills the requirement. See Section “6.4 Hierarchical Component Structure” on page 122 for details.Chapter 10: Evaluation282 ■[REQ-A4] Dialog-Level Component-Orientation: PERFECT. The rationale is that HUICA, by design, completely fulfills the requirement. See Section “6.4 Hierarchical Component Structure” on page 122 and Section “6.7 Hierar-chical Dialog Composition” on page 147 for details. ■[REQ-A5] Hierarchical Dialog Communication: PERFECT. The rationale is that HUICA, by design, completely fulfills the requirement. See Section “6.6 Hierarchical Component Communication” on page 135 for details. ■[REQ-A6] Transitive Dialog Communication: PERFECT. The rationale is that HUICA, by design, completely fulfills the requirement. See Section “6.6 Hi-erarchical Component Communication” on page 135 for details. ■[REQ-A7] Structure and Behavior Patterns: VERY GOOD. The rationale is that HUICA provides a reasonable set of structure and behavior patterns. See Section “6.11 Component Tree Structure Patterns” on page 173 and Section “6.12 Component Tree Behavior Patterns” on page 176 for details. ■[REQ-A8] Microservice User Interface Integration: GOOD. The rationale is that HUICA conceptually supports the integration of multiple User Inter-faces during run time, but HUICA itself does nothing more on the con-ceptual side. HUICA especially does not document how this integration is done in detail in practice. See Section “6.14 User Interface Run-Time Inte-gration” on page 184 for details. ■[REQ-A9] Run-Time Tracing and Architecture Constraints: VERY GOOD. The rationale is that HUICA supports a reasonable tracing and constraints mechanism, although it is not a 100% solution. See Section “6.13 User In-terface Run-Time Monitoring” on page 179 for details. ■[REQ-D1] Server-Side Component Model Alignment: GOOD. The rationale is that HUICA’s Component Model loosely follows the usual models on the server-side. However, HUICA’s model is more powerful and hierarchical, while mostly all server-side models are less powerful and not hierarchi-cal. See Section “6.4 Hierarchical Component Structure” on page 122 and Section “6.5 Hierarchical Component States” on page 126 for details. ■[REQ-D2] Hierarchical Development-Time Dialog De-Composition: PER-FECT. The rationale is that HUICA, by design, completely fulfills the require-ment. See Section “6.4 Hierarchical Component Structure” on page 122 and Section “6.7 Hierarchical Dialog Composition” on page 147 for details. ■[REQ-D3] Distributed Orchestration of Run-Time Dialog Re-Composition: PERFECT. The rationale is that HUICA, by design, completely fulfills the requirement. See Section “6.7 Hierarchical Dialog Composition” on page 147 for details. ■[REQ-D4] Event-Driven Architecture: PERFECT. The ration-ale is that HUICA, by design, completely fulfills the require-ment. See Section “6.8 Hierarchical Dialog Architecture: Academic Evaluation283Model-View-Controller/Component-Tree (MVC/CT)” on page 150, Section “6.9 Data Binding of Presentation Model” on page 164 and Section “6.10 Data Binding of Business Model” on page 168 for details. ■[REQ-D5] Adequate Technology Complexity: GOOD. The rationale is that HUICA’s Hierarchical Dialog Composition provides an adequate focus point in practice and supports both small and large User Interfaces, but one can imagine an architecture which at least causes less “boilerplate code” for small User Interfaces. See Section “6.7 Hierarchical Dialog Composition” on page 147 for details. ■[REQ-D6] Object-Oriented Programming Flavors: PERFECT. The rationale is that HUICA, by design, completely fulfills the requirement. The key con-cept is the distinction between Components and Backing Objects. See Section “6.4 Hierarchical Component Structure” on page 122 for details. ■[REQ-D7] Different Programming Models: VERY GOOD. The rationale is that HUICA intentionally makes no assumption how the View Masks are rendered and this way supports both direct DOM-based and indirect Object Instanti-ation based approaches. See Section “6.8 Hierarchical Dialog Architecture: Model-View-Controller/Component-Tree (MVC/CT)” on page 150 for de-tails. ■[REQ-E1] Potential Web Technology Independence: GOOD. The ra-tionale is that HUICA intentionally makes no assumption how the View Masks are rendered and how Components are OOP-wise im-plemented. See Section “6.8 Hierarchical Dialog Architecture: Model-View-Controller/Component-Tree (MVC/CT)” on page 150 for de-tails. ■[REQ-E2] Third-Party Integration and Extensibility: GOOD. The rationale is that HUICA intentionally makes no assumption how the View Masks are rendered and so allows multiple libraries to manipulate the DOM coopera-tively. However, HUICA conceptually provides no mechanism for managing this cooperation and leaves it to the particular implementations to correctly interplay with each other. See Section “6.8 Hierarchical Dialog Architecture: Model-View-Controller/Component-Tree (MVC/CT)” on page 150 for de-tails. ■[REQ-E3] Run-Time Debugging and Visualization: VERY GOOD. The ration-ale is that HUICA conceptually supports this requirement, but does noth-ing more. In practice, it is the task of the underlying HUICA-based Compo-nent System to provide the necessary mechanism. See Section “6.13 User Interface Run-Time Monitoring” on page 179 for details. ■[REQ-E4] Head-Less Run-Time Testing: PERFECT. The ration-ale is that HUICA, by design, completely fulfills the require-ment. The key concept is that the View Components are ful-Chapter 10: Evaluation284ly optional. See Section “6.8 Hierarchical Dialog Architecture: Model-View-Controller/Component-Tree (MVC/CT)” on page 150 for de-tails. ■[REQ-E5] Massive Dialog Scalability: PERFECT. The rationale is that HUICA, by design, completely fulfills the requirement. The key aspect is that eve-rything in the Component Tree is locally scoped and just loosely coupled. See Section “6.4 Hierarchical Component Structure” on page 122, Section “6.5 Hierarchical Component States” on page 126, Section “6.6 Hierarchi-cal Component Communication” on page 135, and Section “6.7 Hierarchi-cal Dialog Composition” on page 147 for details. ■[REQ-E6] Team Delegation and Responsibilities: PERFECT. The rationale is that HUICA, by design, completely fulfills the requirement. The key aspect is that everything in the Component Tree is locally scoped and just loosely coupled. See Section “6.6 Hierarchical Component Communication” on page 135, and Section “6.7 Hierarchical Dialog Composition” on page 147 for details.10.1.2 Downstream Developer EvaluationIn this subsection, the Hierarchical User Interface Component Architecture (HUICA) solution (see Chapter 6 on page 111) is evaluated from an academic “downstream” perspective of other developers in the field. The average attainment evaluation of the Requirement Suite from the perspective of the developers one can find sum-marized in Figure 10.2 on page 285.The individual developers which evaluated HUICA are known by their full name to the author and here are just identified by a three-letter abbreviation. Their profiles follow (in the order of decreasing years of experience with HUICA): ■Person 1 [JHO]: male, IT education, Software Architect role, 20 years of ex-perience in Software Engineering, 15 years of experience with User Inter-faces, 6 years of experience with HUICA. ■Person 2 [LZE]: female, Computer Science education, Software Architect role, 6 years of experience in Software Engineering, 6 years of experience with User Interfaces, 5 years of experience with HUICA. ■Person 3 [MLU]: male, IT education, Software Engineer, 15 years of experi-ence in Software Engineering, 5 years of experience with User Interfaces, 2 years of experience with HUICA.Practical Feedback285Figure 10.2: Downstream Developer Evaluation of HUICA0%1-19%20-39%40-59%60-79%80-99%100%NOT AT ALLVERY POOR POORACCEPTABLEGOODVERY GOODPERFECTNDNA0123456AVGREQ-F1Complete User Interface Aspect Coverage6,0REQ-F2Complete User Interface Ontology6,0REQ-F3Separation of Mask, Style, and Behaviour3,7REQ-F4Separation of Controls, Interactions, and Events4,3REQ-F5Dialog-Level Structuring5,7REQ-F6Dialog Life-Cycle and States6,0REQ-C1HTML5 Single-Page-Application Approach6,0REQ-C2Strict Language Separation3,7REQ-C3Potential Offline Operation3,7REQ-C4Near-Real-Time Updates4,7REQ-A1Separation of Model, View, and Control6,0REQ-A2Distinguished Presentation Model6,0REQ-A3Dialog Instantiation and Reusability6,0REQ-A4Dialog-Level Component-Orientation6,0REQ-A5Hierarchical Dialog Communication6,0REQ-A6Transitive Dialog Communication6,0REQ-A7Structure and Behaviour Patterns5,3REQ-A8Microservice User Interface Integration2,7REQ-A9Run-Time Tracing and Architecture Constraints4,0REQ-D1Server-Side Component Model Alignment4,7REQ-D2Hierarchical Development-Time Dialog De-Composition5,3REQ-D3Distributed Orchestration of Run-Time Dialog Re-Composition5,3REQ-D4Event-Driven Architecture5,7REQ-D5Adequate Technology Complexity5,3REQ-D6Object-Oriented Programming Flavors4,0REQ-D7Different Programming Models4,7REQ-E1Potential Web Technology Independence3,7REQ-E2Third-Party Integration and Extensibility4,0REQ-E3Run-Time Debugging and Visualization4,0REQ-E4Head-Less Run-Time Testing5,7REQ-E5Massive Dialog Scalability5,3REQ-E6Team Delegation and Responsibilities5,7REQUIREMENT ATTAINMENTNOT DETERMINABLENOT APPLICABLEChapter 10: Evaluation28610.2 Practical FeedbackWe all need people who will give us feedback. That’s how we improve. — Bill GatesIn this section, the most prominent practical feedback and lessons learned from developers are summarized, which are not directly related to the particular Re-quirements Suite (see Section 4.2 on page 61).10.2.1 Imperative vs. Declarative Data BindingThe initial HUICA applications used plain jQuery for bi-directionally binding the View Mask to the Presentation Model in an imperative fashion. This functionality-wise worked just fine, but unfortunately caused an extraordinarily large amount of “boilerplate code.” The View components, as a result, became rather huge, not easy to comprehend and hard to maintain.The later HUICA applications used the excellent VueJS library for bi-direction-ally binding the View Mask to the Presentation Model in a declarative fashion. This dramatically reduced the amount of necessary code and at the same time made the Views more comprehensible and easier to maintain.The lesson learned from this, and hence the later GemstoneJS ap-proach, was that HUICA should be used with a declarative bi-directional View Mask binding only. 10.2.2 Reduced vs. Full-Blown MVC/CT TriadsHUICA has a set of defined Component Tree Structure Patterns (see Section 6.11 on page 173) which, from a bare architecture perspective, are both reasonable and practical. About half of the HUICA-based applications (see Chapter 9 on page 253) are directly based on these patterns. The other half of the HUICA based applications consequently use full-blown MVC/CT Triads only (see Subsection 6.11.5 on page 176). They even accept that sometimes Components are just ones without any functionality, except their Com-ponent Tree namespace/position purpose. From a bare architecture perspective, this is both not reasonable and not clean. However, from a practical Soft-ware Engineering perspective, this can be reasonable, as this extreme ap-proach ensures that developers are not required to have a deeper archi-tectural understanding of HUICA and can instead mindlessly implement the easier to understand single MVC/CT Triad pattern. This greatly simpli-fies the Software Engineering with a team of junior developers and greatly reduces the special cases in the Component Tree. It also avoids any major Component Tree refactoring, in case of Dialog requirements change.HUICA always should be used with a declarative bi-directional data bind-ing.Software Architecture sometimes can be a nasty burden for developers in practice.Practical Feedback287The lesson learned from this is that although the Software Architecture disci-pline in general greatly supports the Software Engineering domain, sometimes it can make it more complex than the average developer can easily comprehend.10.2.3 Explicit vs. Automatic Resource Allocation Spooling The HUICA-supporting Component System ComponentJS from the earliest days supported explicit Component Resource Allocation Spooling (see Subsection 6.5.6 on page 133). Later most of the resource allocation methods in ComponentJS re-ceived a spool flag for implicitly spooling the resource de-allocation operation. This is a major convenience feature, as it lets one avoid mostly all Component leave methods (see Subsection 6.5.1 on page 127) and this way substantially reduces the amount of “boilerplate code.”Finally, it was recognized that the spool flag was really used every-where in HUICA applications and actually could have been the default. In other words: the lesson learned from this was that one actually wants fully automatic resource (de-)allocation spooling in practice and only in rare circumstances one needs to disable this feature.10.2.4 Code-First vs. Contract-First ApproachIn Software Engineering there are two classical approaches to interface definitions: Code-First and Contract-First. In Code-First, the actual interface implementation is coded, and this code then implicitly defines the interface. In Contract-First, first a specification of the interface is created and then the implementation of the inter-face is required to follow it.The advantage of Code-First is productivity and convenience. The advantage of Contract-First is that the specification is the first-hand documentation of the interface and that one gets the ability to perform automatic syntactical checking of the implementation against the speci-fication during build time.Half of the HUICA applications used Code-First for the Dialog Components, while the other half of the HUICA applications used Contract-First for the Dialog Components with the help of a component.yaml specification file.The lesson learned from this was that although from a strict architecture ap-proach, the Contract-First approach is superior, the Code-First approach in total was considered to have more advantages than drawbacks in contrast to Contract-First by most developers. In practice fully automat-ic resource (de-)alloca-tion spooling is advised.Code-First is less clean, but beats Contract-First in practice due to produc-tivity and joy of develop-ment.28810.2.5 Natural vs. Traditional Component Tree VisualizationIn nature, trees have their root at the bottom and their leaves towards the top. In Computer Science, trees are traditionally drawn the opposite direction: with their root at the top and their leaves towards the bottom.ComponentJS supports the Component Tree Visualization (see Sub-section 6.13.1 on page 179) in both natural and traditional directions. Initially, the ComponentJS direction was the traditional direction of Com-puter Science. However, once the User Interface Optical View Projection (see Figure 6.6 on page 125) was understood, the Component Tree was always visualized in natural direction by most developers.The lesson learned from this is that the natural Component Tree Visualization, with the root Component at the bottom and the leaf Components towards the top, is the most intuitive way.The Component Tree Visualization in the natu-ral direction is the most intuitive.VPartConclusion and EpilogNext >