next up previous
Next: Observable properties Up: A Model-View-Controller pattern implementation Previous: Architectural Overview


MVC Infrastructure

The MVC pattern used inside gNuSMV is a simplified version of the ''official`` pattern generally described by Software Engineering Theory (for example, see
http://www.object-arts.com/EducationCentre/Overviews/MVC.htm).

Figure 2: Simplified Model-View-Controller Pattern
\includegraphics[width=10cm]{eps/mvc.eps}
Simplification consists in the fact that in the more general pattern the Constroller-View relationship allows a 1-N cardinality. Also the implementation aims to highlight and address practical requirements (w.r.t. the GTK toolkit), rather than to be strictly and formally faithful implementation of the pattern.

Figure 2 shows three interconnected parts:

Model
Contains the state of the application. Also it provides support to access and modify the state, and knows how to handle dependencies between different parts in the state. For example the application logic could require that changing a variable, causes a changing of another. It is not required the Model's user to be aware about this dependency, because Model autonomously handles it.

Zero, one or more Controllers can be connected to one Model (see Controller, below). Furthermore, one or more Views can be associated with parts of the state; for example a numerical variable could be visualized as a number, as well as a graphic bar. It is important to remark that a Model does not know that a set of Views are connected to its state.

View
Views show parts of the Model state, and interactively exchange information with the User, via input/output devices. View also interacts with the Controller (see below), sending event-associated signals to the Controller, and receiving information to visualize.

A View also associates a set of widget trees, deriving from the Glade File, as well as from the ad-hoc View Representation. Since a Widget contains a state, this implementation differs from the standard MVC pattern, where generally the View side is completely stateless.

As for the Model, a View does not know the semantics concerning what it visualizes, as well as the Model it is connected to.

Controller
The Controller realizes the connection between Models and Views. The Controller contains the GUI logic: for example, it stores the information about what happens when a button is clicked (i.e. handlers of signal are located inside the Controller.)

Two particular mechanisms make the isolation between Model and Controller, and between View and Controller (see sections 3.1 and 3.2 below).

A Controller perfectly knows how the connected Model and View are implemented, and knows both the state and presentation semantics. A Controller is associated to one Model (has a relationship), and in the current implementation is associated only to one View.



Subsections
next up previous
Next: Observable properties Up: A Model-View-Controller pattern implementation Previous: Architectural Overview
Roberto Cavada 2004-11-16