1. Architectural separation (MVC, arch model, Seeheim).
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)
Architectural separation (MVC, arch model, Seeheim).
Bakaev Ilkhom

2. Today’s Plan 1. Architecture separation 2. Design Patterns 3. Why MVC
4. What is MVC
5. What is ARCH model
6. What is SHEEHEIM model
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

3. Architecture separation
The architecture of a computer system is a set of structures which include: components, the outside visible properties of these components and the relations between them.
The aim of architecture models is to supply a pattern for the design and the realization of the user interface.
They decompose the HMI (Human-Machine Interface) into modules and define appropriate roles for each module. These roles contribute towards the correct execution of the system.
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

4. Architecture separation
Several architecture models have been put forward by researchers over the past twenty years. Three main types of architecture can be distinguished in the resulting research literature:
The Language Model (the precursor): presents an analogy between the human dialogue and the human- machine interaction.
Functional models: they bring the software and the interaction together into functional levels.
Agent-based Models: they organize an interactive system into a set of reactions and stimulus.
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

5. Architecture separation
These architecture models recommend the same principle, based on the separation between the system (application) and the human-machine interface.
Therefore, the architecture has to separate application and interface, to define a distribution of the interface services, and to define an exchange protocol [18].
The advantage of separating the interface: it facilitates modifications which can be made to the interface without changing the application.
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

6. The Language model
The Language model was proposed by [14]. This model decomposes the application and the human- machine interface in the same way as a language.
In spite of the fact that this model defines four levels of abstraction, it also has some drawbacks.
Priority is given to the shape of the information
The level of abstraction of the protocols of communication between components is not sufficiently clear [6].
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

7. The Language model
The basic principles of the Language model have been used by many researchers, and have influenced the definition of several generic models. The most well-known are functional models.
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

8. Functional models
The functional architecture models provide a separation between the application and the interface. The Seeheim model is the most widely known.
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

9. Seeheim Reference Architecture
The Seeheim reference architecture applies part - whole decomposition to the monolithic reference architecture.
Presentation
Dialogue
Application
To achieve the desired goals of portability and modifiability, the operation of abstraction was applied. Because of the need to mitigate the effects on the user interface of replacing the presentation toolkit, the presentation function was isolated in its own component. In order to insulate against modifications to the dialogue (typically the most heavily modified portion of an interactive system) or to the application, the Seeheim participants again appealed to separation and isolated the dialogue and application each into their own component. Following the two applications of part-whole decomposition, the monolithic model had been transformed as shown in the figure above.

10. Improved Seeheim Uses compression to improve performance problems
Presentation
Dialogue
Application
However, the derivation is not quite complete. A fourth element, the arrow linking presentation and application, was included so that large amounts of data moving from the application interface to the presentation would not have to flow through the dialogue control component. This is an example of layer bridging, or compression. The operation of compression is used to achieve performance efficiency, at the cost of most other quality factors: modifiability, scalability, and so on. The designers of the Seeheim model deemed this an acceptable trade-off, given the efficiency demands of user interfaces when providing real-time responses to user input (semantic feedback, for example). The designers attempted to limit the use of this layer bridge to cases in which the dialogue control is not interested in the actual data. Such a restriction is not enforced by the architecture, however.

11. Strengths of Seeheim Reference Architecture
A separate presentation function supports portability and modifiability.
A separate application layer allows modification of function without affecting the user interface.
A separate dialogue allows modifications to user interaction without rewriting the presentation.
As we have mentioned, the separation of the presentation function supports modifiability by mitigating the effects on the user interface of replacing the presentation toolkit, the presentation function. Portability is achieved because different toolkits can be inserted.
The isolation of the application function allows modifications without affecting the user interface.
The separation of the dialogue function allows the use of the interface to be changed without changing the look (presentation) of the interface.

12. Weaknesses of Seeheim Reference Architecture
Many modifications affect all three functions.
There are performance problems with sophisticated semantic feedback (which result in the need for compression).
Use of the architecture leads to separate notations for dialogue, presentation, and application layer; this is cumbersome.
Problems arise when modifications affect all three functions. For example, adding a function to application requires a change to application to implement the function, a change to presentation so that the user can see the function, and a change to dialogue so that the user can interact with it.
In today’s complex systems where interaction between the system and the user (via the user interface) requires using real-time semantic feedback (such as with an icon being grabbed by the mouse and dragged across the desktop, with a + or - sign always displayed to indicate when the mouse button can be released or not). The computations required take up a great deal of memory space, which can slow performance unless compression is used.
Separating the architecture into layers of functions requires separation notations for presentation, application, and dialogue; this is cumbersome.

