< Previous301.4 Typographical Conventions of DissertationFashion has always been in conflict with convention. Style involves some knowledge of both. — Russel SmithIn this dissertation, the following typographical conventions are used for text: ■Headlines: headlines are set in color and in bold. Example: Foo bar quux. ■Regular Text: regular body text is set without any style. Example: Foo bar quux. ■Internal Fixed Term: fixed terms used internally to this dissertations are set with capitalized first letters of all words. Example: Foo Bar Quux. ■External Fixed Term: fixed terms defined externally to this dissertation are set in italics and with capitalized first letters of all words. Example: Foo Bar Quux. Most can be found in [IEEE 1990], [Bourque & Fairley 2014] or [Rechen-berg & Pomberger 2006]. ■Source Code: source text is set in color and a mono-spaced font. Example: Foo Bar Quux. ■Anchors: anchors and references to an internal text are set as numbers within circles: Example: 7. ■References: references to external resources are set in brackets and with the text set in “small caps.” Example: [Foo Bar Quux 1972].Diagrams are drawn either in the well-defined Unified Modeling Language (UML) [Booch et al. 2017] [Rumpe 2016] [Rumpe 2017] [Pilone & Pitman 2005] [Miles 2006] [Pi-lone 2006], if knowledge and precision is the primary goal, or in a freestyle “boxes and lines” notation, if illustration and understanding is the primary goal. Most of the time, the diagrams document various Software Architecture views [Clements et al. 2010] [Rozanski & Woods 2011] [Starke & Hruschka 2016].IIPartFoundations and ContextChapter 2FoundationsChapter 2: Foundations34Chapter Contents2.1 User Interface ................................................................. 352.1.1 Mask, Style, and Data ................................................ 352.1.2 Controls, Interactions, and Events ................................. 362.2 User Interface Dialog ........................................................ 372.2.1 Bounded Domain Context ......................................... 372.2.2 Hierarchical Composition and User Interface Fragments ..... 372.3 Object-Oriented Component .............................................. 382.3.1 Development-Time Class and Run-Time Objects ............... 382.3.2 Structuring and Mastering Complexity .......................... 392.3.3 Separation of Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.3.4 Knowledge Encapsulation and Information Hiding ............ 392.3.5 Loose Coupling and Strong Cohesion ............................ 392.3.6 Application Programming Interface (API) ........................ 402.4 Data Model .................................................................... 412.4.1 Abstraction and Data Structure ................................... 412.4.2 Type Definition ....................................................... 412.5 Component Life-Cycle ....................................................... 422.5.1 Finite State Machine and State Transitions ...................... 422.5.2 Time and Life-Cycle .................................................. 42User Interface352.1 User InterfaceA user interface is like a joke. If you have to explain it, it’s not that good. — Martin LeBlancThe User Interface (UI) is the user-facing side of an application. It consists of a vis-ible Mask with Style and State, contained Controls for Interaction and emitted Events. Each of those foundational aspects is briefly introduced in the following and illustrated as a domain model in Figure 2.1 on page 35.2.1.1 Mask, Style, and DataThe Mask of the User Interface (UI), in general, is the surface of the UI. More specifi-cally, it is usually the term used for just the hierarchical, graphical structure of the UI surface, in contrast to its Style and Data. In the context of Web Technologies (see section 3.3 on page 49), the Mask is described during development time via the Hyper-Text Markup Language (HTML, see subsection 3.3.1 on page 49 and [Faulkner et al. 2017]) and manifests itself during run time as the struc-ture of the Document Object Model (DOM, see subsection 3.3.3 on page 51 and [Wilson et al. 2000]).The Style of the UI, in general, is the optical appearance of the UI. More specifi-cally, it is usually the term used for the graphical layouting, shaping, enabling and A User Interface consists of the structuring Mask, the optical Style and the domain Data.Figure 2.1: Domain Model of User InterfaceUser Interfaceemitted-onMaskStyleDataHTMLCSSDOMControlInteractionEventleads-toallowsdefinesdefinesdefines+****+**0..1Chapter 2: Foundations36coloring of the UI surface, in contrast to its Mask and Data. In the context of Web Technologies, the Style is described during development time via Cascading Style-Sheets (CSS, see subsection 3.3.2 on page 50 and [Bos et al. 2011] and [Celik et al. 2011]) language and manifests itself under run time as the graphical properties of the DOM.The Data of the User Interface, in general, is the set of all domain values of all Mask elements. In the context of Web Technologies, the Data is the set of all domain value properties of the HTML elements in the DOM. 2.1.2 Controls, Interactions, and EventsControls, in other contexts sometimes also called Widgets (a combination of “Win-dow” and “Gadget”), are graphical input elements, which allow the user to perform his Interactions. In the context of Web Technologies (see section 3.3.1 on page 49), they are represented by HTML input elements in the Mask. Interaction is a manual action the user performs when working with a User Interface. It can be based on the operation of Controls, but it can be also based on key-strokes, mouse-gestures, or touchscreen-gestures. In the context of Web Technologies (see section 3.3.3 on page 51), all Interactions manifest as corresponding emitted Events on the Document Object Model (DOM).An Event is an emitted information object to indicate that an Interaction in a User Interface occurred. Interested parties can subscribe to those Events in order to perform certain domain-specific actions. In the context of Web Technologies (see section 3.3.4 on page 51), JavaScript [Terlson 2017] code is used to subscribe to Events which are emitted on the DOM.Users interact with the User Interface through Controls, which then emit programmatic Events.Figure 2.2: Domain Model of User Interface DialogUser InterfaceUser InterfaceFragmentBoundedDomain Contextchild-dialogDialog++*child-fragmentbelongs-toUser Interface Dialog372.2 User Interface DialogThe ability to improve a design occurs primarily at the interfaces (Shea’s Law). This is also the prime location for screwing it up. — Akin’s Laws of Spacecraft DesignThe Dialog is the primary design unit for User Interfaces (UI). It covers a particu-lar Bounded Domain Context, is part of the Hierarchical Composition of the UI and manifests itself as a hierarchy of one or more nested UI Fragments in the UI Mask. See Figure 2.2 on page 36 for an illustration of the domain model.2.2.1 Bounded Domain ContextThe Dialog covers the User Interface (UI) of a certain Bounded Domain Context. This is a particular domain scope, in the meaning of the Bound-ed Context of Domain-Driven Design [Evans 2004] [Vernon 2014] [Avram & Floyd 2006] and the scope of a Use Case in Requirements Engineering [Jacobson 2011].The Dialog allows the user to achieve a particular domain-specific goal with the help of the User Interface of an application. Usually, for this, a Dialog consists of one or more nested UI Fragments, each rendering a suitable Mask with Controls.2.2.2 Hierarchical Composition and User Interface FragmentsAs a Dialog is part of a User Interface (UI) and any UI is inherently hierarchically structured, there are two Hierarchical Composition scopes involved.First, on the inner scope, the Dialog itself is hierarchically structured out of one or more User Interface Fragments. The UI Fragment is an optically distinct part of a User Interface (UI). Second, on the outer scope, the User Interface is hierarchically structured out of one or more Dialogs. In other words, a UI is a hierarchy of UI Frag-ments, and some UI Fragments are considered distinct Dialogs.UI Dialogs are usually scoped to (subsets of) DDD Bounded Contexts or Use Cases.Chapter 2: Foundations382.3 Object-Oriented ComponentI would advise students to pay more attention to the fundamental ideas [...] for example structured programming principles, the good ideas in “Object Oriented” programming, etc. — Prof. David L. ParnasThe Object-Orientation (OO, [Armstrong 2006]) paradigm and the principle of Modularization are central to Software Development for over two decades as the primary means for structuring and Mastering Complexity. They also strongly em-phasize the concepts Development-Time Classes and Run-Time Objects, Separa-tion of Concerns, Knowledge Encapsulation, Information Hiding, Loose Coupling and Strong Cohesion, and well-defined Application Programming Interfaces. For an illustration of the Object-Oriented Component see the domain model in Figure 2.3 on page 38.For general background information on Components and Component-Orien-tation, see [McIlroy 1968], [Nierstrasz et al. 1992], [Nierstrasz et al. 1992], [Meyer 1997], [Fredriksson 1999], [Weinreich & Sametinger 2001], [Councill & Heinemann 2001], [Lorenz & Vlissides 2001], [Szyperski 2002], [Rosen 2003], [Morch et al. 2004], [Niekamp 2006], [Kim et al. 2007], [Wallace 2010], [Stepan 2011], [Crnkovic 2011], [Dong et al. 2012], [Kaur 2013] and [Heinzemann 2013].2.3.1 Development-Time Class and Run-Time ObjectsIn the context of Object-Oriented Programming (OOP, [Armstrong 2006] ), a Com-ponent during development time is represented as a single OOP Class. This Class is then instantiated one or more times into Objects during run time of the applica-tion. Hence, from a development-time point of view, the term Component refers to ClassObject-OrientedComponent+exhibitsObjectModuleAPIFunctionMethodOperationinstantiated-frombelongs-to++Figure 2.3: Domain Model of Object-Oriented ComponentObject-Oriented Component39the Class. From a run-time point of view, the term Component also can refer to one of the instantiated Objects of the Class.In the context of User Interfaces and this dissertation, this OOP dis-tinction between a Class and its Objects is not important, and hence the generic term Component is used, which covers both the Class and Ob-ject concepts.2.3.2 Structuring and Mastering ComplexityBeside traditional functions on the inner scope and packages and sub-systems on the outer scope, the (Object-Oriented) Component is the primary unit for struc-turing an application. Notably, it allows mastering complexity by Knowledge En-capsulation and an abstraction through a well-defined Application Programming Interface (API).2.3.3 Separation of ConcernsEach Component should focus on a particular concern. Hence, finding the Compo-nent-based slicing of an application usually means to strongly follow the important architecture principle of Separation of Concerns [Dijkstra 1982a] [Mitchell 1990].2.3.4 Knowledge Encapsulation and Information HidingThe principle of Modularization [Parnas 1972a] [Parnas 1972b] [Parnas 1979] [Parnas et al. 1984] is absolutely essential to Software Development. It emphasizes the con-centration and encapsulation of distinct knowledge into Modules and the hiding of internal information by those Modules from external access. Those Modules, in a more general context, are usually also called Components — the term used in this dissertation. In the context of User Interfaces and this dissertation, there is no distinction between a Component and a Module.Beside the Knowledge Encapsulation, a Component should also encapsulate or even completely hide its internal details behind a well-defined Application Pro-gramming Interface (API). This Information Hiding [Mitchell 1990] is a key concept and allows the Component to change its internals without breaking foreign Com-ponents using it.2.3.5 Loose Coupling and Strong CohesionComponents usually depend on other related Components. These dependencies should be as loose as possible to allow changing the dependent Components as much as possible without breaking the Relationship. For this, in-memory de-cou-pling mechanisms like Dependency Injection or the Mediator or Registry pattern are Object-Oriented Compo-nents are in HUICA the primary unit of structur-ing the implementation of User Interfaces.Next >