Duane Nickull wrote:
> Try this diagram.
>
>
>http://java.sun.com/developer/technicalArticles/J2EE/despat/gen-interactions.gif
> (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 -
>http://www.adobe.com/products/livecycle/
> 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)
|
