[Top] [All Lists]

Re: [ontolog-forum] MVC (was: Defining UML in Common Logic)

To: Duane Nickull <dnickull@xxxxxxxxx>
Cc: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Edward Barkmeyer <edward.barkmeyer@xxxxxxxx>
Date: Mon, 22 Feb 2010 17:58:02 -0500
Message-id: <4B830BFA.4090106@xxxxxxxx>
Duane Nickull wrote:
> Try this diagram.
>       (01)

With some interesting minor differences in the assignment of 
responsibilities, this seems to say exactly the same thing as the MS 
article.    (02)

In your original contribution, you said:    (03)

> UML is only one of many ways to represent logic or models.
> I am a big fan of MVC as an architectural pattern!    (04)

Upon reflection, I think you mean to place the emphasis on separating 
the presentation form of information from the information content 
itself, thus allowing multiple forms of representation for the same 
information.  Is that right?    (05)

First, that is a secondary aspect of the MVC pattern.  The MVC pattern 
is primarily about separating presentation technologies and presentation 
concerns, including form, from not only the information content but also 
from the processing application. The goal as presented in the MS article 
is to separate the responsibilities so that people who know how to deal 
with the ergonomic and technical concerns of the human interface can do 
the design and coding for that, while people who know how to do the 
business functions can do the design and coding for that.  That is not 
the only rationale for the pattern, but the emphasis is always on the 
difference in concerns, not just the difference in form.    (06)

Second, the formal representation of engineered knowledge is importantly 
different from multiple display representations for human consumption.  
The syntax of the formal representation has a significant impact on the 
kind of knowledge processing that can be performed on the captured 
knowledge.   Presentation to humans is often the least important concern 
in the formal representation of knowledge.  The reason for formal 
representation is to do some category of formal knowledge processing on 
the model. And it isn't so easy to transform logically equivalent formal 
knowledge representations.  In our experience, a UML class diagram (or a 
set of such diagrams) is a fairly effective way of conveying a concept 
network to people, but the XMI form of the UML model is what I use in 
converting the model to OWL.  And while I can convert UML to OWL with 
very high reliability, converting OWL to UML is "lossy" -- UML has no 
understanding of class definition, for example.  Similarly, going from 
OWL to CLIF is not a problem, but CLIF to OWL transformation is not even 
a reasonable idea in the general case.     (07)

The MVC concept is that the application has structured information that 
one must understand in terms of the structure presented at the 
interface.  Then the display application can render that information in 
any way that makes sense to the intended user.  In a similar way, a 
knowledge base contains structured information in terms of the 
expression notions of the formal language (the interface), but rendering 
that knowledge into another form suitable for knowledge processing, or 
even presentation to a human user, is not a "simple matter of 
programming".  The MVC idea makes assumptions about equivalence of 
content and about abstraction of content for human interface.  But for 
reasoner interfaces, equivalence is hard and abstraction is difficult 
and  rarely desirable.    (08)

Think of it this way:  If using MVC, I build a "Model" component that 
exports the XMI version of the UML model, can you build a View component 
that displays useful UML diagrams?  The answer is Yes.  That is exactly 
what UML tools do.  The Control component allows the user to select the 
components he wants on the diagram; the View section places the 
components on the diagram and may automatically add connecting 
relationships, and so on; and the Model they both use is the knowledge 
base consisting of the concept network extracted from the XMI and/or as 
built from user interactions.  But that is about presenting the 
knowledge contained in the UML model in other forms defined for UML models.    (09)

Now using MVC, I build a Model component that exports CLIF.  Can you 
build a View component that displays useful UML diagrams?  That is a 
horse of a different color.  And that problem is the same one if you are 
to build a component to read a CLIF file and export a UML file.  It has 
nothing to do with the MVC pattern.  (And that is why I don't see the 
relevance of MVC to the formal definition of UML.)    (010)

-Ed    (011)

