< PreviousChapter 6: Solution1506.8 Hierarchical Dialog Architecture: Model-View-Controller/Component-Tree (MVC/CT)Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. — Christopher AlexanderIn order to create complex User Interfaces, consisting of hundreds of Dialogs, in a hierarchical fashion out of Components on a Component Tree, a strict underlying Component-Oriented Architecture is required.This architecture is based on a new architecture pattern: Model-View-Con-troller/Component-Tree (MVC/CT), a variant of the classic Model-View-Controller (MVC) pattern, driven on a Component Tree. It proved to scale even to very com-plex User Interfaces of Business Information Systems with hundreds of dialogs thanks to its strict Separation of Concerns aspect.The essential MVC/CT ar-chitecture pattern is the ultimate heart of HUICA.Figure 6.14: User Interface Ontology (Excerpt)CompositeUser InterfaceWidget+ControllerModelViewComponentparentchild0..1*parent0..1User InterfaceFragment ClassificationUser InterfaceCompositionUser InterfaceComponent RolesUser InterfaceComponent Treewrapper0..10..10..1TriadFragmentimplemented byimplemented bychild***Hierarchical Dialog Architecture: Model-View-Controller/Component-Tree (MVC/CT)1516.8.1 Component Tree: Fragment CorrelationAccording to the User Interface Ontology (see Section 6.3 on page 119 or the ex-cerpt in Figure 6.14 on page 150), the User Interface consists of a tree of UI Frag-ments. Each UI Fragment is either a Composite or a Widget. Both Composites and Widgets are then implemented by Components, which, in turn, are assembled in a Component Tree. This way, a UI Fragment is implemented by a set of strongly related Components. These strongly related Components then implement a par-ticular Composite or Widget and have either the View, Model or Controller roles. The combination of those three Components are called a Component Triad (see Figure 6.15 on page 151).6.8.2 Component Roles: View, Model, and ControllerThe Component Triad of View, Model and Controller Components form the outer unit of the Model-View-Controller/Component-Tree (MVC/CT) architecture pattern. In contrast to the classical regular Model-View-Controller (MVC) architecture pat-tern, MVC/CT has the strict ordering of View, Model and Controller Components. Actually, they have stacked in exactly this order: View, Model and Controller (see Figure 6.16 on page 152). The Controller has the responsibility to provision the Model and to act towards the (business) service and their data. The View presents the Model data to the user and reacts on user interactions towards the Model.Figure 6.15: Component Tree and Component TriadCControllerComponentModelComponentViewComponentComponent TriadVVMMMCCVMCVMVMCVMCVMCVComponent TreeChapter 6: Solution1526.8.3 Component Knowledge: White Box vs. Black BoxIt is important to notice that although the View, Model, and Controller Compo-nents are stacked onto each other in a strict way, they do not form a traditional layer architecture where only upper layers are allowed to know and use lower layers. Instead, there are two views: a life-cycle related Black-Box view and a usage related White-Box view (see Figure 6.17 on page 152).MVC/CT is not a strict traditional layer architec-ture, but has blackbox and whitebox views.CMVFigure 6.16: Component RolesFigure 6.17: Component Knowledge: White Box vs. Black BoxControllerComponentModelComponentViewComponentComponent TriadBlackboxKnowledge(Life-Cycle)WhiteboxKnowledge(Usage)Hierarchical Dialog Architecture: Model-View-Controller/Component-Tree (MVC/CT)153The Controller Component has a Black-Box view of the Model and View Com-ponents in order to manage their life-cycle. This means the Controller Component is at least allowed to create, change state and destroy the Model and View Compo-nents. However, it is not allowed in its Black-Box view to perform any other opera-tions on them.In the White-Box view, both the Controller and the View Components are al-lowed to use the Model Component. This means the Controller and View Compo-nents set, observe and get data from the Model Component. In other words: they know exactly the data structure of the Model Component and directly access it. However, it is also allowed in the White-Box view to perform any other operations than bare data access. The Model Component has to synchronize any concurrent access.As a consequence, the Model Component is a fully passive one. It knows noth-ing about the View and Controller Components around it. In contrast to the Model Component, both the View and Controller Components are fully active ones. They know all about the Model and use it as their intermediate data structure.6.8.4 Component Triad Variants: Composite vs. WidgetFor implementing a Widget or Composite, it is not necessary that all three Components be present. Instead, there are major variants of the Component Triad (see Figure 6.18 on page 153).When implementing a Composite, the Controller Component is mandatory. However, the Model and View Components can be left out if the Composite just orchestrates other Composites and Widget and hence has no requirement to render an outer UI Fragment on its own. When im-plementing a Widget, the Model and View Components are mandatory. However, the Controller Component can be left out if the Widget is really a fully reusable one MVC/CT does not mean that just full Component Triads exist. Instead, it can collapse for implement-ing some Composites or for usual Widgets.Figure 6.18: Component Triad: Composite vs. WidgetControllerComponentModelComponentViewComponentCompositeControllerComponentModelComponentViewComponentWidgetoptionalmandatoryoptionalmandatoryChapter 6: Solution154(which requires that a provisioning Controller component of an outer Composite orchestrates the Widget).Hence, in practice there are effectively three variants of the Component Triad: full triads for complex Composites, just Controller-based simple Composites and View/Model-based Widgets.Figure 6.19: MVC/CT Architecture Pattern (Conceptual)(Domain)Modelupdatedread/updateDataBindingupdatedread/updateXComponentRun-TimeCallRun-TimeCall-BackKnowledgeRelationshipupdatedread/updateInput/OutputDevicesrendernotifyInheritanceRelationshipparent0..10..10..10..1*child(Abstract)TreeComponent0..10..1parent modelparent view0..1parentcontrollerViewControllerupdatedread/update(Presentation)ModelHierarchical Dialog Architecture: Model-View-Controller/Component-Tree (MVC/CT)155Figure 6.20: MVC/CT Architecture Pattern (Detailed)View MaskParameterValuesStateValuesDataValuesBusinessModelBusinessLogicData Flow (upward)Control Flow (Callback)Control Flow (Direct Call)CommandBindingDataBindingEventBindingStateBindingPresentationLogicEventValuesPresentationProvisioningPresentationActioningViewModelControllerServiceObservableObservableObservableObservableObservableObservableObservableSBViewMaskViewBindingPresentationLogicPresentationModelPresentationControlBusinessServiceDBEBVMPLSVDVEVPPPABMBLactive/codepassive/datacomponentlayeraspectBSPCPMPLVBVMPresentation/Interaction TierBusiness/Service TierObservablePotential Reusability / Multiple InstantiationNon-Reusability / Single InstantiationData Flow (downward)ObservableCommandValuesObservablePVMaskRenderingCBCVMRObservableCVVMMMCCVMCVMVMCVMCVMCVSChapter 6: Solution1566.8.5 MVC/CT Architecture PatternThe Model-View-Controller/Component-Tree (MVC/CT) architecture pattern, as a whole, might be not easy to comprehend for the first time. Hence, it is reasonable to develop it incrementally in nine distinct steps in the following. Nevertheless, once understood, the MVC/CT “all-in-one” diagram (see Figure 6.20 on page 155) is what should be used in practice by Software Engineers during the development of MVC/CT-based User Interfaces. It contains all relevant information about MVC/CT. Additionally, Figure 6.19 on page 154 gives a conceptual overview of MVC/CT in a diagram variant which is visually aligned to, and hence directly comparable, with the diagrams of other Model-View Separation Patterns in Chapter “State of the Art” on page 69.Notice that MVC/CT is not just a high-level architecture pattern (aka concep-tual idea), but actually a detailed low-level implementation-guiding architecture pattern. As such, every box and every line in the MVC/CT “all-in-one” diagram has a direct correspondence to code in the practice.Moreover, also the other way round: there is no code in practice allowed which has no direct correspondence in the MVC/CT diagram. This makes MVC/CT a very useful architecture pattern in practice, as it directly guides the implementation and does not just give a rough idea of the pattern concept.Notice also that MVC/CT, as an architecture pattern, intentionally is shown in the “full-blown” variant, i.e., with the full Component Triad. When implementing MVC/CT is not just a rough concept, but a de-tailed pattern for guiding the implementation.Figure 6.21: MVC/CT Step 1: Component TriadViewModelControllerServicePresentation/Interaction TierBusiness/Service TierPotential Reusability / Multiple InstantiationNon-Reusability / Single InstantiationCVVMMMCCVMCVMVMCVMCVMCVSHierarchical Dialog Architecture: Model-View-Controller/Component-Tree (MVC/CT)157Widgets or Composites with just a reduced set of Components (compare the previ-ous Subsection 6.8.4 on page 153) the Component Triad of MVC/CT collapses, of course.6.8.6 MVC/CT Step 1: Component TriadThe first step in MVC/CT is to start with the full Component Triad of View, Model and Controller Components, in their strict stacking order (see Figure 6.21 on page 156). The Controller Component at the bottom, the Model Component in the mid-dle and the View Component at the top. Additionally, although not part of the User Interface, but still part of the Front End, the underlying Service Component is shown, too. This is usually a singleton of the UI Components use for communicating with the Back End. It is presented in order to show how the Controller interacts with the environment.6.8.7 MVC/CT Step 2: Component LayersIn the second step, we add Component Layers onto the Components of MVC/CT, in order to sub-divide the functionality into equally sized parts and to ensure Sepa-ration of Concerns (see Figure 6.22 on page 158). The individual 5 Component Layers are: ■View Mask (VM): The upper layer of the View Component is the View Mask layer. As the name indicates, there the View Component renders and man-ages the mask of the User Interface. ■View Binding (VB): The lower layer of the View Component is the View Bind-ing layer. Here the View Component performs its data binding functional-ity, i.e., bidirectionally transferring data between the Presentation Model layer of the Model Component and the own View Mask layer. ■Presentation Logic (PL): The upper layer of the Model Component is the Presentation Logic layer. This layer sits on top of the Presentation Model layer, observes and reads its values, performs logical decision operations on those values and writes result values back to the Presentation Model. ■Presentation Model (PM): The lower layer of the Model Component is the Presentation Model layer. This layer provides the abstraction of the UI Frag-ment in the form of an observable data structure. ■Presentation Control (PC): the Controller Component simply consists of a single layer named Presentation Control. ■Business Service (BS): the Service Component simply consists of a single layer named Business Service.Chapter 6: Solution1586.8.8 MVC/CT Step 3: Component AspectsIn the third step, we add Component Aspects to the Component Layers (see Figure 6.23 on page 159). These aspects are either active (in the way of “code,” indicated by a yellow star) or passive (in the way of “data,” indicated by a red box). The individual 16 Component Aspects are: ■View Mask (VM): The passive View Mask aspect provides the User Interface mask of the UI Fragment. For HTML5 SPAs this is the Document-Object-Mod-el (DOM) provided by the browser. ■Mask Rendering (MR): The active Mask Rendering aspect performs the ini-tial creation of the User Interface mask of the UI Fragment. For HTML5 SPAs this means the creation of HTML elements in the DOM. ■Command Binding (CB): The active Command Binding aspect performs uni-directional data binding of commands. For HTML5 SPAs this can be, for instance, the reaction upon a “reset” or “resize” command.The Component Aspects are the most prominent part of MVC/CT in prac-tice.Figure 6.22: MVC/CT Step 2: Component LayersViewModelControllerServiceViewMaskViewBindingPresentationLogicPresentationModelPresentationControlBusinessServiceBSPCPMPLVBVMHierarchical Dialog Architecture: Model-View-Controller/Component-Tree (MVC/CT)159 ■State Binding (SB): The active State Binding aspect performs unidirectional data binding of states. For HTML5 SPAs this can be, for instance, the CSS binding of a state indicating selection, activation or error. Notice the im-portant distinction between data (e.g., a password input field value) and states (e.g., the validity state of the password input field). ■Data Binding (DB): The active Data Binding aspect performs bidirectional data binding of domain data. For HTML5 SPAs this can be, for in-stance, the DOM binding of input field values. Notice, the Data Binding is the only data binding which is really bidirectional. ■Event Binding (EB): The active Event Binding aspect performs uni-directional data binding of events. For HTML5 SPAs this can be, for instance, the reaction upon DOM events like button clicks or list item selections. Notice, as the View Component has no The Event Binding to plain Event Values in the Presentation Model, in-stead of a direct action-ing in the Controller, is one of MVC/CT’s distinct features. It especially sup-ports the strict Separa-tion of Concerns.Figure 6.23: MVC/CT Step 3: Component AspectsView MaskParameterValuesStateValuesDataValuesBusinessModelBusinessLogicCommandBindingDataBindingEventBindingStateBindingPresentationLogicEventValuesPresentationProvisioningPresentationActioningViewModelControllerServiceSBViewMaskViewBindingPresentationLogicPresentationModelPresentationControlBusinessServiceDBEBVMPLSVDVEVPPPABMBLBSPCPMPLVBVMCommandValuesPVMaskRenderingCBCVMRNext >