Re: Multi Valued Interface Models?

x wrote:
> "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> news:1139881994.518885.274830_at_z14g2000cwz.googlegroups.com...
> > x wrote:
> > > "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> > > news:1139598896.676278.14030_at_g44g2000cwa.googlegroups.com...
>
> > > You have not given the specifications for the interface in a way that
> not
> > > assume a particular solution.
>
> > This was not a model of the database or any other intermediate software
> > components between the UI and the DB. It is strictly a class diagram
> > for the UI (an interface) itself. From a screen prototype (web page
> > prototype), you can draft a UML class diagram such as this. It is NOT
> > a class diagram for persisting anything, but for the interface with the
> > user.
>
> It is a class diagram (have you noticed the word class ?) for the Model
> part.
> It is not the UI.

It is a class diagram that would participate in the View (UI) NOT in the Model (database) side. The Model might have multiple classes for these same data, while the UI itself has one view of data at a point in time. The Model relates to how the data are modeled for processing and persistence while the View is about how the data are modeled for the interface to the user.

> > I definitely did not model an entire system, if that is what you mean.
> > I prepared exactly one component of an application model -- a class
> > diagram for the user interface (not for the persistence of data
> > collected or presented via that interface, for example).
>
> Your class diagram is an example of how one should not design a class.

It is how you should not design a class for the Model. But it is not part of the Model, but the View (think web page).

> > > > > You talk about data copying.
> > >
> > > > ?
> > > You said "same model could be implemented in xml, for example, for data
> > > exchange".
> > > How is xml better at data exchange rather than at data copying (data
> > > transfer) ?
>
> > It matters not. I used XML as one example of how one might do data
> > exchange. My point was that you don't have to change the model for the
> > data, even if the format. The same UML works for the xml as well as
> > the web page.
>
> Too many tentatives and not one good example.

It is an example of my point, but I apparently have not made that point perfectly clear.

> > > > > > > HTML/XML/HTTP is a poor low level complex way to describe an
> > > interface.
> > > > >
> > > > > > I thought of it as a high level way. I wasn't intending to bring
> HTTP
> > > > > > into the picture, only to take an example of an arbitrary UI.
> Without
> > > > > > loss of generalization...
> > >
> > > > > If they were high level tools you would have found them easy to use.
> > >
> > > > So Dreamweaver and GoLive are high level tools and HTML is a low level
> > > > tool? OK. I use GoLive and only bring up the source code panel and
> > > > code raw xhtml. So, perhaps mid-level for the html and xml.
> > >
> > > Then GoLive is not good enough if you have to go to raw xhtml.
>
> > It does a few things for me so that it is worth using, but perhaps I'm
> > just old fashioned and prefer to code myself rather than have generated
> > code in this case.
>
> Do you prefer to work in assembly language instead of in a high level
> language ?

The CS version of GoLive has significant issues (from my perspective) so perhaps I will change my approach if I use later versions. If I ever need to work with code for debugging, then I prefer it not be generated code. Sometimes that is the best choice, however.

> > > I would not call xhtml source code because it is not the source but the
> > > target.
>
> > And the source looks like...?
>
> That is the question isn't it ?
>
> > > You have not given the specification for the UI.
>
> > Only a class diagram of the precise interface (user interface).
>
> One flower does not a spring make.
>
> > > Have you heard of Model-View-Controller UI paradigm ?
>
> > Oh, you betcha.
> >
> > > RM could be used for the "Model" part for example.
>
> > Yes! Yes! Yes! The RM could be used as the data model for the Model
> > and could not be used as the data model for the View. That is my
> > point.
>
> "The view is the piece that manages the visual display of the state
> represented by the model.

There are models everywhere, so the meaning is getting muddied. The visual display IS an interface and that very interface itself has a model, even if there is another model from which this model is drawn.

> A model can have more than one view. "

Yes. But a single view, itself, has a single logical data model (of precisely that view).

> "The view is responsible for mapping graphics onto a device. A view
> typically has a one to one correspondence with a display surface and knows
> how to render to it. A view attaches to a model and renders its contents to
> the display surface"