> On 2/22/10 11:52 AM, "Edward Barkmeyer" <edward.barkmeyer@xxxxxxxx> wrote:
> Duane Nickull wrote:
>> MVC is an architectural pattern used by software architects to separate 
>concerns (Model  view  control).  The idea is that by  cleanly decoupling 
>the model from the control and view aspects of an application, you have more 
>freedom to express it in multiple formats such as UML, spreadsheets, 
>datagrids, graphcs etc.
>> More on MVC here - http://msdn.microsoft.com/en-us/library/ms978748.aspx
>> (Note: I like the Microsoft definition of this pattern as it sits well with 
>the Christopher Alexander style)
> OK.  I went to the MS page and found that the terminology is much wider
> than the application domain for the pattern.
> MVC is a pattern for software design for browser-like user interfaces.
> Per the MS page:
> "Problem
> How do you modularize the user interface functionality of a Web
> application so that you can easily modify the individual parts?
> ...
> Solution
> The Model-View-Controller (MVC) pattern separates the modeling of the
> domain, the presentation, and the actions based on user input into three
> separate classes [Burbeck92]:
> o Model. The model manages the behavior and data of the application
> domain, responds to requests for information about its state (usually
> from the view), and responds to instructions to change state (usually
> from the controller).
> o View. The view manages the display of information.
> o Controller. The controller interprets the mouse and keyboard inputs
> from the user, informing the model and/or the view to change as
> appropriate.
> ..."
> So, in their terms, the Model is the entirety of the decision support
> functionality -- it is the part of the application that manages the data
> and performs all the business processing functions.  The other two
> elements are the part that presents information to the user and the part
> that takes commands and information from the user via mouse, keyboard,
> etc. These functions can be mostly encapsulated, and speak to each other
> using webservices.
> This is an entirely different meaning of "model" from the term as used
> in UML.  In fact, it is not clear to me that the MVC pattern involves or
> requires any modeling concepts in the knowledge engineering sense,
> except for separation of concerns.  (I do see object interaction
> diagrams on the web page.  Ivar would be pleased.)
> What Microsoft calls "MVC" is, I will grant you, a respected
> architectural pattern for user interfaces, whatever its relationship to
> modeling.  It goes back to the late 1960s and the Plato project (which
> was all about the human-computer interfaces and made the application a
> back-end).  IBM (and others) used this approach for the very expensive
> graphical interactive devices of the early 1970s, and for the same
> reason -- programming the interface, with several possible input devices
> (keyboard, tablet, light pen, roller ball, and mouse) and a bit-based
> display, was itself a complex task.  Interestingly, the Xerox PARC
> Smalltalk development -- the first object-oriented programming language
> (by some opinions) -- arose out of experience in developing user
> interface software for the Alto (1975), which was one of the first
> WYSIWYG text processor systems.  It does not surprise me that this
> pattern is not well-known by most V-Basic and many Java programmers,
> who, for the most part don't read anything written before 1992, and I am
> happy to see it published as a best practice at a site they might
> actually read.  Among other things, it is rather too bad that Windows
> didn't and doesn't use this pattern.  Linux does, because Berkeley Unix
> of the late 1980s did.
> -Ed
> --
> Edward J. Barkmeyer                        Email: edbark@xxxxxxxx
> National Institute of Standards & Technology
> Manufacturing Systems Integration Division
> 100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
> Gaithersburg, MD 20899-8263                FAX: +1 301-975-4694
> "The opinions expressed above do not reflect consensus of NIST,
>  and have not been reviewed by any Government authority."
> ---
> Adobe LiveCycle Enterprise Architecture - 
> My TV Show - http://tv.adobe.com/show/duanes-world/
> My Blog  http://technoracle.blogspot.com/
> My Band  http://22ndcenturyofficial.com/
> Twitter  http://twitter.com/duanechaos
>       (012)

Edward J. Barkmeyer                        Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4694    (013)

"The opinions expressed above do not reflect consensus of NIST, 
 and have not been reviewed by any Government authority."    (014)

Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (015)

<Prev in Thread] Current Thread [Next in Thread>