< PreviousChapter 5: State of the Art80put devices. Both are handled by the View Component, so the Controls, In-teractions, and Events at least target the dedicated View Component only. However, HMVC addresses no separation between the three aspects. It just does not prohibit the separation of these three aspects. ■[REQ-F5] Dialog-Level Structuring: VERY GOOD: HMVC motivates the struc-turing of the User Interface at the level of individual Dialogs and the hier-archy they live in. ■[REQ-F6] Dialog Life-Cycle and States: POOR: HMVC does not explicitly support a flexible custom life-cycle of Dialogs, although it could be estab-lished around it. ■[REQ-C1] HTML5 Single-Page-Application Approach: GOOD: HMVC can be used just fine for HTML5 Single-Page-Applications as long as the View Component renders the View Mask into the Document Object Model (DOM) and can coordinate this rendering with both parent and child instances of the HMVC’s MVC Triads. The challenge is that in HMVC this parent and child Figure 5.4: Evaluation Results of Hierarchical-Model-View-Controller (HMVC) Pattern0%1-19%20-39%40-59%60-79%80-99%100%NOT AT ALLVERY POOR POORACCEPTABLEGOODVERY GOODPERFECTNDNA0123456REQ-F3Separation of Mask, Style, and BehaviourREQ-F4Separation of Controls, Interactions, and EventsREQ-F5Dialog-Level StructuringREQ-F6Dialog Life-Cycle and StatesREQ-C1HTML5 Single-Page-Application ApproachREQ-C3Potential Offline OperationREQ-C4Near-Real-Time UpdatesREQ-A1Separation of Model, View, and ControlREQ-A2Distinguished Presentation ModelREQ-A3Dialog Instantiation and ReusabilityREQ-A4Dialog-Level Component-OrientationREQ-A5Hierarchical Dialog CommunicationREQ-A6Transitive Dialog CommunicationREQ-D2Hierarchical Development-Time Dialog De-CompositionREQ-D3Distributed Orchestration of Run-Time Dialog Re-CompositionREQ-D4Event-Driven ArchitectureREQ-E1Potential Web Technology IndependenceREQ-E4Head-Less Run-Time TestingREQ-E5Massive Dialog ScalabilityREQUIREMENT ATTAINMENTNOT DETERMINABLENOT APPLICABLEModel-View Separation Patterns81communication cannot be done directly by the View Component and in-stead has to be delegated to the Controller Component. ■[REQ-C3] Potential Offline Operation: VERY GOOD: HMVC holds all its in-formation in the Model Component and is not directly tied to any corre-sponding Back-End communication. It is outside the scope of HMVC how the information is coming from the Back End to the Model Component. ■[REQ-C4] Near-Real-Time Updates: VERY GOOD: HMVC holds all its informa-tion in the Model Component, and it actively triggers updates on the View Component. Hence it can potentially support near-real-time updates just fine. ■[REQ-A1] Separation of Model, View, and Control: PERFECT: HMVC, similar to MVC, explicitly distinguishes between and separates Model, View and Control aspects of the User Interface. ■[REQ-A2] Distinguished Presentation Model: GOOD: HMVC does not distin-guish between a Presentation Model and the underlying Domain Model. HMVC just has the single Model Component, but this can be considered a Presentation Model as it is locally scoped to the MVC Triad of HMVC and is not a pre-existing global instance. However, HMVC does not explicitly address the distinction between Presentation Model and Domain Model. ■[REQ-A3] Dialog Instantiation and Reusability: GOOD: HMVC just states that the Model, View, and Controller Components are instantiated, starting with the Controller Component. However, it is not stated by HMVC wheth-er the implementation of those three Components has to allow or just can allow multiple instantiations and reusability. HMVC at least does nothing explicitly to support multiple instantiations and reusability, but it helps that its Model Component is local to the MVC Triad. ■[REQ-A4] Dialog-Level Component-Orientation: VERY GOOD: HMVC does explicitly focus on the Dialog level. Hence with HMVC, one can use Dialog-level Component-Orientation by treating the MVC Triad as a grouping Di-alog Component. ■[REQ-A5] Hierarchical Dialog Communication: GOOD: In HMVC the Controller Component knows about the parent and child Controller Components. This forms the hierarchy of MVC Triads, and one could communicate along this hierarchy. However, HMVC itself does not give any further information about how this com-munication should be done. ■[REQ-A6] Transitive Dialog Communication: NOT AT ALL: In HMVC the Con-troller Component knows about the parent and child Controller Compo-nents. However, there is no notion of any transitive communication be-tween those Controller Components.Although HMVC has the notion of a hierarchy, it has no built-in notion of transitive hierarchical communication.Chapter 5: State of the Art82 ■[REQ-D2] Hierarchical Development-Time Dialog De-Composition: VERY GOOD: In HMVC the Controller Component knows about the parent and child Controller Components. This forms the hierarchy of MVC Triads which allows the decomposition of an entire User Interface into distinct Dialogs and implementing each Dialog with an MVC Triad. ■[REQ-D3] Distributed Orchestration of Run-Time Dialog Re-Composition: VERY POOR: In HMVC the Controller knows about the parent and child Con-trollers. However, HMVC does not state how to re-compose a User Inter-face from this hierarchy of Controllers. Notably, it does nothing explicitly to support the distributed orchestration for the hierarchical re-composition of the User Interface during run time. ■[REQ-D4] Event-Driven Architecture: POOR: In HMVC the View Component supports the direct mapping of user Dialog interactions onto correspond-ing programmatic events which are then delegated to the Controller Com-ponent. However, any updates to the Model Component require a direct call to the View Component, as HMVC does not use an Observer pattern on the Model Component. Hence, the support for Event-Driven Architecture is rather limited. ■[REQ-E1] Potential Web Technology Independence: PERFECT: HMVC can be used perfectly in both Web and non-Web technology contexts as it is in no way tied to one of those contexts at all. It was even originally invented outside the Web context for Java Swing applications. ■[REQ-E4] Head-Less Run-Time Testing: GOOD: In HMVC, in contrast to MVC, the entire connection to the input/output devices is at the View Com-ponents, and the entire User Interface structure is primarily handled by the Controller Components. This would allow head-less testing, although HMVC has no explicit support for it. ■[REQ-E5] Massive Dialog Scalability: VERY GOOD: HMVC’s main feature is the hierarchy of MVC Triads to address the management of the entire User Interfaces and not just single Dialogs. This hierarchy, at least in theory, can scale just arbitrarily.Pattern JudgementHierarchical Model-View-Controller (HMVC) is a decent idea to extend the scope of MVC to the User Interface (UI) as a whole by taking the hierarchical composition of the UI into account. However, HMVC fails in two major aspects: ■Optional Controller: The Controller, although the primary pattern aspect and the creator of the MVC Triad, is considered optional. In this case, the parent Controller has to manage the Model and View. This breaks both the carefully established hierarchy layering and introduces hard to compre-hend special cases into the code.Model-View Separation Patterns83 ■Asymmetric Data Flow: There is an asymmetry in the data flow: the View does not know the Model and hence has to update the Model via the Con-troller, but the Model knows and updates the View directly. Compare the description and example source codes in [Cia et al. 2000a] for details on these two aspects.5.1.3 Presentation-Abstraction-Control (PAC)Pattern OriginThe Presentation-Abstraction-Control (PAC) software architecture pattern was in-troduced in 1987 by [Coutaz 1987]. In [Nigay & Coutaz 1991] practical experiences with PAC were published. In [Coutaz 1997] and [Calvary & Coutaz 1997] the single-user system focused PAC was further extended into the multi-user system focused PAC* pattern variant. For details on PAC in particular contexts, like mobile applications, see [Plakalovic & Simic 2010].PAC can be considered a superset of HMVC, al-though it was invented earlier and has a wider scope.AbstractionPresentationInput/OutputDevicesread/updaterendernotifyApplication,PAC-Entity,PAC-Object,Compound Object,Interactive ObjectupdateupdatedXComponentKnowledgeRelationshipRun-TimeCallRun-TimeCall-BackupdatedSub-PAC-Entitycontroller*ControlLogicalSub-PAC-EntitycontrolFigure 5.5: Presentation-Abstraction-Control (PAC) PatternChapter 5: State of the Art84Pattern DescriptionFigure 5.5 on page 83 shows a summarizing illustration of the PAC pattern. The PAC pattern is similar to HMVC (see Subsection 5.1.2 on page 77). Actually, it can be considered a super-set of HMVC, as it is more general and has a broader scope. At heart, similar to MVC (see Subsection 5.1.1 on page 72), it also consists of a Component Triad: ■The Presentation Component is very similar to the MVC View Component. It handles the input/output and represents the “syntax.” ■The Abstraction Component is somewhat similar to the MVC Model Com-ponent. It represents the “semantics” and implements “the functions that the application is able to perform” [Coutaz 1987] and also contains the “ab-stract entities.” [Coutaz 1987]. ■The Control Component is very similar to the MVC Controller Component. It manages and maps between the Presentation and Abstraction Compo-nent. It can be considered a form of bi-directional data binding between Presentation and Abstraction Components. Additionally, the Control Com-ponent exclusively handles the hierarchical communication between the Component Triads.A few major differences between HMVC and PAC should be noted: ■Hierarchy Linking: For HMVC it is explicitly noted that the Controller Com-ponent has a direct link to the parent Controller Component, while for PAC no such direct link seems to exist. ■Hierarchy Duality: Although in PAC the hierarchy of Component Triads “physically” manifests in the links between the Control Components, PAC “logically” sees the nesting at the Presentation Component level. It is as-sumed that this follows the intuitive optical de-composition of a User In-terface. ■Pattern Scope: PAC is a generic de-composition pattern which is intended to be applied at the application level, the User Interface level, the Dialog level and the Widget level. ■Pattern Terminology: When applied at the application level, the Compo-nent Triad is just called the “Application.” When applied at the Dialog or Widget Level, the Component Triad is called “Compound Object.” When applied at the Widget level, the Component Triad is called “Interactive Ob-ject.” In all other cases, the Component Triad is just called “PAC Entity” or “PAC Object.” In [Calvary & Coutaz 1997] the Component Triad is even called “Agent.” ■Presentation and Abstraction Insulation: There is no knowledge or even direct communication between the Presentation and Abstraction Compo-nents. Instead, the Control Component establishes the Component Triad, Model-View Separation Patterns85and every communication between the Presentation and Abstraction Component flows through the Control Component.Pattern EvaluationThe evaluation of the Presentation-Abstraction-Control (PAC) software architecture pattern against the subset of our Requirements Suite (see Section 4.2 on page 61) one can find in Figure 5.6 on page 85. ■[REQ-F3] Separation of Mask, Style, and Behaviour: VERY GOOD: PAC clearly distinguishes between Presentation and Control Components, so inher-ently separates at least the Mask and Style from the Behaviour. Whether Mask and Style are also separated is not addressed by PAC, but at least not explicitly prohibited and hence also possible. ■[REQ-F4] Separation of Controls, Interactions, and Events: VERY POOR: PAC does not address any separation between these three aspects. It just does not prohibit the separation of these three aspects.0%1-19%20-39%40-59%60-79%80-99%100%NOT AT ALLVERY POOR POORACCEPTABLEGOODVERY GOODPERFECTNDNA0123456REQ-F3Separation of Mask, Style, and BehaviourREQ-F4Separation of Controls, Interactions, and EventsREQ-F5Dialog-Level StructuringREQ-F6Dialog Life-Cycle and StatesREQ-C1HTML5 Single-Page-Application ApproachREQ-C3Potential Offline OperationREQ-C4Near-Real-Time UpdatesREQ-A1Separation of Model, View, and ControlREQ-A2Distinguished Presentation ModelREQ-A3Dialog Instantiation and ReusabilityREQ-A4Dialog-Level Component-OrientationREQ-A5Hierarchical Dialog CommunicationREQ-A6Transitive Dialog CommunicationREQ-D2Hierarchical Development-Time Dialog De-CompositionREQ-D3Distributed Orchestration of Run-Time Dialog Re-CompositionREQ-D4Event-Driven ArchitectureREQ-E1Potential Web Technology IndependenceREQ-E4Head-Less Run-Time TestingREQ-E5Massive Dialog ScalabilityREQUIREMENT ATTAINMENTNOT DETERMINABLENOT APPLICABLEFigure 5.6: Evaluation Results of Presentation-Abstraction-Control (PAC) PatternChapter 5: State of the Art86 ■[REQ-F5] Dialog-Level Structuring: VERY GOOD: PAC motivates the struc-turing of the User Interface at the level of individual Dialogs and the hier-archy they live in. ■[REQ-F6] Dialog Life-Cycle and States: POOR: PAC does not explicitly sup-port a flexible custom life-cycle of Dialogs, although it could be estab-lished around it. ■[REQ-C1] HTML5 Single-Page-Application Approach: ACCEPTABLE: PAC can be used just fine for HTML5 Single-Page-Applications as long as the Presen-tation Component renders the View Mask into the Document Object Model (DOM) and can coordinate this rendering with both parent and child in-stances of the PAC Component Triads. The challenge is that in PAC this par-ent and child communication cannot be done directly by the Presentation Component and instead has to be delegated to the Control Component. Additionally, the Control Component seems not to have any direct link to its parent Control Component. ■[REQ-C3] Potential Offline Operation: VERY GOOD: PAC holds all its infor-mation in the Abstraction Component and is not directly tied to any corre-sponding Back-End communication. It is outside the scope of PAC how the information is coming from the Back End to the Abstraction Component. ■[REQ-C4] Near-Real-Time Updates: VERY GOOD: PAC holds all its informa-tion in the Abstraction Component, and it actively maps updates to the Presentation Component via the Control Component. Hence it can poten-tially support near-real-time updates. The Control Component, in this case, acts as a bi-directional data-binding. ■[REQ-A1] Separation of Model, View, and Control: PERFECT: PAC, similar to MVC, explicitly distinguishes between and separates Model (via Abstrac-tion Component), View (via Presentation Component) and Control aspects of the User Interface. ■[REQ-A2] Distinguished Presentation Model: GOOD: PAC does not distin-guish between a Presentation Model and the underlying Domain Model. PAC just has the single Abstraction Component, but this can be considered a Presentation Model as it is locally scoped to the Component Triad of PAC and is not a pre-existing global instance. However, PAC does not explicitly address the distinction between Presentation Model and Domain Model. ■[REQ-A3] Dialog Instantiation and Reusability: GOOD: PAC just states that the Abstraction, Presentation, and Control Components are instantiated, starting with the Control Component. However, it is not stated by PAC whether the implementation of those three Components has to allow or just can allow multiple instantiations and reusability. PAC at least does nothing explicitly to support multiple instantiations and reusability, but it helps that its Abstraction Component is local to the Component Triad.Model-View Separation Patterns87 ■[REQ-A4] Dialog-Level Component-Orientation: VERY GOOD: PAC does ex-plicitly focus on the Dialog level. Hence with PAC, one can use Dialog-level Component-Orientation by treating the Component Triad as a grouping Dialog Component. In PAC it is usually named Compound Object. ■[REQ-A5] Hierarchical Dialog Communication: POOR: In PAC the Control Component knows about the child Control Components. This forms the hierarchy of Component Triads, and one could communicate along this hierarchy downwards. However, PAC itself does not give any further in-formation about how this communication should be done in particular. Additionally, as the Control Component seems not to have a link to the parent Control Component, there is no chance for communicating along this hierarchy upwards. ■[REQ-A6] Transitive Dialog Communication: NOT AT ALL: In PAC the Control Component knows about the child Control Components. However, there is no notion of any transitive communication between those Control Com-ponents. ■[REQ-D2] Hierarchical Development-Time Dialog De-Composition: VERY GOOD: In PAC the Control Component knows about the child Control Com-ponents. This forms the hierarchy of Component Triads which allows the decomposition of an entire User Interface into distinct Dialogs and imple-menting each Dialog with a Component Triad. ■[REQ-D3] Distributed Orchestration of Run-Time Dialog Re-Composition: VERY POOR: In PAC the Control Component knows about the child Con-trol Components. However, PAC does not state how to re-compose a User Interface from this hierarchy of Control Components. Especially, it does nothing explicitly to support the distributed orchestration for the hierar-chical re-composition of the User Interface during run time. ■[REQ-D4] Event-Driven Architecture: GOOD: In PAC the Presentation Com-ponent supports the direct mapping of user Dialog interactions onto cor-responding programmatic events which are then delegated to the Con-trol Component. Additionally, as neither the Abstraction nor Presentation Components directly know about the Control Component, it has to be as-sumed that in PAC an Observer pattern is used for both the Abstraction and Presentation Components. This supports Event-Driven Architecture just fine. ■[REQ-E1] Potential Web Technology Independence: PERFECT: PAC can be used perfectly in both Web and non-Web technology contexts as it is in no way tied to one of those contexts at all. It was even originally invented outside the Web context for native GUI applications. ■[REQ-E4] Head-Less Run-Time Testing: GOOD: In PAC, in contrast to MVC, the entire connection to the input/output devices is at the Presentation Chapter 5: State of the Art88Components and the entire User Interface structure is primarily handled by the Control Components. This would allow head-less testing, although PAC has no explicit support for it. ■[REQ-E5] Massive Dialog Scalability: VERY GOOD: PAC’s main fea-ture is the hierarchy of Component Triads to address the management of entire User Interfaces and not just single Dialogs. This hierarchy, at least in theory, can scale just arbitrarily.Pattern JudgementPresentation-Abstraction-Control (PAC) is a very decent idea to extend the scope of MVC to the User Interface (UI) and even the entire application as a whole, by taking the hierarchical composition of the UI into account. PAC just fails in two ways: ■Confusing Terminology: Its terminology, where the Component Triad has nearly arbitrary names depending on the current context, is rather confus-ing. ■Outdated Controller Role: The Control Component fully isolates the Ab-straction and Presentation Components, and both have no knowledge about both the Control Component and the Component Triad hierarchy. As a consequence, the Control Component has to both map data back and forth between the Abstraction and Presentation Components and man-age the hierarchy. For the first task, nowadays bi-directional data-binding mechanisms are the preferred approach. For the second task, nowadays surrounding frameworks are the preferred approach. 5.1.4 Model-View-Adapter (MVA)Pattern OriginThe Model-View-Adapter (MVA) software architecture pattern, unfortunately, has no clear origin and was documented in various contexts [Borini 2017] [Apple 2012]. It is a variant of MVC, which especially was made popular by User Interface frame-works like Apple Cocoa [Apple 2012]. Sometimes this pattern is alternatively named “Mediating-Controller MVC.”Pattern DescriptionFigure 5.7 on page 89 shows a summarizing illustration of the MVA pattern. The MVA pattern is very similar to MVC (see Subsection 5.1.1 on page 72). Actually, it can be considered just a slight but essential variation of MVC with the following major changes: ■Model and View Insulation: The knowledge between View and Model Components is fully broken up, and the Controller Component is replaced PAC can be applied in various contexts and then its parts receive dif-ferent names. This makes it hard to understand the pattern.Model-View Separation Patterns89with an Adapter Component implementing the Mediator pattern. As a consequence, all data and control flow goes through the Adapter Com-ponent. One can consider the Adapter Component the implementation of a bi-directional data-binding mechanism between View and Model Com-ponents. ■Adapter-Driven: As only the Adapter Component has knowledge about the View and Model Components, the pattern is now instantiated starting with the Adapter Component. ■GUI Code Centralization: The entire input/output device handling is now located at the View Component only. As a consequence, the code for ren-dering and reacting upon the Graphical User Interface (GUI) is now central-ized. ■Related Component Triads: Although not explicitly stated for MVA, but as it is a direct variant of MVC, the Adapter Component seems to know about other Adapter Components, and the View Component knows at least about their parent/super View Component.ModelViewAdapterInput/OutputDevicesother adapter**read/updateread/updaterendernotifyupdatedupdatedXComponentKnowledgeRelationshipRun-TimeCallRun-TimeCall-Backsuperview**Figure 5.7: Model-View-Adapter (MVA) PatternNext >