13. Unit Operations and HCI Reference Architectures
Monolithic
architecture
PAC/
AMODEUS
MVC
PAC
Seeheim
Arch/
Slinky
part-whole
abstraction
is-a
This is a roadmap slide. You need only to explain the following.
The Seeheim model showed how application of part-whole decomposition resulted in a layered architecture. We will now look at a different application of part-whole decomposition, to arrive at an object-oriented approach, MVC.

14. The Seeheim model
The Seeheim model (Cf. figure 1) was proposed in 1983 by Pfaff [27].
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

15. The Seeheim model
This model works as follows: the presentation performs a lexical analysis in order to translate the statements of the user into computer language.
The dialogue controller provides a syntactic analysis of the interaction language. It also manages interaction between the presentation and the application.
The final module makes it possible to translate the statement into specification language in order to reach the application
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

16. The Seeheim model
The Seeheim model has some drawbacks such as the separation between the dialogue controller component and the other components, which is not always true in reality.
Indeed, the application interface can use semantic information, which makes it possible to control feed-backs for example, to generate default values or to check errors
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

17. The Arch model
The Arch model [1] is a revision of the Seeheim model. It defines a functional breakdown of the interface into five different elements (Cf. Figure 2).
Both the presentation component and the interaction component are a decomposition of the presentation of the Seeheim model. The interaction component manages the physical interactions with the user.
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

18. The Arch model
The presentation component supplies a set of presentation objects which are independent of any toolkit.
The functional kernel carries out the domain concepts. The domain adapter is used for adjusting the differences in the modelling of conceptual objects between the functional kernel and the dialogue controller.
Note that the Arch model is limited in that it is centralized.
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

19. The Arch model
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

20. The Arch model
Seeheim and Arch provide canonical functional structures with big gain.
These models are useful as a structural framework for a design or a rough analysis of the functional decomposition of an interactive system.
Multi-agent reference models aim at a finer functional breakdown.
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

21. Agent based model
Agent-based models are generally based on a modular decomposition of the elements of the interface (like functional models with levels of abstraction) as well as on a reorganization of the location of features and of data and the hierarchy between each entity.
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

22. Agent based model
We shall not detail the notion of agent, but retain the following definition for the term agent:
"An agent acts according to a set of information received and perceived from its environment and according to the goal which it is pursuing".
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

23. WHY MVC?
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

24. Overview 1. Design Patterns 2. Why MVC 3. What is MVC
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

25. PROBLEM
Problem - Without the separation of concerns a developer has to rely and wait for the feeds of others to complete his tasks. Productivity --
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

26. SOLUTION
Solution - With separation of concerns by MVC, he can build applications faster, Unit test them easily without any involvement of other developers. Productivity ++
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

27. MVC Pattern? Architecture? Framework?
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

28. PATTERN “ Each pattern is a three-part rule, which:
expresses a relation between a certain context (design context),
a certain system of forces which occurs repeatedly in that context (recurring design problem),
and a certain software configuration which allows these forces to resolve themselves (solution).“
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

29. ARCHITECTURAL PATTERN:
Fundamental structural organization for software systems.
Architectural patterns are high-level strategies that concerns large-scale components, the global properties and mechanisms of a system.
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

30. ARCHITECTURAL PATTERN:
“At the highest level, there are the architecture patterns that define the overall shape and structure of software applications.
Down a level is the architecture that is specifically related to the purpose of the software application.
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

31. ARCHITECTURAL PATTERN:
Yet another level down resides the architecture of the modules and their interconnections. This is the domain of design patterns, packages, components, and classes.”
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

32. FRAMEWORK:
A software framework is a universal, reusable software platform used to develop applications, products and solutions.
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

33. MVC
In the MVC paradigm, the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of objects, each specialized for its task.
A software framework is a universal, reusable software platform used to develop applications, products and solutions.
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

34. MVC Model View Controller Model Controller View
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

35. Model
The model is responsible for managing the data of the application.
It responds to the request from the view and it also responds to instructions from the controller to update itself
It is the lowest level of the pattern which is responsible for maintaining data.
The Model represents the application core (for instance a list of database records).
It is also called the domain layer
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

36. View The View displays the data (the database records).
A view requests information from the model, that it needs to generate an output representation.
It presents data in a particular format like JSP, ASP, PHP.
MVC is often seen in web applications, where the view is the HTML page.
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

37. Controller
The Controller is the part of the application that handles user interaction.
Typically controllers read data from a view, control user input, and send input data to the model.
It handles the input, typically user actions and may invoke changes on the model and view.
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

38. Working of MVC in web application
PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS ( TEMPUS FR-TEMPUS-JPCR)

39. Questions Do controllers have a user interface?
Does a view allow user input?
Can a view send messages to the model?
Can a view send messages to the controller?
Can you have more than one view?
Can you more than one model?
Can you more than one controller?
Is a controller just one file? A View?, A Model?
Should the view UI be separate from the controller interface?