Yes, the model of the View is attached to a Model (or backed by a Model).

> "The controller is the piece that manages user interaction with the model."
>
> > > I think the screen layout can also be described by RM.
>
> > I don't. There might be extensions to SQL that ignore the RM that
> > would permit this, but if you use a SQL-92 standard, for example, you
> > can see that there is no way to specify this precise UI with that
> > language. You need to be able to specify a view that is not in 1NF,
> > for example.
>
> Are you sure you are not making a confusion here ?
> The cycle is User --> User input --> Controller --> Model --> View -->
> Display output --> User
> The View in Model-View-Controller has nothing to do with the View as in
> "Relational View of Data" or the View in "SQL View".

The definition of Model in MVC is more specific than my use of the term model. You take the Model from MVC and from that you can derive the logical data model for the View. This logical data model of the View must permit non-1NF structures, for example.

> > > > I would like a <foodItem> with <toppingList> on it.
> > >
> > > How would this exclude the RM ?
> >
> > that little ordered list guy at the end -- toppingList -- would not be
> > how you would model this with the RM. You would have multiple
> > predicates (relations), adding in an ordering attribute and a new table
> > for the toppingList. So you would not model the proposition above with
> > a single predicate like this using the RM.
>
> So what if I would use multiple predicates ?

You can do so. In fact you need to (for the RM), while I don't.

> Buying a pizza is not the same as buying a pizza made according to the
> client recipe.
> A recipe would require multiple predicates.

Logical data modeling is all about what predicates you write. When do you split out a proposition so that you model it with two prepositions, for example. I am inclined to have fewer predicates, but with more complex structure (allowing for lists, for example).

>
> > > What is atomic data by your definition ?
>
> > I don't need it for my purposes. There is no data value that could not
> > have functions defined on it that would extract a portion of it other
> > than a bit. But you could define it in terms of the functions that are
> > currently defined on a type. A scalar or atomic value could then be an
> > element of the type/domain set where no existing operations/functions
> > on that domain partition the value of the element into multiple
> > disjoint values (or something like that -- I'm making it up on the fly
> > when I'm sure there are better definitions existing).
>
> The difference between atomic data and non atomic data is like the
> difference between the pizza and the ingredients + the recipe :-)
>
> > > The fact that RM is badly understood and implemented is recognized by
> many.
> > > Codd said this many times.
>
> > That is why I tried to dig in and actually define it, starting where
> > Codd started.
>
> In his 1990 book he stated 333 rules for a relational implementation.

I'm well aware ;-)

>
> > > Would you want RM to handle screen painting and mouse input ?
>
> > No. But I'm saying that it is a limited data model. It can be used to
> > model the interface between a client and a database service, but not an
> > arbitrary interface between a person and software.
>
> Right. Just the Model part.

with a capital M, not the model of the View.

> > > I was asking if there is data that can be represented by the data model
> of
> > > the UI that cannot be represented by the data model of an SQL database.
>
> > Change the word "by" to "as" and then yes.
>
> The model of the Model part of the UI

The model of the View part of the UI

> cannot be the model of an SQL
> database ?
> Why ? I know SQL is bad, but you are not disputing this.
>
> > > > Once you hide it, however, you
> > > > are no longer using it as the model for the interface.
> > >
> > > Who said anything about hidding it ? Not me.
>
> You skipped this.

Nothing to add or subtract there

>
> > > But if I would be willing to try
> > > hard enough, maybe I could come up with a language based on the RM for
> > > writing code also not just for describing data. Then the applications
> would
> > > become easier to maintain :-)
>
> > I think this is something like what mountain man is suggesting by using
> > stored procedures. You still cannot model the UI with the RM, however.
>
> Why ?

See if you can step into a place where the following sentence makes sense: A View in MVC is backed by a Model which could be illustrated by one or more UML class diagrams, and this View also has a model as illustrated by a single UML class diagram.

--dawn Received on Tue Feb 14 2006 - 12:53:22 CET