Guideline: The Model-View Separation Principle - UML

What kind of visibility should other packages have to the UI layer? How should non - window classes communicate with windows?

In this context, modelis a synonym for the domain layer of objects (it's an old 00 term from the late 1970s). Viewis a synonym for UI objects, such as windows, Web pages, applets, and reports.

The Model - View Separationprinciple2 states that model (domain) objects should not have direct knowledge of view (UI) objects, at least as view objects. So, for example, a Register or Saleobject should not directly send a message to a GUI window object ProcessSaleFrame, asking it to display something, change color, close, and so forth.

A legitimate relaxation of this principle is the Observer pattern, where the domain objects send messages to UI objects viewed only in terms of an interface such as PropertyListener (a common Java interface for this situation). Then, the domain object doesn't know that the UI object is a UI object - it doesn't know its concrete window clasj. It only knows the object as something that implements the PropertyListener interface.

A further part of this principle is that the domain classes encapsulate the information and behavior related to application logic. The window classes are relatively thin; they are responsible for input and output, and catching GUI events, but do not maintain application data or directly provide application logic. For example, a Java JFrame window should not have a method that does a tax calculation. A Web JSP page should not contain logic to calculate the tax. These UI elements should delegate to non - UI elements for such responsibilities.

The motivation for Model - View Separation includes:

  • To support cohesive model definitions that focus on the domain processes, rather than on user interfaces.
  • To allow separate development of the model and user interface layers.
  • To minimize the impact of requirements changes in the interface upon the domain layer.
  • To allow new views to be easily connected to an existing domain layer, without affecting the domain layer.
  • To allow multiple simultaneous views on the same model object, such as both a tabular and business chart view of sales information.
  • To allow execution of the model layer independent of the user interface layer, such as in a message - processing or batch - mode system.
  • To allow easy porting of the model layer to another user interface framework.

What's the Connection Between SSDs, System Operations, and Layers?

During analysis work, we sketched some SSDs for use case scenarios. We identified input events from external actors into the system, calling upon system operations such as makeNewSale and enterltem.

The SSDs illustrate these system operations, but hide the specific UI objects. Nevertheless, normally it will be objects in the UI layer of the system that capture these system operation requests, usually with a rich client GUI or Web page.

In a well - designed layered architecture that supports high cohesion and a separation of concerns, the UI layer objects will then forward - or delegate - the request from the UI layer onto the domain layer for handling.

Now, here's the key point:

The messages sent from the UI layer to the domain layer will be the messages illustrated on the SSDs, such as enterltem.

For example, in Java Swing, perhaps a GUI window class called ProcessSale - Frame in the UI layer will pick up the mouse and keyboard events requesting to enter an item, and then the ProcessSaleFrame object will send an enterltem message on to a software object in the domain layer, such as Register, to perform the application logic.

System operations in the SSDs and in terms of layers

System operations in the SSDs and in terms of layers

Example: Monopoly Logical Architecture?

The Monopoly architecture is a simple layered design - UI, domain, and services. There is nothing novel to illustrate, so the NextGen case study is used for the architectural examples.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

UML Topics