< PreviousChapter 2: Foundations40usually used [Gamma et al. 1994] . The result is a so-called Loose Coupling [Stevens et al. 1974] [Constantine & Yourdon 1979].Although Loose Coupling, in general, provides great benefits from an archi-tectural point of view, it has its price: all de-coupling approaches cause additional complexity. Hence, while Loose Coupling makes sense between multiple Compo-nents and there one usually is willing to pay the price, it makes no sense also strictly to apply it within a single Component. Instead, there Strong Cohesion of the inter-nals is strived for [Stevens et al. 1974] [Constantine & Yourdon 1979].2.3.6 Application Programming Interface (API)An Application Programming Interface (API) is the well-defined, shielding and ab-stracting boundary of a Component, consisting of one or more distinguished and exposed operations, each operating under a certain syntactical and semantical contract. In the context of Object-Oriented Programming (OOP, [Armstrong 2006]), during development time, the operations are functions and are called “methods.”Figure 2.4: Domain Model of Data ModelData Modelto-classAttribute+ReferenceScalarClass+Data Model412.4 Data ModelModels are not right or wrong; they are more or less useful. — Martin Fowler, “Analysis Patterns: Reusable Object Models”A Data Model is a Type Definition of a Data Structure, based on an Ab-straction of a certain domain. It is a passive Component in the sense that it provides just operations to manipulate the Data Structure and no operations which control any application flow. Sometimes these Com-ponents are also known as Anemic Domain Models [Fowler 2003]. See Figure 2.4 on page 40 for an illustration of the domain model of the Data Model.2.4.1 Abstraction and Data StructureA Data Model, like any other type of model, is an Abstraction of a certain domain-specific context. This Abstraction is defined as a Data Structure, usually some kind of higher-level Record, Structure or Class and consisting of lower-level Scalars. The Data Model usually has specific operations defined which allow the reasonable ma-nipulation of the Data Structure on a Scalar level.2.4.2 Type DefinitionIn the context of Object-Oriented Programming (OOP), the Data Model is a Class of Scalars (here called fields or attributes) and References (here called relationships). It usually forms a custom type in the type system of the underlying programming environment. An example of a Data Model, defined in a fictional Domain-Specific Language, might be:type Person { firstName string lastName string Although Anemic Do-main Models sometimes are considered Anti-Pat-terns, in the context of User Interfaces and the resulting Presentation Models, this is not the case.Componentfrom-stateStateTransitionComponentLife-CycleState+to-statehas*defined-byFigure 2.5: Domain Model of Component Life-Cycle42 supervisor Person orgUnit OrgUnit+ } type OrgUnit { name string manager Person employees Person* }2.5 Component Life-CycleEverything has a cycle and a season. — Tyrone William Griffin Jr. (Ty Dolla Sign)Components can have State and this way form a Finite State Machine where the Life-Cycle of the Component is caused by sequential State Transitions over time. See Figure 2.5 on page 41 for an illustration of the domain model.2.5.1 Finite State Machine and State TransitionsA Component can have zero or more States. The State of a Component is a Scalar of an underlying Data Structure, defined as an enumeration of one or more dis-tinct State values. Manipulation of the State Scalar logically causes a State Transition of the Component. The State Values and the State Transition between those State Values implicitly define a Finite State Machine.An example of a State definition, in a fictional Domain-Specific Language (DSL), might be:type Component { state: State = { DEAD, CREATED, CONFIGURED, PREPARED, MATERIALIZED, VISIBLE, READY } ... }2.5.2 Time and Life-CycleThe sequence of State Transitions of a Component over the time implicitly defines the Life-Cycle of the Component. This Life-Cycle usually starts with a special initial State Value (for instance CREATED), then changes arbitrary times between regular State Values (for instance CONFIGURED, PREPARED, MATERIALIZED, VISIBLE and READY) and finally reaches a special terminating State Value (for instance DEAD).In HUICA, stateful Com-ponents with a Life-Cycle play a major role. Chapter 3ContextChapter 3: Context44Chapter Contents3.1 Application User Interface .................................................. 453.1.1 Front End of Application ............................................ 453.1.2 Presentation Tier of Deployment .................................. 463.1.3 Client Role of Communication ..................................... 463.2 Rich-Client Architecture ..................................................... 473.2.1 Autonomous User Interface Rendering .......................... 473.2.2 Rich User Interaction ................................................ 483.2.3 Server Off-Loading .................................................. 483.2.4 Potential Offline Operation ......................................... 483.3 Web Technology Standards ................................................ 493.3.1 HyperText Markup Language (HTML) for Structure ............ 493.3.2 Cascading Style-Sheets (CSS) for Style ........................... 503.3.3 Document Object Model (DOM) as Run-Time Platform ....... 513.3.4 JavaScript/ECMAScript for Behaviour ............................ 513.4 HTML5 Single-Page-Application (SPA) Approach ...................... 533.4.1 Dynamic User Interface Rendering ............................... 533.4.2 Domain-Only Network Communication ......................... 543.4.3 Server-Sent Events ................................................... 543.4.4 Built-Time Artifact Bundling ........................................ 553.4.5 On-The-Fly Loading or On-Device Deployment ................ 56Application User Interface453.1 Application User InterfaceAs far as the customer is concerned, the interface is the product. — Jef RaskinThe User Interface (UI) of an Application is its user-facing Front End. In the context of Multi-Tier Architecture, the UI comprises the Presentation Tier. In communica-tion, the UI plays the Client role. The Hierarchical User Interface Component Archi-tecture (HUICA) targets Front Ends, comprising Presentation Tiers and communi-cating in the Client role.3.1.1 Front End of ApplicationAn application can be logically split into a Front End and Back End part (see Figure 3.1 on page 45). The former is the user-facing part of the application, where the User Interface is presented and which can be used by the User for inter-acting with the application. The latter is the data storage facing part of the application, where data is processed and persisted. The domain logic is usually considered part of the Back End, but it is also acceptable that a smaller part of the domain logic is also part of the Front End. Notice, the Front End / Back End concept usually is just a logical tagging of the two main parts of an application and is not directly tied to the individual programs, processes or even deployment locations of the application as a whole [Rouse 2006]. For instance, in a Thin-Client Architecture, the UI is usually the Front End, but it is even part of the server program (while the client program is the generic browser).Frontend/Backend is a logical concept, Tier is a physical concept and Cli-ent/Server is a role con-cept.ApplicationBack EndFront EndUserInterfaceDataStorageDomainLogicFigure 3.1: Logical Front End / Back End conceptChapter 3: Context463.1.2 Presentation Tier of DeploymentAn Application can be physically split into multiple deployment units (see Figure 3.2 on page 46). In a Multi-Tier Architecture, the User Interface comprises the unit which is deployed to the Presentation Tier — in contrast to the Business Tier (aka Service Tier or Domain Tier) and the Persistence Tier (aka Data Tiers).Notice, the Tier concept is not identical to the Layer concept in Software Ar-chitecture. A Layer is a logical concept, while a Tier is primarily a physical concept [Siedersleben 2003] [Liu & Ozsu 2009].3.1.3 Client Role of CommunicationAs a result of splitting an application into individual deployment units in a Mul-ti-Tier Architecture, network communication is required between the individual units. The User Interface in the Presentation Tier traditionally then takes the com-munication role of the Client while the part of the application in the Business Tier takes the role of the Server (see Figure 3.3 on page 46).ClientServer1. Request2. ResponseFigure 3.3: Client/Server communication rolePresentationTierPersistenceTierBusinessTierFigure 3.2: Physical Tier conceptRich-Client Architecture473.2 Rich-Client ArchitectureArchitecture is the will of an epoch translated into space. — Ludwig Mies van der RoheWhen the User Interface (UI) of an application comprises the Front End, is deployed to the Presentation Tier, plays the Client communication role, it can provide Au-tonomous User Interface Rendering, Rich User Interaction, Server Offloading and even Potential Offline Operation (see Figure 3.4 on page 47). In this case, the ap-plication uses a Rich-Client Architecture for its UI. As already mentioned in subsec-tion 1.1.1 on page 21, this is the currently most dominant UI architecture since the year 2010. 3.2.1 Autonomous User Interface RenderingIn the Rich-Client Architecture, the User Interface is a dedicated deployment unit of the Front End, having to communicate with the Back End over a network. As this communication should be reduced to its minimum, to not cause any UI latency, instead of UI Masks only domain data is transferred. As a conse-quence, the Front End fully autonomously and locally renders the entire UI Mask and can provide a high User Experience.The autonomous render-ing of the UI is the most prominent property of the Rich-Client Architec-ture.Figure 3.4: Rich-Client ArchitecureApplicationBack-End /(Thin-)ServerFront-End / Rich-ClientUserInterfaceDataStorageDomainLogicDomainLogicChapter 3: Context483.2.2 Rich User InteractionAs a side-effect of the Autonomous User Interface Rendering, the UI can have high responsiveness and supports Rich User Interaction. This means that keyboard key-strokes, mouse gestures, touch gestures, speech input, and any other form of inter-action are supported. It usually also means that a rich multimedia presentation is used, although this is not a requirement.Notice, the Rich User Interaction concept is all about the rich interaction mod-el, while Adobe/Macromedia’s old similar-named Rich Internet Application (RIA) con-cept is both about the rich interaction model and the rich multimedia presentation.3.2.3 Server Off-LoadingAs the Front End on the Presentation Tier is usually running on a dedicated graphi-cal device and mostly all those devices today even have multiple mid-power CPUs, the off-loaded Autonomous User Interface Rendering and Rich User Interaction dramatically reduces the load on the Back End of the application. This Server Off-Loading allows the Rich-Client Architecture to leverage from the distributed computing powers and the inherent fact that an application has just a few Back-End instances (think about load-balancing and high-availability set-ups) and a myriad of Front-End instances (think about the number of users).3.2.4 Potential Offline OperationUsually, the Presentation Tier is a device belonging to the user and users today of-ten use mobile devices. Although mobile devices today usually have good Internet connectivity, because of physical roaming and location changes, their connectivity is regularly interrupted.As a consequence, the User Interface in a Rich-Client Architecture is required to autonomously resolve and reconnect to its Back End and at least potentially con-tinue to work reasonably during the temporary offline situations.Web Technology Standards493.3 Web Technology StandardsThe advance of technology is based on making it fit in so that you don’t really even notice it, so it’s part of everyday life. — Bill GatesIn the 1970th the User Interface (UI) was all about text and terminals. In the 1980th the UI was all about graphics and workstations. In the 1990th the UI was all about the Internet and its HyperMedia-based Web. Since 2000 the UI is all about the Web and its ultimate run-time platform of extremely powerful browsers. For many years, the Web Technologies are now the most dominant and feature-wise unbeatable technologies for implementing all kinds of UIs. Although there are dozens of individual Web Technology Standards for imple-menting UIs, the most prominent ones are the HyperText Markup Language (HTML) for the UI structure, the Cascading Style-Sheets (CSS) for the UI style and JavaScript/ECMAScript for the UI behavior.3.3.1 HyperText Markup Language (HTML) for StructureThe HyperText Markup Language (HTML, [Faulkner et al. 2017] [Robbins 2009] [Ho-gan 2011]), during development time, declaratively describes the structure of the User Interface (UI). It manifests itself, during run time, as the structure of the Docu-ment Object Model (DOM, see subsection 3.3.3 on page 51). A simple UI Mask of a login dialog, in plain HTML, is:<form id=”login”> <label for=”un”>Username:</label> <input id=”un” name=”username” type=”text”></input> <label for=”pw”>Password:</label> <input id=”pw” name=”password” type=”password”></input> <input type=”submit” value=”Login”></input> </form>As plain HTML (of the current HTML version 5.2, as of 2017) does not sup-port macros, expression interpolation, variable binding and similar use-ful constructs, nowadays higher-level languages, like VueJS, Nunjucks or Handlebars, are used. As the current browsers just support plain HTML during run time, these higher-level languages are “transpiled”, during build time, Web Technologies are the unbeatable technolo-gies for implementing UIs since over a decade.HTML was originally inspired by SGML, but later re-formulated and aligned to XML.Next >